Общесистемные неисправности

Сервер недоступен в сети

В случае, если сервер ECSS-10 стал недоступен в сети, то необходимо предпринять следующие действия:

  1. Убедиться, что в сети нет шторма;
  2. Убедиться, что сервер подключен к коммутатору, линк активен;
  3. Подключить монитор и клавиатуру к серверу и проверить состояние операционной системы (далее ОС). В случае если ОС не загружена (например, нет приглашения ввода логина и пароля), то выполнить аппаратный перезапуск сервера. Если сервер не запускается, то необходимо обратиться в службу технической поддержки;
  4. Если ОС загружена, выполнить команду "ip a" и убедиться, что все необходимые сетевые интерфейсы подняты;
  5. Выполнить команду ping <IP-адрес ПК управления>. Если ping не проходит, то необходимо проверить сетевые настройки и состояние работы коммутатора.

Сервер доступен в сети, но невозможно подключиться к Cocon, Web

Если вызывная нагрузка обрабатывается нормально, а только недоступны сервисы управления, следует проверить:

Нет доступа в Cocon и Web

Сначала нужно быть уверенным, что логин и пароль вводятся правильные(раскладка, 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

Сервер доступен в сети, но не активен какой-либо сервис

Проверка статуса сервисов из Linux shell

Проверить запущены ли все сервисы ECSS-10 можно командой:

sudo systemctl status <service name>

где <service name> может принимать следующие значения:

  • ecss-core.service
  • ecss-mediator.service
  • ecss-restfs.service
  • ecss-ds.service
  • ecss-mycelium.service
  • ecss-media-server.service
  • ecss-pa-sip.service
  • ecss-pa-megaco.service
  • ecss-erlang.slice
  • ecss-glusterfs-mount.service
  • ecss-web-conf.service
  • ecss-web-socket.service

Результат выполнения команды для сервиса должен показать 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 не может запуститься. 

Решение данной проблемы следующее:

  1. Найти наибольший по размеру каталог;
  2. Освободить раздел от ненужных файлов.

Для остановки и запуска всех сервисов необходимо выполнить команды:

sudo systemctl stop ecss.service
sudo systemctl start ecss.service

Проверка статуса сервисов из CLI

Подключившись к командной оболочке 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 │
│ │megaco1@ecss1  │ecss-pa-megaco-3.14.10.562 │megaco1@ecss1                  │megaco1@ecss1        │15h 3m│
│ │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>. Команда доступна администратору виртуальной АТС.

где:

  • <CLUSTER> — имя ноды MEDIATOR, для которой выполняется команда;
  • <DOMAIN> — имя виртуальной АТС.
По умолчанию выводится 25 последних предупреждений.

Подробное описание команд CLI системы сбора и отображения предупреждений приведено в разделе Команды управления аварийной сигнализацией.

Для просмотра описания по сбору и отображению предупреждений можно подключиться к командной консоли управления операционной системы CoCon и воспользоваться командой man:

man cluster/mediator/md1/alarms/list all
man domain/<DOMAIN>/alarms/list all

Описание предупреждений и действий, необходимых для решения, приведены в разделе Аварийные сообщения и меры по их устранению.

Неисправности конкретного абонента

Алгоритм сбора информации от абонента

При получении жалоб от абонентов системы ECSS-10 необходимо получить от них следующую информацию:

  1. Номер вызывающего абонента;
  2. Номер вызываемого абонента;
    По данной информации определить к какому шлюзу подключен абонент, проверить работу шлюза. Если абонент использует SIP телефон, SIP-шлюз или софтфон — определить модель (в таком случае возможно проблема на стороне абонента).
  3. Точное время, дату вызова или интервал времени;
    По данной информации можно получить трассировку вызова, если она была включена и не удалена по исчерпанию лимита на количество трассировок.
  4. Повторяется ли проблема при вызовах на телефонные номера;
  5. Если вызов не проходит только на определенные номера, узнать список номеров на которые не проходит вызов. Исходя из данной информации по плану маршрутизации определить исходящий транк;
  6. Выяснить в какое время не проходят вызовы: в любое время или в определенные часы. Если в определенные часы — проверить маршрутизацию по времени.

Устранение любого отказа следует начинать со сбора информации. Источниками информации об отказе, могут быть:

  1. Сообщения о предупреждениях (по e-mail, jabber);
  2. Приложение Список предупреждений (Alarm list) в web-интерфейсе или вывод команды /cluster/mediator/md1/alarms/list);
    Подробнее см. Просмотр текущих предупреждений в системе, Аварийные сообщения и меры по их устранению;
  3. Жалобы и замечания других абонентов;
    При получении жалоб и замечаний от абонента, следует получить максимально подробную информацию о проблеме.
  4. Аварийные и информационные сообщения на взаимодействующих устройствах и системах (шлюзы, SBC, Softswitch, коммутаторы);
  5. Данные по предоставленным услугам (cdr или история вызовов);
  6. Просмотр информации о потребляемых ресурсах.

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

