Grandstream umc 6202 настройка - вэб-шпаргалка для интернет предпринимателей!

Введение

LDAP, или Lightweight Directory Access Protocol, является открытым протоколом, используемым для хранения и получения данных из каталога с иерархической структурой. Обычно используемый для хранения информации об организации, ее активах и пользователях, LDAP является гибким решением для определения любого типа сущностей и их свойств.

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

API сервиса

Запрос адресной книги

CODE

<IP> — ip адреса сервера, где установлен пакет ecss-restfs;
<service> — сервис используемый для получения телефонной книги (mysql/yandex/ssw);
<Параметр> — дополнительные параметры запроса, порядок не имеет значения:

Параметры

domain — имя домена для которого забирается адресная книга: str;
name_len — максимальная длина имени: number > 0;
skip_no_disp — пропускать записи без имени: true|false;
translit — использовать транслит: true|false;
user_agent — имя шаблона для адресной книги: str;
limit — ограничение на количество записей: number > 0.

Сбросить кеш для сервиса телефонной книги

CODE

<IP> — ip адреса сервера, где установлен пакет ecss-restfs;
<service> — сервис используемый для получения телефонной книги (mysql/yandex/ssw).

Запрос по протоколу CardDAV

CODE

<IP> — ip адреса сервера, где установлен пакет ecss-restfs;
<service> — сервис используемый для получения телефонной книги (mysql/yandex/ssw);
<Параметр> — дополнительные параметры запроса, порядок не имеет значения:

Параметры

domain — имя домена для которого забирается адресная книга: str;
skip_no_disp — пропускать записи без имени: true|false;
translit — использовать транслит: true|false;

Пример настройки телефона GRANDSTREAM GXP2000

В примере не используется XCAP.

В данном примере схема не отличается от схемы, приведенной в примере 1, кроме того, что производитель SIP-телефона GRANDSTREAM GXP2000.

Настройка аналогична, но есть некоторые отличия. Аппарат не поддерживает протокол XCAP, но реализована возможность синхронизации телефонной книги XML напрямую c TFTP/HTTP-сервера.

Пример:

RUSSIAN Home — 528002;
UKRAINE Friend – 534303.

Создание телефонной книги.

Для Grandstream файл называется gs_phonebook.xml. Формат данных XML-файла имеет следующую структуру:

XML

Сохраняем в XML, размещаем его на TFTP-сервере.
Включение и настройка функции получения телефонной книги.

В телефоне необходимо включить и настроить функции получения телефонной книги.Для телефона GRANDSTREAM нужно зайти во вкладку ADVANCED SETTINGS=> Phonebook XML Download:, рисунок 4.

Рисунок 4 – Настройка функции получения телефонной книги на телефоне GRANDSTREAM

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

Рисунок 5 – Меню загруженной телефонной книги SIP-телефона фирмы GRANDSTREAM

Внешний вид станции

Станция в металличиском корпусе для установки в серверную 19-ти дюймовую стойку (Rack). На лицевой панеле имеются следующие разъёмы:

usb-порт для хранения записей разговоров;
разъём для флеш-карты SD;
8 порта RJ11 для подключения аналоговых городских номеров (FXO);
2 портов RJ11 для подключения аналоговых телефонных аппаратов (FXS);
световые индикаторы работы системы;
цифровое информационное табло.

На тыльной стороне корпуса присутствуют разъем для подключения внешнего блока питания, а также разъём LAN для подключения к локальной сети. Станция имеет встроенную активную систему вентиляции.

Пример настройки телефона snom

Исходные данные: имя и телефон (или несколько телефонов), которые добавляются на сервер, чтобы телефоны могли получить данную информацию по сети. Это могут быть конфигурации, но в данной инструкции не рассматриваются.

Необходимо реализовать схему, которая приведена на рисунке 1.Аппаратная часть – сервер (ECSS-10, Softswith), SIP-телефон (snom320) и TFTP-сервер, на котором хранятся телефонные номера. Также базу телефонной книги можно хранить на сервере Softswith.

Рисунок 1 — Схема стенда

