Cisco: особенность работы с SDP

        Есть такой нюанс, что кто бы и как бы не звонил на Cisco, то она не 

смотрит на SDP в INVITE, а организует сессию и уже потом начинает договариваться о кодеках и запрашивает их в PROGRESS (SIP 183 Session Progress). Это не противоречит RFC3261 RFC2543

       В общем, вызов управляется двумя информационными ответами в SIP: звонком 180 и ходом сеанса 183 в идеологии Cisco.

        Основное различие между ними заключается в том, что сообщение «180 Ringing» инструктирует UA создать локальный сигнал готовности, тогда как «183 Session Progress» содержит протокол SDP, который также позволяет выполнять обратные вызовы и объявления операторов, согласование кодеков и т. д.

Собственно выдержка из RFC3261:

SIP/2.0 183 Session Progress - используется для того, чтобы заранее получить описание сеанса информационного обмена от шлюзов на пути к вызываемому пользователю.

Linux: после обновления не пускает в графическую оболочку

При входе в Ubuntu под своей учетной записью, перебрасывает обратно на страницу авторизации, случается такое в моей практике на убунту уже 2ой раз, что не могло меня не беспокоить, грешил на драйвер и что он слетел, проверял командами:

lspci -k | grep -EA2 "VGA|3D|Display"

У меня такое

01:00.0 VGA compatible controller: NVIDIA Corporation GT218 [GeForce 210] (rev a2)

Драйвер от NVIDIA 210, но это старый, я ставил 340ый драйвер

Смотрел еще так:

lspci -vnn | grep -i VGA -A 12

Дает нам подробную информацию о видео драйвере.

В итоге проблему решил следующим способом:

1) Смотрим права на файл авторизации, т.к. при входе происходит авторизация, она не срабатывает, процесс загрузки стопится и потом отбивается и запускается заново, а мы это видим как опять вылетающие окно запроса пароля:
 
ls -la /home/имя_пользователя/.Xauthority

Вот что видим(Бинго):

rw------- 1 root root 260 февр. 3 19:16 /home/имя_пользователя/.Xauthority

2) Соответственно меняем права на свои:

sudo chown {user_name}:{user_name} /home/имя_пользователя/.Xauthority

3) Теперь перезаходим и все ок

З.Ы.

Можно вообще удалять - при попытке входа сохжается заново

Mitel: проблема кластеризации и синхронизации на складских сетях связи

В один прекрасный весенний день у нас появилась проблема:

Пропадать начала у нас DECT-связь на сегменте сети

Выглядит так, даю сразу с комментариями:

1) Видим что группа БС потеряла связь с остальной "большей" сетью:

 2) Пропала вся связь, БС ресинхронизируются:

 3) Восстанавливается сеть

4) Все хорошо:

Из документа(раздел 9.2):

www.mitel.com/open-solutions/
SIP-DECT OM System Manual:
INSTALLATION, MAINTENANCE & ADMINISTRATION GUIDE
RELEASE 6.0

CHECKING THE SYNCHRONIZATION OF A NETWORK

Для каждого кластера периодически выполняется проверка синхронизации сети. Если сеть разделена, а у нас как раз он и образовывается, по крайней мере в две подсети все RFP меньшей подсети будут повторно синхронизированы(см. скриншоты). При выполнении начальной процедура синхронизации эта проверка отключена. Мы можем проверить синхронизацию RFP с помощью меню Sync view на портале управления OM (OMP), откуда и делал скриншоты.

Синхронизация проходит несколько стадий по очередно проходят их всех при провале/начале

9.2.1 ПРОЦЕДУРА НАЧАЛЬНОЙ СИНХРОНИЗАЦИИ

Этап 0 Начало

Если хотя бы одна точка RFP была настроена, процесс синхронизации системы будет идти около 30 секунд, если не выбрали мастер базу то следующий этап

Этап 1 Назначение

Если предпочтительный RFP была определена на этапе 0, то она становится источником синхронизации для кластера. В противном случае первый RFP, который отправляет сообщение запуска, будет источник синхронизации для сети. 

На этом этапе, только RFPs сообщающая значение RSSI более лучшее чем DBM -65 будут позволено стать приоритетном источником синхронизации.