Приложение Web-конфигуратора "Список предупреждений (Alarm list)"  предоставляет следующую информацию:

  • уникальный идентификатор предупреждения (id);
  • дата и время возникновения предупреждения (date);
  • уровень важности предупреждения (severity);
  • класс предупреждения (class);
  • тип предупреждения (type);
  • местоположение подсистемы, которая сгенерировала предупреждение (location);
  • сообщение о предупреждения (message).

Подробнее в разделе Описание структуры предупреждения.

Классификация предупреждений

По уровню важности предупреждения делятся на:

  • критическое предупреждения (critical);
  • важный уровень предупреждения (major);
  • незначительный уровень предупреждения (minor);
  • оповещение (warning);
  • уровень предупреждения не определен (indeterminate);
  • предупреждение сброшено (cleared).

По типу предупреждения делятся на:

  • предупреждения, связанные с коммуникациями (communicationsAlarm);
  • предупреждения, связанные с качеством сервиса (qualityOfServiceAlarm);
  • предупреждения, связанные с обработкой (processingErrorAlarm);
  • предупреждения, связанные с оборудованием (equipmentAlarm);
  • предупреждения, связанные с окружением (environmentalAlarm);
  • предупреждения, связанные с неполной информацией (integrityViolation);
  • предупреждения, связанные с некорректной работой (operationalViolation);
  • предупреждения, связанные с физическими нарушениями (например, выход оборудования из строя) (physicalViolation);
  • предупреждения, связанные с безопасностью (например, несанкционированный доступ) (securityServiceOrMechanismViolation);
  • предупреждения, связанные с возникновением несвоевременных или запрещенных событий (timeDomainViolation);
  • другая (не отнесена к выше перечисленным) (other).

Локализация неисправности

В большинстве случаев информации, полученной в панели предупреждений, достаточно для того, чтобы локализовать неисправность. Сложность представляют те случаи, при которых наблюдается отказ, но в панели предупреждений нет об этом записи. В такой ситуации следует собирать дополнительную информацию. Для точной локализации неисправности, необходимо знать путь прохождения вызова.
Любой вызов, совершаемый через систему, можно разбить на три участка:

  • Плечо А — содержит участок сети от вызывающего абонента (далее абонента А) до системы ECSS-10; ПО шлюза или телефона <--> сетевой стек оп. системы <--> линия связи <--> сетевой стек оп. системы <--> протокол адаптер ECSS (pa-sip, megaco)
  • Ядро системы ECSS-10 и Media Server. Ядро содержит сервисы управляющие логикой обработки вызова, медиасервер — выполняет функции трансляции, транскодирования, записи и смешивания медиа-трафика.
  • Плечо Б — содержит участок сети от системы ECSS-10 до вызываемого абонента (далее абонента Б);

Отказы по одному или нескольким абонентам