Содержимое телефонной книги
- Home — 528002;
- Friend – 534303;
- Russian President – 8-913-1234567.
Телефон snom320 может получать настройки и телефонную книгу по протоколу XCAP (XML Configuration Access Protocol).

Алгоритм работы: когда пользователь подключает телефон к сети, устройство передает мультиадресный запрос SUBSCRIBE с событием event=ua-profile на адрес 224.0.1.75.SSW проверяет, есть ли запрашивающее устройство в базе (по производителю, модели, версии, MAC-адресу).Если устройство найдено, то шлет ответ 200, и затем запрос NOTIFY с адресом сервера и путем к файлу конфигурации, рисунок 2.

Рисунок 2 — Алгоритм работы
Создание файла телефонной книги.

У каждого телефона свой формат данных телефонной книги и прочих конфигураций. Для каждого производителя (модели устройства) нужно создать свой файл, который находится на сайте производителя телефона. Например, для телефонов snom 320 XML-файл называется phonebook.xml и имеет следующую структуру (исходя из нашего примера):

XML

Сохраняем в XML, размещаем на TFTP-сервере.
Настройка на SSW.
1. Добавляем SIP-телефон в базу ECSS-10 с помощью команды add:
  
  где:<TYPE> — тип профиля: device, user, local-network;<VENDOR> — производитель;<MODEL> — модель (опциональный параметр);<VERSION> — версия (опциональный параметр);<MAC> — MAC-адрес определенного устройства (опциональный параметр).
  
  Любой параметр, кроме VENDOR, может заменить символ «*». Можно, например, прописать конфигурацию по версиям без указания определенной модели или MAC-адреса и т.п.Если введены не все параметры, то значение «*» будет присвоено всем оставшимся параметрам.При попытке добавления уже существующего описания будет выдана соответствующая ошибка: «This definitions is exists».
  
  Пример:
  
  Определяем MAC-адрес устройства и прописываем его на сервере (ECSS-10):
2. Указываются ссылки на соответствующие директории с XML-файлами на сервере (ECSS-10) c помощью команды set:
  
  где: <TYPE>, <VENDOR>, <MODEL>, <VERSION>, <MAC> — описание приведено выше;<PATH> — адрес расположения файла конфигурации или телефонной книги (для SNOM файл должен называться phonebook.xml). Значение по умолчанию: «/TYPE/VENDOR».<EFFECTIVE-BY> — тайм-аут применения изменений устройством (0 — применить сразу). Значение по умолчанию 0.
  
  Пример:
3. Для удаления записи используется команда del:
  
  где:
  
  <TYPE>, <VENDOR>, <MODEL>, <VERSION>, <MAC> — описание приведено выше.—force — не спрашивать подтверждение.Удаление «*» — это удаление записей со значением параметра «*».Если нужно удалить всю группу — параметр не должен быть указан. Например, для удаления всех версий определенной модели ввод команды заканчивается указанием модели.
Проверка параметров на сервере (ECSS-10) с помощью команды info.

Проверка параметров выполняется следующей командой CLI:

где:

<TYPE>, <VENDOR>, <MODEL>, <VERSION>, <MAC> — описание параметров приведено выше. Все параметры опциональны, можно ограничить вывод на любом уровне.

Пример:
Проверка работы.

Телефонная книга отображается в меню аппарата или в WEB-интерфейсе телефона во вкладке Operation=>Directory, рисунок 3.

Рисунок 3 – Переданная телефонная книга на SIP-телефоне фирмы snom

Организация данных

Мы рассмотрели общие элементы, которые используются для построения записей в LDAP системе и поговорили о том, как эти «строительные блоки» определяются в системе. Однако мы еще не много говорили о том, как организована и структурирована сама информация в LDAP DIT.

Размещение записей в DIT

DIT — это просто иерархия, описывающая взаимосвязь существующих записей. После создания, каждая новая запись должна «подключаться» к существующему DIT, помещая себя в качестве дочерней по отношению к какой-либо существующей записи. Это создает древовидную структуру, которая используется для определения отношений и присвоения значения.

