По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Одним из важных компонентов установления соединения по протоколу SIP является протокол Session Description Protocol, или сокращенно SDP.
О протоколе SDP впервые заговорили в 1998 году в рамках опубликованного RFC2327. Спустя 8 лет, в 2006 году протокол претерпел некоторые изменения, которые были отображены в RFC4566.
Протокол SDP используется для установления соединения и согласования параметров передачи и приема аудио или видео потоков между оконечными устройствами. Наиболее важными параметрами обмена являются IP – адреса, номера портов и кодеки. Давайте разбираться?
Пример SDP
При установлении сессии SDP параметры передаются в рамках SIP – запросов. Давайте взглянем на один из таких запросов. В данном случае распарсим SIP INVITE, который прилетело на нашу IP – АТС Asterisk с помощью утилиты sngrep:
INVITE sip:74996491913@192.168.x.xxx:5061;transport=UDP SIP/2.0
Via: SIP/2.0/UDP 80.xx.yy.zz:5060;branch=z9hG4bK-524287-1-MThkZjMzNzMyXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX;rport
Via: SIP/2.0/UDP 80.xx.yy.zz:5077;branch=z9hG4bK-XXXXXXXXXXXXXXXX;rport=5077
Max-Forwards: 69
Record-Route: <sip:80.xx.yy.zz:5060;lr;transport=UDP>
Contact: <sip:80.xx.yy.zz:5077>
To: <sip:74996491913@80.xx.yy.zz>
From: <sip:7925XXXXXXX@80.xx.yy.zz>;tag=qdpxhe2avyyjcqfn.o
Call-ID: fb9909e8fYYYYYYYYYYYYYYYYYYYYYY
CSeq: 479 INVITE
Expires: 300
Allow: INVITE, ACK, BYE, CANCEL, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS, UPDATE
Content-Disposition: session
Content-Type: application/sdp
User-Agent: Sippy
P-Asserted-Identity: <sip:7925XXXXXXX@80.xx.yy.zz>
Remote-Party-ID: <sip:7925XXXXXXX@80.xx.yy.zz>;party=calling
h323-conf-id: 4133864240-4217115111-2706418710-XXXXXXXXX
Portasip-3264-action: offer 1
cisco-GUID: 4133864240-4217115111-2706418710-XXXXXXXXX
Content-Length: 278
v=0
o=Sippy 1011212504475793896 1 IN IP4 80.xx.yy.zz
s=-
c=IN IP4 80.xx.yy.zz
t=0 0
m=audio 57028 RTP/AVP 0 8 18 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=yes
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
В приведенном примере можно увидеть, что основная часть SIP – сообщения отделена от SDP сегмента пустой строкой. Помимо прочего, поле Content-Type, что сообщение сопоставимо с SDP параметрами.
Про SDP поля
Каждый из параметров SDP сообщения можно отнести к одной из следующих категорий:
Имя сессии;
Время, в течении которого сессия активна;
Параметры медиа;
Информация о пропускной способности;
Контактная информация;
Поговорим об основных параметрах. Они всегда имеют следующее обозначение: <поле> = <значение>. Поле всегда обозначается 1 буквой.
Поле
Значение
Формат
v=
версия протокола
v=0
o=
инициатор сессии и соответствующие идентификаторы
o=<имя_пользователя> <идентификатор_сессии> <версия> <тип_сети> <тип_адреса> <адрес>. В нашем примере поле o=Sippy 1011212504475793896 1 IN IP4 80.xx.yy.zz (IN - тип сети, интернет, IP4 - тип адреса, IPv4;
s=
имя сессии
в нашем примере прочерк ("-"), имя сессии не указано;
c=
информация о подключении;
Синтаксис таков: c=<тип_сети> <тип_адреса> <адрес>. В нашем примере IN IP4 80.xx.yy.zz. Параметры IN/IP4 объяснены выше.
t=
время активности сессии
Синтаксис поля таков: t=<начальное_время> <конечное_время>. Это обязательное поле, но важно отметить, что оно весьма субъективно, так как невозможно предсказать точное время начала и окончания. В нашем примере t=0 0
m=
тип передачи медиа данных, формат и адресация
m=<тип_медиа> <порт> <транспорт> <формат_передачи>. Давайте разберемся - у нас m=audio 57028 RTP/AVP 0 8 18 101, это означает передачу аудио (может быть значение video, или передача обоих типов), порт передачи обозначен как 57028, транспорт, указанный как RTP/AVP, означает передачу по протоколу RTP в рамках стандарта Audio and Video Conferences with Minimal Control, который описан в RFC3551. После, первый 0 означает протокол G.711 uLaw, 8 означает G.711 ALaw, 18 означает G.729. То есть условно говоря, нам предложено предпочтение кодеков сначала G.711 uLaw, затем G.711 ALaw, и третьим приоритетом G.729. 101 означает поддержку динамического типа данных, например DTMF.
a=
параметры сессии
a=<параметр> или a=<параметр><значение>. SDP сессия может содержать несколько дополнительных атрибутов передачи. Более подробно мы рассмотрим далее.
Помимо указанных параметров, зачастую встречаются такие как k=, в рамках которого описывается метод шифрования, или i=, содержащий дополнительную информацию о сессии. Поговорим про параметры поля a=:
Параметр
Синтаксис и описание
rtpmap
a=rtpmap:<тип> <название_кодировки>/<частота_дискретизации> [/<параметры_кодирования>].
Данный параметр подсказывает имена кодеков, частоту и прочие параметры кодирования для данных, обозначенных в параметре m=. Например, у нас a=rtpmap:0 PCMU/8000, означает использование G.711 с импульсно - кодовой модуляцией по U - закону с частотой дискретизации 8000 Гц.
sendrecv
a=sendrecv
Данный параметр указывает на то, что мы собираемся отправлять и получать медиа - данные. Например, возможно опция отправки (sendonly), только получение (recvonly) и отключения медиа (inactive);
ptime
a=ptime:<длительность_пакета>
Продолжительность RTP - пакет (в миллисекундах). Условно говоря, какой длительности фрагмент голоса переносит один RTP - пакет;
fmtp
a=fmtp:<формат> <специальные_параметры>
Параметр описывает дополнительные параметры сессии, например, такие как режим подавления тишины (VAD) и прочие;
Сериализация – это процесс, в котором одна служба берет структуру данных, такую как словарь в Python, упаковывает ее и передает другой службе для чтения. Это максимально простое определение.
Представьте, что мне нужно отправить кому-то сообщение. Итак, я записываю текст на уже собранный пазл. Далее я разбираю части пазла, добавляю несколько инструкций о том, как его собрать, и отправляю его.
Затем получатель сообщения, получив кусочки головоломки, собирает их вместе. И теперь у него есть мое сообщение.
Техническое определение этого понятия немного интереснее. А именно, сериализация – это процесс преобразования объекта данных в поток байтов и сохранения состояния объекта для хранения на диске или передачи по сети. Это сокращает необходимый размер хранилища и упрощает передачу информации по сети.
Маршалинг и сериализация – в чем разница?
Здесь на ум может прийти понятие маршалинга (Marshalling). Маршалинг – это процесс преобразования представления объекта в памяти в форму, подходящую для передачи.
Хотя маршалинг и сериализация в общих чертах похожи, между ними все-таки есть принципиальная разница. Например, при создании программы в Golang для считывания JSON данных в структуру данных Golang вы можете использовать маршалинг для преобразования пары «ключ-значение» JSON в пару «ключ-значение» Golang.
Разница в том, что маршалинг используется для преобразования данных. А сериализация, напротив, отправляет или сохраняет данные в потоке байтов и повторно собирает их в исходную форму. Оба процесса вроде бы выполняют процесс сериализации, но с разными намерениями.
Вы можете увидеть структуру, которую я создал для взаимодействия с данными Twitter, ниже, как пример процесса маршалинга в действии. В Golang вы можете вставлять подсказки, называемые тегами, легко преобразовывая этот объект в данные JSON с помощью встроенной службы маршалинга Golang.
Что такое Endianness?
Я также хотел бы немного затронуть тему порядка следования байтов. Endianness – это термин, который используется для описания порядка байтов в памяти.
Представьте, что память – это блок, в котором хранятся биты данных. Чтобы сериализация работала, поток байтов должен передавать типы данных независимо от изменения порядка следования байтов из одной системы в другую.
Здесь вы можете увидеть большие различия и не очень. Очень важно, чтобы порядок следования байтов из одной системы в другую совпадал или каким-либо образом преобразовывался, поскольку не все системы упорядочивают свои биты одинаково. Little endian (от младшего к старшему) и big endian (от старшего к младшему)
Варианты использования сериализации
Наш вариант использования в полной мере использует все функции сериализации. Мы планируем получить некоторую информацию от сканируемого оборудования, упаковать эту информацию в поток байтов и отправить ее по сети в другую службу, которая восстановит данные.
Процесс обратной сериализации и восстановления данных в исходную форму называется десериализацией.
Есть и другие варианты использования сериализации. Например, REST API или протоколы обмена сообщениями, такие как AMQP, могут использовать сериализацию для сжатия и отправки данных.
AMQP – это протокол обмена сообщениями, в котором вы отправляете сообщение брокеру AMQP, а служба-получатель «прослушивает» этого брокера в поисках сообщения. Серверные специалисты должны быть хорошо с этим знакомы, так как это часто используется для отправки данных туда и обратно в распределенных системах.
Многие языки программирования включают возможность легкого развертывания некоторой сериализации. Так что это языково-независимая тема.
Пример сериализации
Приведем краткий пример. Код, приведенный ниже, использует библиотеку kombu для отправки сообщений через AMQP. Мы используем ее для отправки сообщений из одного программного пакета в другой по сети. Данный код предназначен для службы, отправляющей сообщение брокеру AMQP:
Обратите внимание на метод publish. Мы передаем метод сериализации в качестве аргумента, чтобы библиотека понимала, как сериализовать данные, которые мы передаем. Сообщение с данными преобразуется в поток байтов, который, если на него посмотреть, выглядит просто как длинная строка букв и цифр. И мы отправляем сообщение.
Соответствующая служба будет использовать тот же метод сериализации для восстановления данных в их исходное состояние. Это важная функция, поскольку мы создаем набор инструментов, которые должны иметь возможность отправлять сообщения друг другу, чтобы все работало.
Форматы данных сериализации
В основном я использую JSON для сериализации, когда этого требует задача. Но тем не менее, вы можете использовать и другие варианты. У JSON много издержек, но для меня он идеален, потому что он читабелен. Вы также можете использовать Protobuf, YAML или XML. Это лишь некоторые из возможных.
Заключение
Сериализация становится необходимостью, когда вы строите свои каналы связи. Полезно знать о таком понятии, чтобы чувствовать себя уверенно при подходе к любому инструменту, который вы используете, с соответствующими базовыми знаниями.
Данный модуль позволяет создавать директории пользователей, которые будут доступны для абонентов через другие модули, например, IVR. Можно создать директорию, содержащую в себе всех сотрудников компании или по одной директории для каждого из департаментов компании. Кроме того, можно обозначит правила маршрутизации вызова для пользователя, когда выбирается определенный сотрудник в директории – к примеру, если кто-то введёт номер генерального директора, вызов отправится на его секретаря.
/p>
Другими словами, данный модуль позволяет иметь Вам корпоративное IVR меню, с помощью которого, сотрудники, зная только имя своего коллеги смогут дозвониться до него через модуль Directory.
Настройка модуля
Для доступа к данному модулю необходимо в меню выбрать Applications –> Directory
Далее необходимо нажать на кнопку + Add Directory и появится окно создания директории
Ниже опишем значащие поля:
Directory Name – понятное название директории, к примеру – «Support», или «Sales»
Directory Description – развёрнутое описание директории
CallerID Name Prefix – префикс, добавляемый к Caller ID звонящего, когда звонок идёт через директорию. К примеру, можно ввести префикс «DIR-», что бы понимать какие звонки пришли из директории
Alert Info – опциональное поле, может быть использовано для посылки сообщения «ALERT_INFO» на SIP устройства, поддерживающие подобную функцию.
Announcement – звуковое приветствие для попавших в директорию. Сообщение по умолчанию – «Welcome to the directory. Please enter the first three or more letters of the party's first or last name, using your touch-tone keypad. Use the 1 key for punctuation. Press 0 to exit the directory and obtain further assistance (Добро пожаловать в директорию. Наберите первые 3 или более букв, которые содержатся в имени или фамилии абонента, используя клавиши на вашем телефоне. Для пробела используйте клавишу 1, и 0 для выхода из директории.)» Данное приветствие рекомендуется сменить на ваше собственное используя модуль System Recordings.
Invalid Retries – количество попыток неудачного набора/ввода имени абонента
Invalid Retry Recording – запись, которая проигрывается при получении неверного имени. Сообщение по дефолту «I’m sorry, there’s no entry matching the keys you have entered. (Извините, но введённая комбинация клавиш не существует)». Данную запись так же можно заменить на вашу собственную с помощью модуля System Recordings
Invalid Recording – Сообщение, которое проигрывается звонящему при нажатии кнопки 0 или если кончились попытки набора. Стандартное сообщение – «We are now transferring you out of the directory. Please hold on for further assistance.(В данный момент ваш вызов направляется вне директории. Ожидайте для дальнейшей информации.)
Invalid Destination – направление для перенаправления вызовов, в случае если истекло количество попыток или был нажат 0. Данное условие может быть отменено функцией «Return to IVR»
Return to IVR – Yes/No (отправлять или нет абонента обратно на IVR, при условии если вызов пришел с IVR.) Если вызов пришел с IVR, то установка в «Yes» отменяет значение поля «Invalid Destination»
Announce Extension – Yes/No – Озвучивать или не озвучивать номер экстеншена, на который будет направлен вызов. Данная функция может быть полезна для уточнения номера экстеншенов при прямом наборе в дальнейшем.
При добавлении новой сущности в директорию с помощью выпадающего меню, есть выбор из 3 опций: All Users – добавление всех существующих экстеншенов на АТС, Custom Entry (для определения конкретной строки набора, может быть полезно для указания номера сотового телефона или какого-нибудь внешнего ресурса), Extension (просто номер отдельного экстеншена).
Ниже пример добавления экстеншена в группу
Далее рассмотрим поля при добавлении экстеншена:
Name – автоматически устанавливается таким же, как и имя экстеншена. К примеру, если имя Ivan, то для набора первых трёх букв потребуется набрать «482» на клавиатуре телефона.
Name Announcement – какой звуковой файл проигрывается при совпадении – например, приветствие для электронной почты, имя или системная запись.
Dial – номер для набора, по умолчанию это тот же экстеншен. Однако, это поле может быть изменено на любой другой номер, как в примере, описанном выше – с генеральным директором и его ассистентом.
На этом всё, для применения изменений необходимо нажать на кнопку Submit и затем Apply Config.