Если отказы наблюдаются только на оном или нескольких абонентов, первым этапом нужно посмотреть в истории вызовов причину отказа. Это можно увидеть в приложении 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: В случае если об отказе нет записи в панели предупреждений, локализацию неисправности следует производить методом последовательной проверки всех участков прохождения вызовов:

  • Протокол адаптер ECSS (pa-sip, megaco) ↔ ядро ECSS-10 ↔ MSR ↔ сетевой стек операционной системы ↔ линия связи ↔ сетевой стек операционной системы ↔ ПО шлюза или телефона

При локализации проблемы необходимо учитывать следующие ситуации:

  • Проблема возникла на новом направлении. Если направление новое, необходимо проверить маршрутизацию, регистрацию и авторизацию абонентов;
  • Проблема возникла на ранее созданном направлении (проверенном, работающем). Если направление было введено в работу ранее, протестировано и успешно работало, вероятно, что существуют проблемы с транспортной сетью между системой ECSS-10 и взаимодействующим шлюзом, либо проблема во взаимодействующем устройстве.

Частичные повторяющиеся сбои сессий (SIP/RTP)

Если  наблюдаются сбои в прохождении трафика VoIP или управления, следует проверить сетевой трафик на наличие шторма на сети. Инструменты могут быть любые - tspdump, ntop, tshark и т.п.  Главное - определить интерфейс, где наблюдается резкий подъем трафика. Если возможно, для локализации проблемы - отключить данный сетевой интерфейс и понаблюдать, не исчезла ли проблема. В целом, источники сетевого шторма довольно трудно локализовать. Лучше обратиться к администраторам своей сети, чтобы согласовать настройки коммутаторов.

Сбор детальной информации об отказе (log-файлы, трассировки, дампы)

Набор требуемой детальной информации зависит от шага Локализация неисправности. Так например, если отказ был локализован в ядре ECSS-10, то дополнительно необходимо будет снять log-файлы ядра необходимых сервисов. Список log-файлов, которые необходимо снять, сообщат сотрудники сервисного центра (См. Включение и отключение систем логирования служб).

Алгоритм проверки в случае непрохождения вызова:

  1. Проверить все ли сервисы ECSS-10 запущены (sudo systemctl status <service_name>)  (См. Проверка статуса сервисов);
  2. Проверить прослушивает ли ECSS необходимые порты (sudo netstat) (См. Проверка открытых портов);
  3. Проверить доступность взаимодействующих элементов, шлюзов, телефонов, других softswitch(ping) (См. Проверка доступности направлений А и Б);
  4. Если пункты 1-3 не выявили неисправности, следует сделать тестовый вызов с включенными трассировками (внешними и внутренними) (См. Снятие трассировок ядра, Снятие дампа сетевого трафика);
  5. Снятие log-файлов ядра и протокол адаптеров или других нод по требованию сервисного центра (См. Включение и отключение систем логирования служб).

Включение и отключение систем логирования служб

В системе ECSS-10 каждая нода имеет в своём составе определенный набор служб, ответственных за те или иные процессы. Также имеет набор заранее определенных правил, которые определяют в каком виде записывать log-файлы и для отдельных служб. Большинство правил по умолчанию отключено, так как в не аварийном состоянии системы они не нужны. В процессе определения причины отказа может потребоваться включить те или иные правила.

где:

  • <node_name> — имя ноды (сообщат сотрудники СЦ); 
  • <rule_name> — имя правила (сообщат сотрудники СЦ).
Существуют правила с постфиксом _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

Пакет ecss-utils включает в себя следующие скрипты:

  • binarylog2text - конвертация бинарных логов в текст;
  • binaryfold2text - конвертация всех бинарных логов в каталоге, вызывает binarylog2text;
  • grab_log - конвертирует при помощи binarylog2text лог, полученный утилитой grab_bin_log;
  • grab_bin_log - вынимает лог с соответствующей ноды;
  • epmd_get_port_by_name - вспомогательная утилита для grab_bin_log.

После установки пакета скрипты будут находиться в каталоге /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.