Длительность такая же 30 сек.

Этап 2 Синхронизация

Повторяет этап 1 с той лишь разницей что пороговый уровень понижается до -70 дБм

Этап 3 Синхронизации

Повторяет этап 1 с той лишь разницей что пороговый уровень понижается до -75 дБм

Синхронизация завершена

Теперь разрешено любой точки становиться источником синхры, ограничения по уровню и времени нет. Последний уровень “синхронизация завершена” будет достигнут либо все зарегистрированные RFP этого кластера синхронизированный или таймер этапа 1800 секунд истекает.

АТС М-200 КМ-64

С сайта М-200 я узнал следующее:

Офисная АТС КМ-64-экономичное решение, позволяющее быстро организовывать качественную цифровую связь по потоку Е1 с поддержкой всего набора абонентских сервисов.
Офисная АТС КМ-64 компактна, легко инсталлируется, устойчива в работе и не требует поддержки тех. персонала во время эксплуатации. Благодаря высокому сочетанию потребительских качеств и невысокой стоимости, пользуется неизменно высоким спросом как среди профессионалов, так и среди обычных пользователей
Возможность АТС работать по цифровому потоку позволяет применять ее также в качестве промежуточного узла доступа к цифровой сети для офисов, чьи собственные АТС поддерживают только 2-х проводные аналоговые СЛ.
Также оборудование КМ-64 можно использовать в качестве мультиплексора 2-пр СЛ в EDSS PRI и другие сигнализации (разработана плата СМ-8-8СЛ) Это один из самых малобюджетных способов решения данной задачи.
Станция реализует удаленный доступ к АТС. Имеет возможность программирования, мониторинга, получения данных тарификации с компьютера через модемное соединение или сеть internet.
Невысокая стоимость офисной АТС КМ-64 сочетается с хорошим качеством и содержательным функционалом.
Абонентская емкость-64 абонентских порта.

Состав модуля:

Наименование	Описание
Кассета КМ-64	Корпус АТС с кросс-платой под установку 8 линейных ТЭЗов
ТЭЗ КМ-08	Плата управления  с флэш-памятью и Eth
ТЭЗ ИМ-22	Блок питания от сети 220В переменного тока
ТЭЗ АМ-8	плата 8 аналоговых абонентских линий
ТЭЗ СМ-4	Плата 4 аналоговых абонентских линий+4 2-х проводных СЛ
ТЭЗ Р-01	Плата контроллера ИКМ-потока Е1 (G.703)
ТЗК-18	Технологическая заглушка пустых слото-мест

Нам привезли с узла, где валялась без дела и в неизвестном состоянии и до селе их не видел и не знал о подобном девайсе.
Первое что узнали, так это то что не работает сетевая карта на процессорной плате управления  КМ-08, потом что на ней не работает модуль потока PCM-1
Прошивку для мотора прислали максимально 5.58,
на МР-128 к примеру 5.78

Фото объекта:

 Станция 2007 года выпуска

 Такая АТС - такой бизнес

 Как видим плинты кроновские, прим малой емкости это скорее + чем минус, много все равно не набить, максимум 8 абонентов

 Плата процессора В середине модуль потоко, внизу флешка

А вот и модуль потока Е1, возможно 2 на плату.

 

Mitel Open Mobility DECTNetMonitor

К DECT есть ещё вот такое ПО, ставится тоже тривиально выглядит отлично:

-- Строится карта сети

-- Статусы базовых станций

-- В реальном времени видно какая трубка на какой базе и на какой базе какие трубки

-- уровни сигнала

Если 3-5 станций, то не принципиально, но на паре десятков и более и несколько зданий - это спасает и выводит работу на новый уровень +

выглядит круто, как в лучших фильмах про хакеров))

Задумался есть ли такое под авайю и нортель - раньше не сталкивался с таким ПО. Должно быть, но не попадалось и вопросы не возникали.

Syslog: заметки по настройки

Syslog (англ. system log — системный журнал) — стандарт отправки и регистрации сообщений о происходящих в системе событиях (то есть создания логов), использующийся в компьютерных сетях, работающих по протоколу IP. Термином «syslog» называют как ныне стандартизированный сетевой протокол syslog, так и программное обеспечение (приложение, библиотека), которое занимается отправкой/получением системных сообщений. Syslog был создан на платформе BSD и получил широкое распространение на UNIX и GNU/Linux-платформах. Это то что узнал из
Википедии.