Верхний DIT — это самая широкая категория, под которой каждый последующий узел является чьим-то потомком. Обычно самая верхняя часть записи просто используется как метка, называющая организацию, для которой DIT используется. Эти записи могут быть иметь любой объектный класс, но обычно они строятся с использованием доменных компонентов ( для управляющей информации LDAP, связанной с ), местоположений ( для организации или сегмента в Нью-Йорке), или подразделений организации ().

Записи, используемые для организации (используемые как папки) часто используют объектный класс , что позволяет использовать простую описательную метку атрибута с названием . Такого рода записи часто используются для общих категорий в записи DIT верхнего уровня (пример часто используемых — , и ). LDAP оптимизирован для поиска информации по дереву в направлении «вправо-влево», а не «вверх-вниз», поэтому зачастую лучше поддерживать иерархию DIT не глубокой, с обобщенными организационными ветвями, и дальнейшим указанием на различия через задание определенных атрибутов.

Именование (Naming) и ссылочные записи (Referencing Entries) в DIT

Мы ссылаемся на записи по их атрибутам. Это означает, что каждая запись должна иметь однозначный атрибут или группу атрибутов на своем уровне в иерархии DIT. Этот атрибут или группа атрибутов называется относительное отличительное имя или RDN (от relative distinguished name), и несет ту же функцию, что и имя файла в каталоге.

Чтобы однозначно ссылаться на запись, вы используете её RDN в сочетании со всеми RDN её родительских записей. Эта цепочка RDN ведет назад, вверх по иерархии DIT и указывает однозначный путь к соответствующему элементу. Мы называем эту цепочку RDN различимым именем или DN (от distinguished name). Вы должны указать DN для записи во время создания, чтобы система LDAP знала, где разместить новую запись, и могла убедиться, что RDN записи уже не используется другой записью.

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

Например, запись для человека по имени Джон Смит может быть помещена под запись «People» в организации . Так как в организации может быть несколько Джонов Смитов, идентификатор пользователя может быть лучшим выбором для RDN записи. Запись может быть указана вот так:

Нам пришлось использовать объектный класс , чтобы получить доступ к атрибуту в данном случае (кроме того, мы ещё имеем доступ ко всем атрибутам, определенным в объектном классе , причина этого будет понятна в следующем разделе).

Маршрутизация вызова

В плане нумерации производится проверка поступивших А- и Б-номеров с целью дальнейшей маршрутизации вызова

Обратите внимание, что если на входящем плече к номеру А или Б применялись модификации, то поиск производится по тем номерам, которые получились в результате. Модификации номера на исходящем плече вызова не влияют на результат маршрутизации и служат для смены номеров, отдаваемых SMG на взаимодействующее устройство

Проверка номеров осуществляется по двум множествам: номеров А (CgPN) и номеров Б (CdPN).

Множество номеров А включает в себя:

Номера CgPN, заданные в настройках префиксов плана нумерации.

Множество номеров Б включает в себя:

Номера CdPN, заданные в настройках префиксов плана нумерации;
Номера абонентской ёмкости. К абонентской ёмкости относятся номера SIP-абонентов, абонентов из групп динамических абонентов, портов FXS и FXO. Под проверку попадают только те абоненты и порты, у которых в настройках выбран тот же план нумерации, в котором находится вызов;
Номера групп вызова. Под проверку попадают только те группы, у которых в настройках выбран тот же план нумерации, в котором находится вызов.

После окончания поиска вызов производится в префикс, в котором был найден подходящий номер Б. Если номер Б не был найден, вызов маршрутизируется по префиксу, найденному для номера А. Если префикс А также не был найден, вызов завершается с причиной «маршрут не найден» (код 3 — No route to destination).

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

Вызов абонента SIP или динамического абонента;
Вызов порта FXS или FXO;
Вызов группы вызова.

Префикс, найденный по номеру А, либо по номеру Б, может иметь следующий тип:

Транковая группа. При маршрутизации вызова на такой префикс производится вызов на привязанный к транковой группе интерфейс — поток E1 с сигнализацией Q.931, группу линий ОКС-7 (поток E1 с сигнализацией ОКС-7), интерфейс SIP или H.323;
Транковое направление. Транковое направление объединяет несколько транковых групп. Транковая группа для дальнейшей маршрутизации выбирается согласно настройкам транкового направления, а в остальном обработка вызова не отличается от обработки вызова через транковую группу;
Смена плана нумерации. Префикс такого типа позволяет сменить текущий план нумерации на другой. При этом на префиксе можно задать модификаторы номеров CgPN и CdPN, если требуется, чтобы вызов в новом плане нумерации проверялся по изменённым номерам. Маршрутизация вызова в новом плане нумерации будет производиться так же, как если бы вызов пришёл напрямую из входящего плеча;
Модификатор. Префикс позволяет задать абонентскую ёмкость устройства. Если номер попадает в пул номеров, заданный этим префиксом, но для него нет соответствующего номера среди абонентов SMG, то вызов будет завершаться с причиной «номер не распределён» (код 1 — Unallocated (Unassigned) number) вместо стандартной «маршрут не найден» (код 3 — No route to destination);
Префикс ДВО. Служит для управления услугами ДВО — заказом, отменой, проверкой статуса и установкой номеров. Маршрутизации в исходящее плечо при этом не происходит — только изменение настроек ДВО при условии, что для вызывающей стороны ДВО разрешены на SMG;
Группа перехвата. Префикс служит для работы ДВО «Перехват вызова» при условии, что услуга для вызывающей стороны разрешена на SMG. Отличия от работы услуги «Перехват вызова», вызываемой по префиксу ДВО, состоит в том, что перехватывать и перехватываться могут только те номера, которые входят в одну группу перехвата;
IVR-сценарий. Вызов направляется на выбранный сценарий IVR, которым и определяется дальнейшая судьба вызова.

Настройка сервиса

Заранее нужно определиться из какого источника будет осуществляться получение данных абонентов.

Если данные будут получены по ldap, необходимо чтобы на момент настройки был доступ к развернутому ldap серверу (сторонний сервер).
Если абонентские номера будут получены через mysql, то необходимо иметь доступ до сервера mysql, который используется ECSS-10 (по умолчанию при установке пакета ecss-mysql создается специальный пользователь address_book с доступом до таблицы address_book). При этом, если будет использован другой пользователь mysql, необходимо убедиться, что у него есть доступ до базы address_book.
Если номера абонентов будут получены через ssw, необходимо иметь доступ до http терминала сервера.

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

На вопрос «Необходимо ли настроить телефонную книгу?» ответить положительно («Да»);
Далее в соответствии с сервисом/сервисами которые будут использоваться для формировании адресной книги заполнить параметры доступа;

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

CODE

Как настроить АТС Grandstream UCM6208

1. Необходимо подключить АТС к электричеству, а также к локальной сети (коммутатору) по порту LAN.

После этого, на лицевой панеле загорятся индикаторы и экран. Для полной загрузки системы требуется несколько минут.

2. После завершения загрузки нужно узнать какой IP-адрес по DHCP был получен станцией. Для этого необходимо нажать на верхнюю правую клавишу. В нашем случае станция получила адрес 192.168.1.143

Для входа в web-интерфейс системы необходимо воспользоваться одним из браузеров, установленных на вашем ПК и в адресной строке ввести IP-адрес, после чего загрузится стартовая страница, где необходимо ввести стандартные значения Login/Password.

Стандартные значения login/password для IP АТС Grandstream UCM6208

User Name — admin
Password — password

После ввода авторизационных данных, загрузится стартовая страница с отображением статуса работы IP АТС. Страница представляет статистику в семи блоках:

использование пространства;
использование ресурсов;
ёмкость USB;
ёмкость SD;
состояние АТС;
состояние интерфейсов;
статусы транков и внутренних номеров.

3. Для ввода первичных настроек АТС необходимо выбрать пункт Мастер настройки. Первым диалоговым окном будет предложено сменить стандартный пароль доступа в web-интерфейс станции. Вы можете его оставить стандартным, но мы рекомендуем его сменить, а значения сохранить.

Следующее окно мастера предложит изменить сетевые параметры. Для правильной работы АТС необходимо назначить статический IP-адрес из диапазона вашей локальной сети, который в дальнейшем будет использоваться при настройке IP-телефонов:

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

Следующим шагом необходимо организовать внутренние (добавочные) номера:

По умолчанию предлагается организовывать диапозон добавочных номеров в 1000-м диапазоне. Чтобы использовать собственную нумерацию, необходимо поставить Галочку напротив пункта Отключить диапазон добавочных номеров.

Рекомендуемне использовать добавочные номера в диапазоне 101-110 для обеспечения в будщем простого набора экстренных служб, а использовать диапазон с 201.

В поле Создать номер указываем необходимо количество добавочных номеров. Предлагаем сразу задать число с запасом.

В поле SIP пароль можно дать возможность системе сгенерировать случайные пароли к аккаунтам номеров, либо назначить одинаковый пароль для всех аккаунтов.

Проверьте все значения и переходите к следующему диалоговому окну Потоки/Маршруты. Для правильной настройки транков, входящих и исходящих маршрутов рекомендуем пропустить этот диалог.

Следующим шагом необходимо сохранить начальные настройки. Далее для применения изменений нажмите Применить изменения.

После перезагрузки потребуется вновь авторизоваться в системе, но уже по новому IP-адресу.

Наследование в LDAP

По большей части то, как данные в LDAP-системе соотносятся друг с другом, зависит от иерархии, наследования и вложенности. Изначально LDAP для многих людей кажется непривычным, поскольку в его дизайн реализованы некоторые объектно-ориентированные концепции. В основном это связано с использованием классов, о чем мы уже говорили ранее, и с возможностью наследования, о котором мы поговорим сейчас.

Наследование объектных классов

Каждый objectClass — это класс, который описывает характеристики объектов данного типа.

Однако, в отличие от простого наследования, объекты в LDAP могут быть, и часто являются, экземплярами нескольких классов (некоторые языки программирования предоставляют аналогичную функциональность посредством множественного наследования). Это возможно потому, что LDAP под классом понимает просто набор атрибутов, которые он ДОЛЖЕН (MUST) или МОЖЕТ (MAY) иметь. Это позволяет указать для записи несколько классов (хотя только один структурный объектный класс может и должен присутствовать), в результате чего объект просто имеет доступ к объединенной коллекции атрибутов со строжайшими определениями MUST или MAY, имеющими приоритет.

По своему определению, объектный класс может иметь указывать на родительский объектный класс, от которого он наследует свои атрибуты. Это делается с помощью определения , за которым следует название объектного класса, от которого происходит наследование. Например, определение объектного класса начинается следующим образом:

Родительским объектом является объектный класс, следующий за идентификатором . Класс-родитель должен быть того же типа, как и определяемый объектный класс (например, или ). Дочерний объектный класс автоматически наследует атрибуты и требования атрибутов родителя.

При назначении объектного класса конкретной записи, Вам нужно только указать самого последнего потомка цепочки наследования, чтобы иметь доступ ко всему набору атрибутов. В предыдущем разделе мы использовали это для указания в качестве единственного objectClass для нашей записи John Smith, в то же время получив доступ к атрибутам, определенным в объектных классах и . Иерархия наследования выглядит следующим образом:

Почти все деревья наследования каждого объектного класса заканчиваются специальным объектным классом, называемым «top». Это абстрактный объектный класс, единственное предназначение которого заключается в том, чтобы можно было выполнить требование задавания объектного класса. Он используется для указания вершины цепочки наследования.

Наследование атрибутов

Точно так же, сами атрибуты могут указать родительский атрибут в своем определении. В этом случае атрибут наследует свойства, которые были установлены в родительском атрибуте.

Это часто используется для создания более специфических версий общего атрибута. Например, атрибут фамилия (surname) имеет тот же тип, что и имя, и может использовать все те же методы для сравнения и проверки на равенство. Он может унаследовать эти качества, чтобы получить обобщенную форму атрибута «имя» (name). На деле, конкретное определение фамилии может содержать чуть больше, чем указатель на родительский атрибут.

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

Пример настройки для телефона Cisco 88XX/79XX

Для настройки удаленной книги cisco нужно в конфигурацию (SEPxxxxxxxxxx.cnf.xml или XMLDefault.xnf.xml) автопровижена добавить следующее:

88хх

XML

79хх

SIPDefault.cnf:

CODE