Причины, по которым порт не открыт:

  • Порт используется другим приложением. Необходимо устранить конфликт, например, изменить диапазон используемых портов.
  • IP-адреса, назначенные нодам для IP-телефонии, отсутствует на сервере или находится не в работе.
  • Ошибка применения конфигурации SIP-адаптера. Необходимо выполнить перезапуск SIP-адаптера, log-файл загрузки передать в СЦ компании Элтекс.
    Также стоит проверить порт 5040 на котором по умолчанию слушает media-server.

Проверить настройки SIP-адаптера можно следующей командой:

/domain/<DOMAIN>/sip/network/info

Необходимо обратить внимание на корректность следующих параметров:

  • node_ip — IP-адреса, назначенные на нодах для открытия портов VoIP-телефонии;
  • listen_ports — диапазон портов, открытых для VoIP-телефонии.

Задать параметры можно в командной консоли 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]

Для просмотра трассировки определенного вызова необходимо найти этот вызов используя значения следующих столбцов:

  • Start (Время начала вызова);
  • Original CgPN (Номер вызывающего абонента);
  • Original CdPN (Номер вызываемого абонента);
  • Duration (Продолжительность вызова).

В первом столбце таблице указывается 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, аргументами которой являются:

  • --Te — для указания Short ID;
  • --dets или --text — для указания формата хранения файла (dets внутренний формат для ECSS-10, text для просмотра независимо от системы ECSS-10);
  • --filename — имя сохраняемого файла.
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 в CLI на SIP-адаптере;
  • включить запись TCP dump в Shell Linux;
  • использовать логи SIP-адаптера — siptrace.bin.

При решении проблем, связанных с "потерей" сообщений, рекомендуется снять TCP dump на ECSS-10 и удаленной стороне.

SIP-адаптер позволяет снять дамп обмена сообщениями двумя способами:

  1. TCP dump с сетевого интерфейса (pcap, используется внешний вызов tcpdump с заданными командой параметрами);
  2. файл siptrace.bin дамп (log-файл) 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 и т.д.

Systemd сервис для захвата и сохранения служебного трафика

Ecss-captraf — скрипт для захвата сетевого трафика и его записи. Используется для записи служебного трафика (либо всего, либо только по voip: http/sip/rtp).

Осуществляет запись трафика пользователя с перезаписью файлов в зависимости от заданных параметров:

  • максимальное количество файлов;
  • максимальный размер файла;
  • максимальное время записи в один файл.

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

Для работы необходимо задать имя сетевого интерфейса (одного или нескольких), с которого будет осуществляться захват трафика, либо any, обозначающее любой интерфейс.

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

Скрипт может работать в двух режимах:

  • full — захват всего трафика;
  • voip — захват трафика только с протоколами http, sip, rtp.

В режиме 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, в котором заданы следующие значения:

  • Размер отдельного файла дампа (100 миллионов байт)
    FILE_SIZE=100
  • Количество отдельных файлов дампа (200 файлов)
    FILE_COUNT=200
  • Макс. время записи в файл (1800 секунд, или 30 мин.)
    FILE_ROTATION=1800
  • Имя сетевого интерфейса (любой интерфейс)
    INTERFACE=any
  • Режим работы: full/voip (захват всего трафика)
    MODE=full
  • Путь, по которому будут записываться файлы дампов (/var/cache/ecss/ecss-captraf/)
    DUMP_PATH=/var/cache/ecss/ecss-captraf/

Имена дампов содержат название хоста, на котором запущен сервис, название интерфейса и время начала записи в файл (при условии, что задано ограничение по времени записи).

Запуск осуществляется через systemd сервис — ecss-captraf.service.


Запись сетевого дампа в CLI на SIP-адаптере

Пример запуска трассировки на SIP-адаптере из CLI CoCon:

cluster/adapter/sip1/pcap-trace/start sip1@ecss1 bond0.8 port = 5060

где:

  • sip1@ecss1 — имя ноды sip адаптера;
  • bond0.8 — сетевой интерфейс;
  • port = 5060 — порт с которого необходимо захватить трафик.

В данном случае будет захватываться трафик с 5060 порта. Если необходимо захватить весь трафик, то тогда команда будет выглядеть:

