По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
Привычный и удобный интерфейс FreePBX удобен для обновления модулей Asterisk – к нему мы уже привыкли. Но не многие знают, как обновить модули через командную строку (консоль, CLI). Разберемся сначала, как обновить конкретный модуль, а затем, как обновить все модули сразу. Разберем обновление модуля framework. Для этого, через любой SSH клиент подключитесь к вашему Asterisk через CLI и зайдите под правами root Далее, вводим следующую команду: [root@localhost ~]# amportal a ma update framework После успешной установки, нам необходимо применить настройки. Как помните, в FreePBX есть красная кнопка «Apply Config». Ее аналог через CLI это следующая команда: [root@localhost ~]# amportal a r На этом модуль Framework обновлен. Давайте теперь рассмотрим процесс массового обновления всех модулей сразу. Для этого, введем следующую команду: [root@localhost ~]# amportal a ma upgradeall После ввода данной команды, Asterisk начнет обновление всех модулей, для которых доступен апгрейд. По окончанию обновления, аналогично применим конфигурацию командой: [root@localhost ~]# amportal a r
img
Чтобы понять NoSQL, нужно разобраться, что такое SQL и почему мы говорим ему No. Итак, SQL (structured query language) расшифровывается как «язык структурированных запросов», и это язык запросов для управления данными в так называемых реляционных базах данных, или просто БД В реляционных базах мы храним данные в таблицах, которые логически связаны между собой - отсюда и название - реляционные от слова relation, связь. Это один из самых популярных типов баз. В этих таблицах есть строки и столбцы. В столбце таблицы хранится определенный тип данных, а в каждой ячейке – значение. Строка же получается как набор связанных значений, которые относятся к одному объекту - мы видим что у крыла типа чайка длина 25 метров. Ну и каждая строка в таблице может быть помечена каким то уникальным идентификатором, который называется первичным ключом (primary key). А затем при помощи него мы можем связать данные из нескольких таблиц, например в отдельной таблице, где он станет внешним ключом (foreign key). В общем, как таблица в экселе, только данные могут быть связаны. Что еще важно знать: реляционные БД требуют так называемую схему (schema) - описание структуры таблицы ее полей и ограничений. То есть если нам например нужно добавить или убрать столбец в таблице, то это изменение коснется всех данных внутри нее. Также БД этого типа соответствуют так называемым принципам ACID (Atomicity — Атомарность, Consistency — Согласованность, Isolation — Изолированность, Durability — Надёжность), что вкратце означает, что при работе с базой, целостность и согласованность данных гарантирована, даже если возникли проблемы с сетью или железом, что полезно при работе с финансами, например. В качестве примеров таких баз назовем: Microsoft SQL Server, Oracle Database, MySQL и PostgreSQL. Разобрались. Теперь вернемся к NoSQL. Это тип баз данных, которые хранят данные в отличном от реляционных таблиц формате. Они узкоспециализированны для конкретных задач и нужны для улучшения производительности, масштабируемости и удобства в работе. Базы данных "ключ-значение" (key-value) Суть в том, что мы храним данные в таком виде: у нас есть уникальный ключ, который указывает на какое-то значение. А сама база - это совокупность этих пар. Вот так просто! Причем эти данные могут быть чем угодно, числом, строкой или даже другой парой ключ-значение потому что в отличии от реляционных баз данных они не имеют предопределенной структуры данных. Многие БД такого типа хранят данные в памяти (RAM), в отличии от других баз, которые хранят данные на диске, что хоть и может ограничивать объем хранимых данных (хотя они требуют гораздо меньше памяти), но это обеспечивают просто невероятную скорость. Ну и раз это NoSQL то никаких сложных запросов, никаких связей друг с другом - мы просто записываем ключ и его значение, и получаем значение по ключу. Где их использовать? Они отлично подходят для хранения кэша или пользовательских сессий. А в качестве самого простого примера можно назвать корзину в интернет магазине - где мы храним идентификатор пользователя, и сколько товаров он положил в корзину. Самые популярные хранилки по типу “ключ - значение” это Redis, Memcached и DynamoDB. Wide-column (columnstore базы данных, БД с широкими столбцами или колоночные БД) Все также просто - берем key-value БД, и делаем так чтобы в значении мы могли хранить несколько столбцов сразу. Это позволяет удобно хранить связанную информацию. Похоже на реляционную БД, но только в отличии от нее, тут у нас нет схемы, поэтому мы можем хранить разные неструктурированные данные. Такой тип БД подойдет для хранения логов, данных с умных холодильников и чайников, а также различных аналитических приложений, где данные хранятся в большом объеме. Netflix, например, хранит в таких таблицах историю просмотров пользователя. В качестве примеров таких баз назовем Cassandra, Hbase и ClickHouse. Базы данных документов или документориентированные БД (Document DB) Подробнее про них можно прочитать в нашей отдельной статье. Если предыдущие типы NoSQL БД обычно используются для специфических задач, то эти базы уже более универсальны, и могут стать основным местом хранения информации. Здесь мы храним документы. Документ это набор нескольких пар ключ-значение, о которых мы говорили раньше, и раз это не SQL, то они неструктурированны и не требуют схему. Это значит, что мы можем легко добавлять и удалять поля в документе, в отличие от реляционных БД, где изменения затронули бы всю таблицу. Документы даже могут быть вложенными, и содержать в себе другие документы. Данные хранятся в стандартных форматах, таких как XML, YAML и JSON. Такая форма хранения идеально подходит к объектам, которые используются в приложениях. Мы буквально сразу получаем полный объект который нам нужен, а в SQL нужно сначала приложить усилия и даже сделать несколько запросов и все собрать в необходимый вид. Документы можно группировать друг с другом собирая их в коллекции, которые можно собирать в логическую иерархию, получая что-то по типу реляционных БД. Это как шкаф на работе - в один ящик мы можем положить трудовые договоры, в другой - договоры с партнерами, а в третий договоры аренды. Ничто нам не мешает сложить всё в одну кучу, но так удобнее. И вот эти ящики как раз и будут коллекциями в нашем случае. А отсутствие схемы позволяет нам положить в один ящик договоры, которые схожи логически, но имеют разную структуру внутри. Например, долгосрочный договор с сотрудником и договор с компанией. Коллекции есть не у всех БД такого типа, некоторые системы используют теги или древовидные иерархии. Они часто используются для мобильных приложений и игр, блогов, интернет магазинов и всяких штук где у нас имеется много контента. Самые популярные БД такого типа - MongoDB, Amazon DynamoDB, CouchDB. Графовые БД (Graph DB) Тут мы больше значения уделяем тому как данные связаны друг с другом, и эта БД лучше всего обрабатывает такие данные. Тут у нас есть узлы, которые представляют данные и ребра (или соединения), которые описывают связь между этими данными. Помните как в реляционных базах мы записывали связь в отдельной таблице? Тут мы можем обойтись без нее, просто показав связь. Такие базы просто необходимы для алгоритмов рекомендаций, социальных сетей, управления компьютерными сетями и маршрутизацией или даже обнаружения финансового мошенничества. Самые популярные графовые базы: Neo4j и DGraph Поисковые БД (Search-engine database) Они, как понятно из названия, нужны для поиска данных из большого количества источников. Работают они примерно также как и базы данных документов - мы добавляем документы с текстом внутри, а БД проанализирует весь текст в этих документах и создаст индексы для этого текста. По сути это работает как указатели, которые ты видел в конце книги, где указывается какой-то термин и страница на которой он встречается. И когда пользователь выполняет поиск, то сканируются только эти индексы, а не все документы в базе. Ну и очевидно что они используются в качестве полнотекстового поиска, а также для хранения и анализа логов. Примеры - Elasticsearch, Solr, Algolia Базы данных временных рядов (Time series database) Это базы данных, оптимизированные для данных с отметками времени. Такое используется, для мониторинга систем, где мы храним значение времени и данные в этот момент. Например, загрузка сервера или количество подключений. Примеры - InfluxDB и Prometheus Многомодульные БД (multi-model) Также существуют так называемые много-модульные БД (multi-model), которые поддерживают несколько моделей данных. Например тот же рredis умеет и в ключ-значение, и документы с графами и даже временные данные обработает.
img
Данная статья будет посвящена одному из основных протоколов IP телефонии – SIP (Session Initiation Protocol - протокол установления сеанса), разработанный одним из отделений IETF - MMUSIC (Multiparty Multimedia Session Control). Описывается в спецификации RFC 2543 и RFC 3261. SIP – это протокол прикладного уровня модели OSI, описывающий способы и правила установления интернет-сессий для обмена мультимедийной информацией, такой как: звук, голос, видеоряд, графика и др. Для соединения обычно используется порт 5060 или 5061. В качестве транспортных протоколов SIP поддерживает: UDP, TCP, SCTP, TLS . Протокол SIP широко применяется в офисной IP-телефонии, видео и аудио-конференциях, он-лайн играх и др. Элементы Протокол SIP имеет клиент-серверную модель. Основными функциональными элементами являются: Абонентский терминал. Устройство, с помощью которого абонент управляет установлением и завершением звонков. Может быть реализован как аппаратно (SIP-телефон), так и программно (Софтфон). Прокси-сервер. Устройство, которое принимает и обрабатывает запросы от терминалов, выполняя соответствующие этим запросам действия. Прокси-сервер состоит из клиентской и серверной частей, поэтому может принимать вызовы, инициировать запросы и возвращать ответы. Сервер переадресации. Устройство, хранящее записи о текущем местоположении всех имеющихся в сети терминалах и прокси-серверах. Сервер переадресации не управляет вызовами и не генерирует собственные запросы. Сервер определения местоположения пользователей. Представляет собой базу данных адресной информации. Необходим для обеспечения персональной мобильности пользователей. Важные преимущества Так как группа MMUSIC разрабатывала протокол SIP с учётом недостатков предшествующего ему H.323, то SIP обзавелся следующими достоинствами: Простота Так как SIP унаследовал текстовый формат сообщений от HTTP, то в случае если одному терминалу при установлении соединения неизвестна какая-либо возможность, известная другому, то данный факт попросту игнорируется. Если же такая ситуация возникнет с протоколом H.323, то это приведет к сбою соединения, т.к H.323 имеет бинарный формат сообщений и все возможности протокола описаны в соответствующей документации. Масштабируемость В случае расширения сети, при использовании протокола SIP , существует возможность добавления дополнительного числа пользователей. Мобильность Благодаря гибкой архитектуре протокола SIP, пропадает необходимость заново регистрировать пользователей, в случае смены ими своего местоположения. Расширяемость При появлении новый услуг существует возможность дополнят протокол SIP новыми функциями. Взаимодействие с другими протоколами сигнализации Имеется возможность использования протокола SIP с протоколами сигнализации сетей ТфОП, такими как DSS-1 и ОКС7. Типы запросов Для организации простейшего вызова в протоколе SIP, предусмотрено 6 типов информационных запросов: INVITE — Инициирует вызов от одного терминала к другому. Содержит описание поддерживаемых сервисов (которые могут быть использованы инициатором сеанса), а также виды сервисов, которые желает передавать инициатор; ACK —Подтверждение установления соединения адресатом. Содержит окончательные параметры сеанса связи, выбранные для установления сеанса связи; Cancel — Отмена ранее переданных неактуальных запросов; BYE — Запрос на завершение соединения; Register — Идентификация местоположения пользователя; OPTIONS — Запрос на информацию о функциональных возможностях терминала, обычно посылается до фактического начала обмена сообщениями INVITE, ACK; SIP - ответы Определено 6 типов ответов, которым прокси-сервер описывает состояние соединения, например: подтверждение установления соединения, передача запрошенной информации, сведения о неисправностях др. 1хх — Информационные ответы; Информационные ответы сообщают о ходе выполнения запроса и не являются его завершением. Остальные же классы ответов завершают выполнение запроса. 2хх — Успешное окончание запроса; 3хх — Информация об изменения местоположения вызываемого абонента; 4хх — Информация об ошибке; 5хх — Информация об ошибке на сервере; 6хх — Информация о невозможности вызова абонента (пользователь с таким адресом не зарегистрирован, или пользователь занят). В следующей статье мы рассмотрим основные сценарии установления соединения по протоколу SIP, а также его модификации и дополнительные функции.
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59