<IP> — ip адреса сервера, где установлен пакет ecss-restfs;
<service> — сервис используемый для получения телефонной книги (mysql/yandex/ssw).

Формат шаблона телефонной книги в restfs, c названием файла cisco.xml:

XML

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

Инструкция по синхронизации телефонной книги SIP-телефонов

Общая информация по автоконфигурированию (Autoprovisioning) SIP-телефонов с помощью XML телефонной книги и конфигурационных файлов.

Конфигурационные файлы и телефонные книги создаются для каждого телефона в отдельности, каждый производитель имеет собственный формат данных.
В телефонах необходимо включить функции автонастройки и получения телефонной книги XML. Указываются ссылки на соответствующие директории с XML-файлами на сервере или телефоне.
Можно настроить получение ссылки на конфигурационные файлы через DHCP. На телефонах необходимо разрешить опции «Allow DHCP Option43», «Option 66» и настроить их на DHCP-сервере. В опции 66 необходимо указать адрес директории с конфигурационными файлами (в данной методике не рассматривается).

Дополнительная настройка сервиса

Параметры сервиса

Сервис можно временно сконфигурировать через файл/usr/lib/ecss/ecss-restfs/conf/address-book/card-settings.json. Изменив параметры в файле необходимо перезагрузить сервис ecss-restfs.

CODE

Однако настройки, выставленные в этом файле будут сброшены после обновления пакета ecss-restfs. Верная схема настройки сервиса через установку или реконфигурирование пакета ecss-restfs.

Шаблоны

Шаблоны находятся по пути /etc/ecss/ecss-restfs/template.

Каждый шаблон должен соответствовать следующему виду: -<tempate_name>.xml

— имя шаблона.

Чтобы телефон мог воспользоваться заданным шаблоном, необходимо, чтобы запрос выглядел следующим образом:

<IP> — ip адреса сервера, где установлен пакет ecss-restfs;
<service> — сервис используемый для получения телефонной книги (mysql/yandex/ssw);
<domain> — домен для пользователей которого запрашиваются номера;
<tempate_name> — имя шаблона.
user_agent — аргумент, который позволяет переопределить используемый шаблон, по умолчанию используется первое слово заголовка http-запроса: user-agent.

CODE

Если шаблон не обнаружен, то возвращается адресная книга по стандартному шаблону.

В директориях /usr/lib/ecss/ecss-restfs/template/(ssw|carddav) находятся служебные шаблоны. Изменение или удаление этих файлов может повлечь за собой прекращение работы сервиса.

Вариации протокола LDAP

В начале мы упоминали, что LDAP на самом деле является лишь протоколом, определяющим интерфейс связи для работы со службами каталогов. Обычно он известен как LDAP, или протокол ldap.

Стоит упомянуть, что вы можете увидеть некоторые варианты в обычном формате:

ldap://: Это основной протокол LDAP, позволяющий получить структурированный доступ к службе каталогов.
ldaps://: Этот вариант используется для доступа к LDAP поверх SSL/TLS. Обычно трафик LDAP не шифруется, но большинство реализаций LDAP поддерживают подобный вариант доступа. Такой способ шифрования LDAP-соединений на самом деле устарел, и вместо него рекомендуется использовать шифрование STARTTLS. Если вы работаете с LDAP через незащищенную сеть, настоятельно рекомендуется шифрование.
ldapi://: Это используется для указания LDAP через IPC. Это часто используется для безопасного соединения с локальной LDAP-системой в административных целях. Он связывается через внутренние сокеты вместо того, чтобы использовать открытый сетевой порт.

Все три формата используют протокол LDAP, но последние два указывают на дополнительную информацию о том, как он используется.

Основные компоненты данных LDAP

Выше мы обсуждали, как LDAP является протоколом, используемым для связи с базой данных директорий с целью запроса, добавления или изменения информации. Однако это простое определение искажает сложность систем, поддерживающих этот протокол. То, как LDAP отображает данные для пользователей, очень зависит от взаимодействия и отношений между некоторыми определенными структурными компонентами.

Атрибуты

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