cluster/adapter/sip1/pcap-trace/start sip1@ecss1 bond0.8

Снятые дампы сохраняются в директории /var/log/ecss/.
Более подробно - см. раздел Команды трассировки.

Запись TCP dump в Shell Linux

Для снятия сетевых дампов рекомендуется использовать утилиту tcpdump. Приведем пример для снятия sip-трафика между ESCC-10 и узлом сети 192.168.8.207.

sudo tcpdump -i bond0.8 -w sipdump.pcap port 5060 and host 192.168.8.207

где:

  • -i bond0.8 — сетевой интерфейс с которого снимается дамп; 
  • -w sipdump.pcap — запись снятого дампа в файл sipdump.pcap; 
  • port 5060 and host 192.168.8.207 — фильтр пакетов, сохранять пакеты с портом назначения или источника 5060 и IP адресом назначения или источника 192.168.8.207.

Сохранённый дамп можно посмотреть в консоле с помощью tcpdump:

sudo tcpdump -v -r sipdump.pcap

Полученный дамп можно также открыть с помощью Wireshark.

Логи SIP-адаптера — siptrace.bin

Путь к логу 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.85021
isup cause<<128,21>>
Информаторundefined
Описаниевызов к абоненту запрещен, например, анонимный вызов на абонента с активным сервисом ACB
Заголовок WarningCall is rejected by destination's leg

В Web-конфигураторе для захвата трафика есть приложение Менеджер PCAP трассировки (PCAP trace manager).

Для захвата и анализа трафика можно также использовать другие приложения, например sngrep, tshark, ngrep, sipgrep и подобные. Для постоянного мониторинга и сбора статистики удобно использовать voipmonitor, pcapsipdump, sipcapture и другие. Документацию по использованию можно найти на страницах соответствующих проектов. 

Краткий список проблем, которые можно обнаружить при анализе трассировки сигнализации

  1. На запрос INVITE от шлюза А система ECSS-10 отправляет ответ 100, затем ответ 486 Busy Here с Reason: Q.850;cause=17;text="User busy" — данное сообщение говорит о том, что абонент Б занят другим вызовом или у него снята трубка.
  2. На запрос INVITE от шлюза А система ECSS-10 отправляет ответ 100, затем ответ 484 Address Incomplete с кодом разъединения Reason: Q.850;cause=28;text="Invalid number format (address incomplete)" — сообщение указывает на то, что нет маршрута до абонента Б. Либо абонент А набрал не полный номер, либо не найден маршрут. Для решения проблемы воспользуйтесь разделом Проверка маршрутизации вызова
  3. На запрос INVITE от шлюза А система ECSS-10 отправляет ответ 100, затем ответ 500 Internal Server Error с внутренней причиной отбоя от SIP-адаптера Error-Info: <Exit call by npi_undefined> — данное сообщение говорит о том, что у абонента Б не задано свойство npi (свойство алиаса), необходимо настроить это свойство.
  4. На запрос INVITE от шлюза А (TCP dump запущен на шлюзе А или на пограничном устройстве) приходит сообщение по протоколу ICMP Port unreachable — данное сообщение говорит о том, что в системе ECSS-10 не доступен или не открыт порт, на который шлюз А отправляет сообщение INVITE. Для решения проблемы воспользуйтесь разделом Проверка доступности направлений А и Б.
  5. На запрос INVITE от шлюза А система ECSS-10 отправляет ответ 401 Unauthorized, шлюз повторно отправляет запрос INVITE с данными авторизации, на что система ECSS-10 передает ответ 403 Forbidden со внутренней причиной отбоя от SIP-адаптера Error-Info: <Unknown uri>. Данное сообщение указывает на некорректный логин и пароль, с которыми абонент А пытается авторизоваться на ECSS-10.

  6. На запрос REGISTER от шлюза А система ECSS-10 отправляет ответ 401 Unauthorized, шлюз повторно отправляет запрос REGISTER с данными авторизации, на что система ECSS-10 передает ответ 403 Forbidden с внутренней причиной отбоя от SIP-адаптера Error-Info: <Unknown uri>. Данное сообщение указывает на некорректный логин и пароль, с которыми абонент А пытается зарегистрироваться на ECSS-10.

    При регистрации SIP-абонента с некорректным логином и паролем SIP-адаптер может не отправить ответ 403, если в настройках SIP-адаптера параметр "silent-mode" установлен в значение "true" и при этом в системе активны соответствующие аварии.
  7. На запрос REGISTER от шлюза А система ECSS-10 отправляет ответ 403 Forbidden с внутренней причиной отбоя от SIP-адаптера Error-Info: <Wrong authentication: no auth configuration for subscriber>. Данное сообщение указывает на ошибку в конфигурации абонента ECSS-10. У абонента включена авторизация, но не задан логин или пароль.
  8. На запрос INVITE от шлюза А система ECSS-10 отправляет ответы 100, 180, затем ответ 502 Bad Gateway с причиной отбоя Reason: Q.850;cause=27;text="Destination out of order". Данное сообщение указывает на недоступность направления до абонента Б. Возможно, что шлюз абонента Б не доступен или абонент Б не зарегистрирован (разделы Проверка доступности направлений А и Б, Проверка регистрации SIP-абонентов системы ECSS-10).

  9. На запрос 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