Практика:

На сервере:

В начале файла /etc/rsyslog.conf для Linux (/usr/local/etc/rsyslog.conf для FreeBSD) нужно добавить:

#################
#### MODULES ####
#################

$ModLoad imudp ### Эти две строчки нужны для того, чтобы 
$UDPServerRun 514 ### сервер начал слушать порт UDP 514

В конце файла нужно добавить:

$template cisco_voip,"/var/log/voip/%$YEAR%%$MONTH%%$DAY%/%FROMHOST%.log"
:source, isequal, "x.x.x.x" ?cisco_voip
:source, isequal, "y.y.y.y" ?cisco_voip
:source, isequal, "z.z.z.z" ?cisco_voip

Пример настройки cisco:

1) Включение логирования всех комманд пользователей:

AS5350(config)#archive
AS5350(config-archive)#log config
AS5350(config-archive-log-cfg)#logging enable
AS5350(config-archive-log-cfg)#notify syslog
AS5350(config-archive-log-cfg)#hidekeys
AS5350(config-archive-log-cfg)#exit
AS5350(config-archive)#exit
AS5350(config)#exit
AS5350#

2) Настройка отправки логов на syslog:

AS5350(config)#logging on
AS5350(config)#logging trap debugging
AS5350(config)#logging facility local4
AS5350(config)#logging source-interface Loopback0
AS5350(config)#logging address syslog-srv-1
AS5350(config)#logging address syslog-srv-2

Пример настройки Audiocodes:

SyslogServerIP = 213.134.192.25
EnableSyslog = 1
ActivityListToLog = 'pvc', 'afl', 'dr', 'fb', 'swu', 'ard', 'naa', 'spc'
SyslogServerPort = 514

Или: Advanced Configuration --- Management Settings --- Syslog Settings

Сбор логов с VOIP-серверов

В конце файла /etc/rsyslog.conf для Linux (/usr/local/etc/rsyslog.conf для FreeBSD) нужно добавить:

########### REMOTE SYSLOG POLICY #########
*.info;mail.*;auth.*;authpriv.*;cron.* @address syslog-srv-1
*.info;mail.*;auth.*;authpriv.*;cron.* @address syslog-srv-2

Пример настройки rsyslog на стороне SYSLOG-сервера:

В начале файла /etc/rsyslog.conf для Linux (/usr/local/etc/rsyslog.conf для FreeBSD) нужно добавить:

#################
#### MODULES ####
#################

$ModLoad imudp ### Эти две строчки нужны для того, чтобы 
$UDPServerRun 514 ### сервер начал слушать порт UDP 514 

В конце файла нужно добавить:

$template cisco_voip,"/var/log/voip/%$YEAR%%$MONTH%%$DAY%/%FROMHOST%.log"
:fromhost-ip, isequal, "x.x.x.x" ?servers
:fromhost-ip, isequal, "x.x.x.x" ~

Mitel: OMP Managment Portal на JAVA

         У Mitel оказалось есть еще OMP на джаве, если зайти на мастер базу и нажать на вкладку с OMP, то загрузим  вот такую программу и установив увидим:

Зайдя в неё увидим статус системы и множество вкладок, намного богаче чем в вэбе:

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

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

    Мое любимое, Sync view, все базовые станции и их состояние, можно разложить по плану, где как находятся, возможность загрузить фото проекта и на нем разложить присутствует:

 Лог событий, очень важен и рекомендую периодические проверять, хоть так, хоть через syslog. Здесь самое волнительное - это
CLSR(007) is split into subnets
clsr - то что информация кластера
007 - номер кластера
is split into subnets - говорит о том что заново собирается, вся дект сеть
                                  перезагрузилась.

Отличный конторль абонентов, его id, PARK, номер и на какой он базе сидит, можно посмотреть сколько всего абонентов и на какой базе, можно зайти в проверку статуса, если щелкнуть на выбранном абоненте, можно редактировать и менять пароли и имена регистрации, супер вещь:

Всем спасибо