Установка значения для атрибута производится с помощью имени атрибута и значения атрибута, разделенного двоеточием и пробелом. Пример атрибута под названием , который определяет почтовый адрес, будет выглядеть следующим образом:

При обращении к атрибуту и его данным (когда он не задан), две стороны соединяются знаком равенства:

Значения атрибутов содержат большую часть фактических данных, которые вы хотите хранить, и к которым вы хотите получить доступ в системе LDAP. Остальные элементы внутри LDAP используются для определения структуры, организации и т.д.

Записи

Атрибуты сами по себе не очень полезны. Чтобы иметь смысл, они должны быть связаны с чем-то. В LDAP вы используете атрибуты в пределах записи (entry). Запись, по сути, представляет собой набор атрибутов под именем, используемый для описания чего-либо.

Например, вы можете иметь запись для пользователя в вашей системе, или для каждого предмета инвентаризации. Это примерно аналогично строке в системе реляционной базы данных, или одной странице в адресной книге (атрибуты здесь будут представлять различные поля в каждой из этих моделей). В то время как атрибут определяет качество или характеристику чего-либо, запись описывает сам предмет, просто собирая эти атрибуты под именем.

Пример записи, отображаемой в LDIF (LDAP Data Interchange Format), будет выглядеть примерно так:

Приведенный выше пример может быть валидной записью в системе LDAP.

DIT

Начав знакомиться с LDAP, легко понять, что данные, определяемые атрибутами, представляют собой лишь часть доступной информации об объекте. Остальное — это расположение записи в системе LDAP и связи, проистекающие из этого.

Например, если можно иметь записи как для пользователя, так и для объекта инвентаризации, как кто-то сможет отличить их друг от друга? Один из способов отличить записи разных типов — это создание отношений и групп. Это в значительной степени зависит от того, где находится запись при ее создании. Все записи добавляются в систему LDAP в виде веток на деревьях, называемых Data Information Trees, или DIT-ы.

DIT представляет собой организационную структуру, похожую на файловую систему, где каждая запись (кроме записи верхнего уровня) имеет ровно одну родительскую запись и под ней может находиться любое количество дочерних записей. Поскольку записи в LDAP-дереве могут представлять практически все, некоторые записи будут использоваться в основном для организационных целей, подобно каталогам внутри файловой системы.

Таким образом, у вас может быть запись для «people» и запись для «inventoryItems». Ваши фактические записи данных могут быть созданы как дочерние записи приведенных выше, чтобы лучше различать их тип. Ваши организационные записи могут быть произвольно определены, чтобы наилучшим образом представить ваши данные.

В примере записи в разделе выше мы видим одно указание на DIT, в строке :

Эта строка называется distinguished name («dn», «отличительное имя») записи (подробнее об этом позже) и используется для идентификации записи. Она функционирует как полный путь до «корня» DIT. В данном случае у нас есть запись под названием , которую мы создаем. Прямым родителем является запись с именем , которая, вероятно, используется в качестве контейнера для записей, описывающих людей. Родители этой записи произошли от доменного имени , которое выступает как корень нашей DIT.

Что такое LDAP?

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

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

Пример настройки телефонов Yealink (T22P)

В примере не используется XCAP.

Для телефонов Yealink (T22P) есть функция «Удаленная записная книга». При этом XML-файл телефонной книги считывается с HTTP/TFTP-сервера не загружая телефонную книгу на локальную директорию телефона. Нужно только настроить путь к серверу и подготовить XML-файл, разместив этот файл на сервере.

Структура XML-файла телефонной книги (по примеру 1):

XML

Настройка удаленной телефонной книги на телефоне Yealink приведена на рисунке 6.

Рисунок 6 – Настройка удаленной телефонной книги на телефоне Yealink

Можно выставить интервал обновления телефонной книги, а также входящий/исходящий поиск.

Удаленная телефонная книга будет доступна в меню телефона DIR => Remote Phone Book. Есть возможность выбирать разные телефонные книги, выбор осуществляется по названию книги, которое задается в колонке (Display Name), рисунок 6.

На рисунке 7 изображено меню переданной телефонной книги SIP-телефона фирмы Yealink.

Рисунок 7 – Меню переданной телефонной книги SIP-телефона фирмы Yealink