Нужно проверить зарегистрированы ли абоненты. Если абоненты не зарегистрированы, то проблема, из-за которой абоненты не могут зарегистрироваться, возможно, связана с неправильной конфигурацией. При неуспешной аутентификации нужно сравнить настройки авторизации SIP-абонентов в системе ECSS-10 и на шлюзе.

Проверка регистрации SIP-абонентов

Указанные команды выполняются через интерфейс командной строки CLI.
Просмотреть зарегистрированных SIP-абонентов на ECSS-10 можно командой:

/domain/<DOMAIN>/sip/user/registered <GROUP> <INTERFACE>

где

  • <DOMAIN> — имя виртуальной АТС;
  • <GROUP> — название группы пользователей. Символ "*" используется для указания всех групп; 
  • <INTERFACE> — название интерфейса, задается в формате: Имя_пользователя@Домен_SIP_регистрации. Символ "*" используется для указания всех интерфейсов.

Проверка настроек SIP-абонентов

Просмотреть информацию о всех SIP-абонентах ECSS-10 можно командой:

/domain/<DOMAIN>/sip/user/info * *

Просмотреть подробную информацию об определенном SIP-абоненте в системе ECSS-10 можно командой:

/domain/<DOMAIN>/sip/user/info <GROUP> <INTERFACE>

где

  • <DOMAIN> — имя виртуальной АТС;
  • <GROUP> — название группы пользователей. Символ "*" используется для указания всех групп;
  • <INTERFACE> — название интерфейса, задается в формате: Имя_пользователя@Домен_SIP_регистрации. Символ "*" используется для указания всех интерфейсов.

Проверка логина и пароля SIP-абонентов

Посмотреть логины и пароли у всех SIP-абонентов ECSS-10 можно командой:

/domain/<DOMAIN>/sip/user/info * *

Посмотреть логины и пароли у определенного SIP-абонента в системе ECSS-10 можно командой:

/domain/<DOMAIN>/sip/user/info <GROUP> <INTERFACE>

где

  • <DOMAIN> — имя виртуальной АТС;
  • <GROUP> — название группы пользователей. Символ "*" используется для указания всех групп;
  • <INTERFACE> — название интерфейса, задается в формате: Имя_пользователя@Домен_SIP_регистрации. Символ "*" используется для указания всех интерфейсов.

Проверка маршрутизации вызова

Необходимо проверить соответствует ли контекст маршрутизации на сервере файлам, импортированным в базу данных ECSS-10.

Контексты маршрутизации не импортируются автоматически. После внесения изменений в контекст маршрутизации необходимо заново импортировать контекст маршрутизации в базу данных ECSS-10.

Контексты маршрутизации расположены на сервере по следующему пути: /var/lib/ecss/routing/ctx/src/<DOMAIN>.

Посмотреть контекст маршрутизации в ОС Linux можно командой cat.

Посмотреть контекст маршрутизации в командной консоли ECSS-10 можно при помощи команды show.

/domain/<DOMAIN>/routing/show <CONTEXT>
где

  • <DOMAIN> — имя виртуальной АТС;
  • <CONTEXT> — имя контекста маршрутизации.

Если контексты не соответствуют, необходимо импортировать контекст маршрутизации в базу данных ECSS-10.
Импорт контекстов маршрутизации выполняется при помощи команды import.

/domain/<DOMAIN>/routing/import <HOST> <FILE>
где

  • <DOMAIN> — имя виртуальной АТС;
  • <HOST> — имя хоста, на котором созданы контексты маршрутизации;
  • <FILE> — имя файла с контекстом маршрутизации, который необходимо импортировать.

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

/domain/<DOMAIN>/routing/trace iface=<INTERFACE> cdpn.<PARAM>=value [<OPT1>=<VALUE1> [ ... [<OPTN>=<VALUEN>]]]
где

  • <DOMAIN> — имя виртуальной АТС;
  • <INTERFACE> — интерфейс вызывающего абонента;
  • <PARAM> — параметры вызываемого абонента (cdpn.digits, cdpn.incomplete, cdpn.inni, cdpn.nai, cdpn.ni, cdpn.npi);
  • <OPT1>..<OPTN> — опциональные параметры — набор входных данных об устанавливаемом телефонном соединении;
  • <VALUE1>..<VALUEN> — значение опционального параметра.

В итоге выполнения команды для входных данных вызова (интерфейс абонента А, контекст абонента А, время суток, день недели, номер абонента А, номер абонента Б) на выходе будут получены следующие данные: интерфейс абонента А, домен абонента А, контекст абонента А, номер абонента А (возможно модифицированный), номер абонента Б (возможно модифицированный), интерфейс абонента Б.

Пример

/domain/test.domain/routing/trace cgpn.digits=5000 cdpn.digits=700 mode=enblock

Возможны следующие результаты маршрутизации:

  • local — вызов на абонента зарегистрированного на ECSS-10, результат является нормальным; 
  • external — вызов на внешнее направление (Trunk0), результат является нормальным; 
  • no route — отсутствие правил маршрутизации с данными параметрами вызовами. Необходимо внести корректировки в контекст маршрутизации, чтобы вызов с данными параметрами осуществлялся успешно. 
  • no access — отсутствие права доступа с данными параметрами вызова. Необходимо внести корректировки в правила ограничения доступа (access_group, access_type, regime), чтобы вызов с данными параметрами осуществлялся успешно. 
  • no_b_iface — интерфейс может быть неактивен. В случае использования протокола SIP это либо незарегистрированный абонент, либо по транку нет ответа на периодически передаваемые запросы OPTIONS.

Протоколирование действий администратора в консоли web на внешний syslog-сервер

Настройка rsyslog

Для того чтобы включить поддержку принятия 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"

Настройка sys.config

Для приложения 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*

Настройка dnsmasq

Для того чтобы задать IP адрес куда будут направляться записи, нужно переопределить имя хоста «syslog.ecss» в /etc/dnsmasq.d/ecss-syslog. По умолчанию используется адрес 127.0.0.1.

Протоколирование действий пользователей на сервере с установленным ECSS-10

При установке пакета ecss-security, автоматически создается папка /var/log/ecss/security/, в которой будет храниться вся история команд и подключений к серверу.

Перечень выполняемых функций:

  1. Логирование всех выполняемых команд в bash;
  2. Логирование входа/выхода в систему;
  3. Логирование удаленных авторизаций;
  4. Еженедельная ротация логов;
  5. Ограничивает количество подключений в Cocon до 5 в минуту.

Создаваемые лог файлы не возможно удалить или отредактировать, они доступны только для просмотра. Все старые лог файлы сжимаются и перемещаются в каталог /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