sdp протокол что это
ИТ База знаний
Полезно
— Онлайн генератор устойчивых паролей
— Онлайн калькулятор подсетей
— Руководство администратора FreePBX на русском языке
— Руководство администратора Cisco UCM/CME на русском языке
— Руководство администратора по Linux/Unix
Навигация
Серверные решения
Телефония
FreePBX и Asterisk
Настройка программных телефонов
Корпоративные сети
Протоколы и стандарты
Про Session Description Protocol
Одним из важных компонентов установления соединения по протоколу SIP является протокол Session Description Protocol, или сокращенно SDP.
Продвинутый курс по Asterisk
Концентрат редких знаний, для внедрения Asterisk в крупных предприятиях. Все это мы собрали в одном курсе для тебя.
О протоколе SDP впервые заговорили в 1998 году в рамках опубликованного RFC2327. Спустя 8 лет, в 2006 году протокол претерпел некоторые изменения, которые были отображены в RFC4566.
Протокол SDP используется для установления соединения и согласования параметров передачи и приема аудио или видео потоков между оконечными устройствами. Наиболее важными параметрами обмена являются IP – адреса, номера портов и кодеки. Давайте разбираться?
Пример SDP
При установлении сессии SDP параметры передаются в рамках SIP – запросов. Давайте взглянем на один из таких запросов. В данном случае распарсим SIP INVITE, который прилетело на нашу IP – АТС Asterisk с помощью утилиты sngrep:
Про SDP поля
Каждый из параметров SDP сообщения можно отнести к одной из следующих категорий:
Базовый курс по Asterisk
Мы собрали концентрат всех must have знаний в одном месте, которые позволят тебе сделать шаг вперед на пути к экспертному владению Asterisk
IP-телефония: от медных проводов до цифровой обработки сигнала
Если в один прекрасный день вам придется на скорую руку разобраться, что есть VoIP (voice over IP) и что значат все эти дикие аббревиатуры, надеюсь, эта методичка поможет. Сразу замечу, что вопросы конфигурирования дополнительных видов обслуживания телефонии (такие как перевод вызова, голосовая почта, конференц-связь и т.п.) здесь не рассматриваются.
1. Базовые понятия телефонии
В общем виде схема подключения локального абонента к телефонному провайдеру по обычной телефонной линии выглядит следующим образом:
На стороне провайдера (АТС) установлен телефонный модуль с портом FXS (Foreign eXchange Subscriber). Дома или в офисе установлен телефон или факс с портом FXO (Foreign eXchange Office) и модуль номеронабирателя.
По внешнему виду порты FXS и FXO никак не отличаются, это обычные 6-выводные RJ11-разъемы. Но с помощью вольтметра отличить их очень просто — на FXS-порте всегда будет какое-то напряжение: 48/60 В, когда трубка положена, или 6–15 В во время разговора. На FXO, если он не подключен к линии, напряжение всегда 0.
Для передачи данных по телефонной линии на стороне провайдера нужна дополнительная логика, которую можно реализовать на модуле SLIC (subscriber line interface circuit), а на стороне абонента — с помощью модуля DAA (Direct Access Arrangement).
Сейчас довольно популярны беспроводные DECT-телефоны (Digital European Cordless Telecommunications). По устройству они аналогичны обычным телефонным аппаратам: в них тоже есть FXO-порт и модуль номеронабирателя, но еще добавлен модуль беспроводной связи станции и трубки на частоте 1,9 ГГц.
Абоненты подключаются к PSTN-сети (Public Switched Telephone Network) — телефонной сети общего пользования, она же ТСОП, ТфОП. PSTN-сеть может быть организована с использованием разных технологий: ISDN, оптики, POTS, Ethernet. Частный случай PSTN, когда используется обычная аналоговая/медная линия — POTS (Plain Old Telephone Service) — простая старая телефонная система.
С развитием Интернета телефонная связь перешла на новый уровень. Стационарные телефонные аппараты все реже используются, в основном по служебным нуждам. DECT-телефоны немного удобнее, но ограничены периметром дома. GSM-телефоны еще удобнее, но ограничены пределами страны (роуминг — дело дорогое). А вот для IP-телефонов, они же cофтфоны (SoftPhone), никаких ограничений, кроме доступа к интернету, нет.
Skype — самый известный пример софтфона. Он может много чего, но имеет два важных недостатка: закрытая архитектура и прослушка известно какими органами. Из-за первого нет возможности создать свою телефонную микросеть. А из-за второго — не очень приятно, когда за вами подсматривают, особенно при личных и коммерческих разговорах.
К счастью есть открытые протоколы для создания своих коммуникационных сетей с плюшками — это SIP и H.323. Софтфонов на SIP-протоколе несколько больше чем на H.323, что можно объяснить его сравнительной простотой и гибкостью. Но иногда эта гибкость может вставлять большие палки в колёса. Оба протокола SIP и H.323 используют RTP-протокол для передачи медиаданных.
Рассмотрим базовые принципы протокола SIP, чтобы разобраться, как происходит соединения двух абонентов.
2. Описание связки SIP/SDP/RTP-протоколов
SIP (Session Initiation Protocol) — протокол установления сессии (не только телефонной) — это текстовый протокол поверх UDP. Также есть возможность использовать SIP поверх TCP, но это редкие случаи.
SDP (Session Description Protocol) — протокол согласования типа передаваемых данных (для звука и видео это кодеки и их форматы, для факсов — скорость передачи и коррекция ошибок) и адреса их назначения (IP и порт). Это также текстовый протокол. Параметры SDP передаются в теле SIP-пакетов.
RTP (Real-time Transport Protocol) — протокол передачи аудио/видеоданных. Это бинарный протокол поверх UDP.
Общая структура SIP-пакетов:
Вот пример двух SIP-пакетов для одной частой процедуры — установления вызова:
Слева изображено содержимое пакета SIP INVITE, справа — ответ на него — SIP 200 OK.
Основные поля выделены рамками:
SDP-сообщение состоит из строк, содержащих пары ПОЛЕ=ЗНАЧЕНИЕ. Из основных полей можно отметить:
RTP-пакеты содержат аудио/видеоданные, закодированные в определенном формате. Данный формат указывается в поле PT (payload type). Таблица соответствия значения данного поля конкретному формату приведена в https://en.wikipedia.org/wiki/RTP_audio_video_profile.
Также в RTP-пакетах указывается уникальный SSRC-идентификатор (определяет источник RTP-потока) и метка времени (timestamp, используется для равномерного проигрывания звука или видео).
Пример взаимодействия двух SIP-абонентов через SIP-сервер (Asterisk):
Как только запускается SIP-телефон, первым делом он регистрируется на удаленном сервере (SIP Registar), отправляет ему сообщение SIP REGISTER.
При вызове абонента отправляется сообщение SIP INVITE, в теле которого вложено SDP-сообщение, в котором указываются параметры передачи звука/видео (какие кодеки поддерживаются, на какой IP и порт отправлять звук и др.).
Когда удаленный абонент поднимает трубку, нам приходит сообщение SIP 200 OK также с параметрами SDP, только удаленного абонента. Используя отправленные и полученные SDP-параметры можно устанавливать RTP-сессию передачи звука/видео или T.38-сессию передачи факсов.
Если полученные параметры SDP нас не устроили, или промежуточный SIP-сервер решил не пропускать через себя RTP-трафик, то выполняется процедура повторного согласования SDP, так называемый REINVITE. Кстати, именно из-за этой процедуры у бесплатных SIP-прокси-серверов есть один недостаток — если оба абонента находятся в одной локальной сети, а прокси-сервер находится за NAT’ом, то после перенаправления RTP-трафика ни один из абонентов не будет слышать другого.
После окончания разговора, абонент положивший трубку, отправляет сообщение SIP BYE.
3. Передача информации о нажатых кнопках
Иногда после установления сессии, во время разговора, требуется доступ к дополнительным видам обслуживания (ДВО) — удержание вызова, перевод, голосовая почта и т.п. — которые реагируют на определенные сочетания нажатых кнопок.
Так, в обычной телефонной линии есть два способа набора номера:
Во время разговора импульсный способ неудобен для передачи нажатой кнопки. Так, на передачу «0» требуется приблизительно 1 секунда (10 импульсов по 100 мс: 60 мс — разрыв линии, 40 мс — замыкание линии) плюс 200 мс на паузу между цифрами. К тому же во время импульсного набора будут часто слышны характерные щелчки. Поэтому в обычной телефонии используется только тоновый режим доступа к ДВО.
В VoIP-телефонии информация о нажатых кнопках может передаваться тремя способами:
Передача DTMF внутри аудиоданных(Inband) имеет несколько недостатков — это накладные ресурсы при генерации/встраивании тонов и при их детектировании, ограничения некоторых кодеков, которые могут исказить DTMF-коды, и слабая надежность при передаче (если потеряется часть пакетов, то может произойти детектирование двойного нажатия одной и той же клавиши).
Главное различие между DTMF RFC2833 и SIP INFO: если на SIP-прокси-сервере включена возможность передачи RTP непосредственно между абонентами минуя сам сервер (например, canreinvite=yes в asterisk), то сервер не заметит RFC2833-пакеты, вследствие чего становятся недоступными сервисы ДВО. Передача SIP-пакетов всегда осуществляется через SIP-прокси-серверы, поэтому ДВО всегда будут работать.
4. Передача голоса и факсов
Как уже упоминалось, для передачи медиаданных используются RTP-протокол. В RTP-пакетах всегда указывается формат передаваемых данных (кодек).
Для передачи голоса существует много разнообразных кодеков, с разными соотношениями битрейт/качество/сложность, есть открытые и закрытые. В любом софтфоне обязательно есть поддержка G.711 alaw/ulaw-кодеков, их реализация очень простая, качество звука неплохое, но они требуют пропускной способности в 64 кбит/с. Например, G.729-кодек требует только 8 кбит/с, но очень сильно загружает процессор, к тому же он не бесплатный.
Для передачи факсов обычно используется либо G.711-кодек, либо T.38-протокол. Передача факсов по G.711-кодеку соответствует передаче факса по T.30-протоколу, как будто факс передается по обычной телефонной линии, но при этом аналоговый сигнал с линии оцифровывается по alaw/ulaw-закону. Это также называется передачей факса Inband T.30.
Факсы по T.30-протоколу выполняют согласование своих параметров: скорости передачи, размера дейтаграмм, тип коррекции ошибок. T.38-протокол базируется на протоколе T.30, но в отличие от Inband-передачи, происходит анализ генерируемых и принятых T.30-команд. Таким образом передаются не сырые данные, а распознанные команды управления факсом.
Для передачи команд T.38 используется UDPTL-протокол, это протокол на базе UDP, он используется только для T.38. Для передачи комманд T.38 можно ещё использовать протоколы TCP и RTP, но они используются гораздо реже.
Основные достоинства T.38 — снижение нагрузки на сеть и большая надежность по сравнению с Inband-передачей факса.
Процедура передачи факса в режиме T.38 выглядит следующим образом:
Передавать факсы по интернету желательно в T.38. Если же факс нужно передать внутри офиса или между объектами, имеющими стабильное соединение, то можно использовать передачу факса Inband T.30. При этом перед передачей факса обязательно должна быть отключена процедура эхоподавления, чтобы не вносить дополнительные искажения.
Очень подробно про передачу факсов написано в книге «Fax, Modem, and Text for IP Telephony», авторы — David Hanes и Gonzalo Salgueiro.
5. Цифровая обработка сигналов (ЦОС). Обеспечение качества звука в IP-телефонии, примеры тестирования
С протоколами установления сеанса разговора (SIP/SDP) и методе передачи звука по RTP-каналу мы разобрались. Остался один немаловажный вопрос — качество звука. С одной стороны, качество звука определяется выбранным кодеком. Но с другой, необходимы еще дополнительные процедуры DSP (ЦОС — цифровой обработки сигналов). Данные процедуры учитывают особенности работы VoIP-телефонии: не всегда используется качественная гарнитура, в интернете бывают пропадания пакетов, иногда пакеты приходят неравномерно, пропускная способность сети тоже не резиновая.
Основные процедуры, улучшающие качество звука:
VAD (Voice activity detector) — процедура определения фреймов, которые содержат голос (активный голосовой фрейм) или тишину (неактивный голосовой фрейм). Такое разделение позволяет заметно снизить загрузку сети, поскольку передача информации о тишине требует гораздо меньше данных (достаточно лишь передать уровень шума или вообще ничего не передавать).
Некоторые кодеки уже содержат внутри себя процедуры VAD (GSM, G.729), для других же (G.711, G.722, G.726) нужно их реализовывать.
Если VAD настроен на передачу информации об уровне шума, то передаются специальные SID-пакеты (Silence Insertion Descriptor) в 13м RTP-формате CN (Comfort Noise).
Стоит заметить, что SID-пакеты могут быть отброшены SIP-прокси-серверами, поэтому для проверки желательно настраивать передачу RTP-трафика мимо SIP-серверов.
CNG (сomfort noise generation) — процедура генерации комфортного шума на базе сведений из SID-пакетов. Таким образом, VAD и CNG работают в связке, но CNG-процедура гораздо менее востребована, поскольку заметить работу CNG-можно не всегда, особенно при малой громкости.
PLC (packet loss concealment) — процедура восстановления звукового потока при потере пакетов. Даже при 50% потере пакетов хороший алгоритм PLC позволяет добиться приемлемого качества речи. Искажения, конечно, будут, но слова разобрать можно.
Простейший способ эмуляции потери пакетов (в Linux) — воспользоваться утилитой tc из пакета iproute с модулем netem. Она выполняет шейпинг только исходящего трафика.
Пример запуска эмуляции сети с потерей 50% пакетов:
Jitter buffer — процедура избавления от jitter-эффекта, когда интервал между принятыми пакетами очень сильно меняется, и что в худшем случае ведет к неверному порядку принимаемых пакетов. Также данный эффект приводит к прерываниям речи. Для устранения jitter-эффекта необходимо на принимаемой стороне реализовать буфер пакетов с размером, достаточным для восстановления исходного порядка отправления пакетов с заданным интервалом.
Эмулировать jitter-эффект также можно с помощью утилиты tc (интервал между ожидаемым моментом прихода пакета и фактическим может достигать 500 мс):
LEC (Line Echo Canceller) — процедура устранения локального эха, когда удаленный абонент начинает слышать собственный голос. Ее суть заключается в том, чтобы вычесть из передаваемого сигнала принимаемый сигнал с некоторым коэффициентом.
Эхо может возникать по нескольким причинам:
Выяснить причину (акустическое или электрическое эхо) несложно: абоненту, на чьей стороне создается эхо, необходимо отключить микрофон. Если эхо все равно возникает — значит оно электрическое.
Более подробно о VoIP и процедурах ЦОС написано в книге VoIP Voice and Fax Signal Processing. Предпросмотр доступен на Google Books.
На этом поверхностный теоретический обзор VoIP завершен. Если интересно, то пример практической реализации мини-АТС на реальной аппаратной платформе можно будет рассмотреть в следующей статье.
[!?] Вопросы и комментарии приветствуются. На них будет отвечать автор статьи Дмитрий Валенто, инженер-программист дизайн-центра электроники Promwad.
Русские Блоги
[RTSP / RTP / RTCP / SDP] Подробное объяснение протокола
1. Протокол RTSP
Разница и связь между RTSP и HTTP:
(1) Контакт: оба отправляют сообщения в виде простого текста, а синтаксис протокола rtsp аналогичен HTTP. Rtsp был разработан таким образом в начале, чтобы быть совместимым с кодом анализа протокола HTTP, написанным ранее.
Существует два типа сообщений RTSP: сообщения запроса и ответные сообщения. Сообщение запроса относится к сообщению запроса, отправляемому от клиента на сервер, а сообщение ответа относится к ответу от сервера клиенту.
Общие методы RTSP включают в себя: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER и SET_PARAMETER.
Краткое описание метода RTSP:
Получение описания объекта мультимедиа также позволяет использовать заголовок получения, чтобы указать формат описания, который понимает пользователь.
При отправке с клиента на сервер, ANNOUNCE отправляет описание медиа-объекта, идентифицированного URL-адресом запроса, на сервер;
При отправке с сервера клиенту, ANNOUNCE обновляет описание соединения в режиме реального времени. Если новый носитель добавлен или изменен, все описание презентации будет отправлено снова
Запрос GET_PARAMETER для проверки значения параметра носителя, указанного в URL. Когда сущности нет, GET_PARAMETER может использоваться для проверки соединения между пользователем и сервером.
Получать методы, поддерживаемые сервером, или выдавать запросы OPTIONS в любое время, чтобы подтвердить состояние сервера или клиента.
Запрос PAUSE вызвал временное прерывание потоковой передачи. Если URL запрашивается для присвоения имени потоку, останавливаются только воспроизведение и запись, а если URL запрашивается для присвоения имени презентации или группе потоков, все активные в данный момент потоки в презентации или группе останавливаются. После возобновления воспроизведения или записи необходимо сохранить синхронизацию.
PLAY указывает серверу начать отправку данных с использованием механизма, указанного в SETUP, клиент может отправить запрос PLAY только после того, как на запрос SETUP был успешно получен ответ. Запрос PLAY устанавливает нормальное время воспроизведения в начале указанного диапазона и отправляет потоковые данные до конца диапазона. Запросы PLAY могут быть поставлены в очередь, сервер ставит в очередь запросы PLAY и выполняет их последовательно
Этот метод инициализирует диапазон записи мультимедийных данных в соответствии с описанием презентации, а временная шкала отражает время начала и окончания, а если временной диапазон не задан, используются время начала и окончания, предоставленные описанием презентации. Если соединение было инициировано, запись начинается немедленно. URL-адрес запроса данных сервера или другой URL-адрес решает, сохранять ли записанные данные; если сервер не использует запрос URL-адреса, ответ должен быть 201 (создать) и включать в себя объект, описывающий состояние запроса и ссылающийся на новый ресурс. Поставь голову Медиа-сервер, поддерживающий живую демонстрационную запись, должен поддерживать формат диапазона часов, а формат smpte не имеет смысла
Запрос на перенаправление информирует клиента о подключении к другому адресу сервера. Он содержит обязательный адрес заголовка, который указывает клиенту на выдачу запроса URL, а также может включать диапазон параметров, указывающий, когда перенаправление вступает в силу. Если клиент хочет продолжить отправку или получение URL-адреса мультимедиа, он должен отправить запрос TEARDOWN для текущего соединения и запрос SETUP для указанного мастера для выполнения нового соединения.
Запрос SETUP к URL-адресу определяет механизм передачи для потокового мультимедиа. Вы также можете заставить клиента выполнить запрос SETUP для воспроизводимого потока, чтобы изменить параметры передачи, разрешенные сервером. Если это не разрешено, ответом будет ошибка 455 «Метод недопустим в этом состоянии». Чтобы пройти через брандмауэр, клиент должен указать параметры передачи, даже если они не влияют на эти параметры.
Этот метод запрашивает установку значения параметра демо или указанного URL потока. Запрос должен содержать только один параметр, позволяющий клиенту решить, почему конкретный запрос не удался. Если запрос содержит несколько параметров, все параметры могут быть установлены успешно, и сервер должен действовать только по запросу. Сервер должен разрешить многократное задание одинаковых значений параметров, но не изменять значения параметров. Примечание. Параметры потоковой передачи мультимедиа должны быть установлены с помощью команды SETUP. Ограничение настроек параметров передачи на SETUP выгодно для брандмауэра. Разделите параметры на регулярное расположение, результат имеет более значимые признаки ошибок
Запрос TEARDOWN прекратить отправку данного потока URL и освободить связанные ресурсы.
Сообщение RTSP состоит из трех частей, а именно: начальная строка, первая строка и тело объекта.
Простой интерактивный процесс RTSP
C означает клиент RTSP, S означает сервер RTSP
Вышеупомянутый процесс является стандартным и дружественным процессом RTSP, но фактический спрос не обязательно приходит шаг за шагом.
Шаги 3 и 4 обязательны! Пока клиент сервера соглашается с тем, какие методы доступны, запрос опции может не потребоваться. На втором этапе, если у нас есть другие способы получения информации описания инициализации носителя (например, HTTP-запрос и т. Д.), Нам не нужно завершать запрос описания в rtsp. На шаге 5 вы можете решить, нужно ли вам это, исходя из требований к системе.
2. Протокол RTP
RTP пакет:
Номер версии (V): 2 бита, используются для обозначения используемой версии RTP.
Бит заполнения (P): 1 бит. Если этот бит установлен, конец пакета RTP содержит дополнительные байты заполнения.
Бит расширения (X): 1 бит. Если этот бит установлен, за фиксированным заголовком RTP следует заголовок расширения.
Счетчик CSRC (CC): 4 бита, содержащие количество CSRC, за которыми следует фиксированный заголовок.
Бит метки (M): 1 бит, интерпретация этого бита принимается профилем.
Тип полезной нагрузки (PT): 7 бит, определяющий тип полезной нагрузки RTP.
Порядковый номер (SN): 16 бит. Отправитель увеличивает значение на 1 после отправки каждого RTP-пакета. Получатель может определить потерю пакета и восстановить последовательность пакетов из этого значения. Начальное значение серийного номера является случайным.
Отметка времени: 32 бита, записывающая время выборки первого байта данных в пакете. В начале сеанса метка времени инициализируется начальным значением. Даже если нет сигнала для отправки, значение метки времени должно продолжать увеличиваться со временем (время идет). Отметка времени необходима для устранения джиттера и синхронизации.
Идентификатор источника синхронизации (SSRC): 32 бита. Источник синхронизации относится к источнику потока пакетов RTP. В одном сеансе RTP не может быть двух одинаковых значений SSRC. Идентификатор выбирается случайным образом. RFC1889 рекомендует алгоритм случайных чисел MD5.
Список источников вклада (список CSRC): от 0 до 15 элементов, каждый по 32 бита, используется для маркировки источника всех пакетов RTP, которые вносят вклад в новый пакет, сгенерированный микшером RTP. Микшер вставляет эти идентификаторы SSRC в таблицу. Идентификаторы SSRC перечислены так, чтобы принимающая сторона могла правильно указывать идентификационные данные обеих сторон в разговоре.
Три, RTCP
RTCP(Real-time ControlProtocol, RTCP) Основными функциями протокола управления передачей в реальном времени являются: мониторинг качества обслуживания и обратная связь, синхронизация между носителями и идентификация участников в многоадресной группе.Во время сеанса RTP каждый участник сеанса периодически отправляет контрольные пакеты RTCP всем другим участникам.Каждый пакет RTCP не инкапсулирует звуковые данные или телевизионные данные, но инкапсулирует статистические отчеты на принимающей стороне (и / или) принимающей стороне. RTCP также передается с использованием UDP.
В соответствии с передаваемой управляющей информацией пакеты RTCP можно разделить на пять категорий: RR (пакет отчета о приемнике), SR (пакет отчета об источнике), SEDS (пакет описания источника), BYE (объявление о выходе) и APP (пакет специального приложения) учебный класс:
SDES（Source Description Items）
Отправка пакета конечного отчета, используемого для отправки и получения статистической информации об активных источниках;
Группа отчетов отправителя SR (Sender Report) используется для того, чтобы отправитель мог сообщать о статусе отправки всем получателям многоадресным способом. Основным содержимым пакета SR являются: SSRC (источник синхронизации определения) соответствующего потока RTP, отметка времени и NTP пакета RTP, вновь сгенерированного в потоке RTP, количество пакетов, включенных в поток RTP, и количество байтов, включенных в поток RTP. Пакет SR инкапсулирован, как показано ниже:
Версия (V): То же, что поле заголовка RTP.
Заполнение (P): То же, что поле заголовка RTP.
Счетчик отчета о приеме (RC): 5 битов, количество блоков отчета о приеме в этом пакете SR может быть нулевым.
Тип пакета (PT): 8 бит, пакет SR равен 200.
Длина: 16 бит, где общая длина пакета SR в единицах по 32 бита уменьшается на единицу.
Источник синхронизации (SSRC отправителя): идентификатор источника синхронизации отправителя пакета SR. То же, что SSRC в соответствующем RTP-пакете.
NTP Timestamp (Сетевой протокол времени) Абсолютное значение времени при отправке пакета SR. Роль NTP заключается в синхронизации различных потоков мультимедиа RTP.
Отметка времени RTP: соответствует отметке времени NTP и имеет ту же единицу и случайное начальное значение, что и отметка времени RTP в пакете данных RTP.
Количество пакетов отправителя: общее количество пакетов данных RTP, отправленных отправителем в течение периода от начала отправки пакета до генерации этого пакета SR. Это поле очищается при изменении SSRC.
Число октетов отправителя: общее количество байтов данных полезной нагрузки, отправленных отправителем (исключая заголовок и заполнение) с момента отправки пакета до формирования пакета SR. Когда отправитель меняет свой SSRC, это поле должно быть очищено.
SSRC-идентификатор источника синхронизации n: этот блок отчета содержит статистическую информацию о пакетах, полученных из этого источника.
Потерянная скорость (Fraction Lost): указывает потерю пакетов RTP из источника синхронизации n (SSRC_n) с момента отправки последнего пакета SR или RR.
Накопленная потеря пакетов: общее количество пакетов RTP, потерянных от SSRC_n с начала приема пакета SSRC_n до отправки SR.
Получен расширенный максимальный порядковый номер: максимальный порядковый номер в пакете RTP, полученном от SSRC_n,
Полученный джиттер (Interarrival jitter): статистическая оценка дисперсии времени приема пакета RTP
Отметка времени последнего SR (Last SR, LSR): возьмите средние 32 бита отметки времени NTP в пакете SR, недавно полученном от SSRC_n. Если пакет SR не был получен, поле очищается.
Задержка с момента последнего SR (Задержка с момента последнего SR, DLSR): задержка с момента последнего получения SSRC_n пакета SR для отправки этого отчета.
Пакет отчетов приемника, используемый для получения статистической информации о неактивных станциях;
Пакет отчета источника SR и пакет отчета приемника RR используются для обеспечения обратной связи по качеству приема,В дополнение к коду типа пакета единственное различие между SR и RR состоит в том, что исходный отчет содержит 20-байтовый раздел информации об отправителе.Для каждого источника RR предоставляет информацию, такую как количество потерянных пакетов, максимальное порядковое число принятых пакетов, дрожание времени прибытия, время для приема последнего SR и задержка для приема последнего SR. SR не только предоставляет информацию обратной связи о качестве приема (так же, как RR), но также предоставляет идентификатор SSRC, временную метку NTP, временную метку RTP, количество отправленных пакетов и количество отправленных байтов. В зависимости от того, является ли получатель отправителем, чтобы решить, использовать ли пакеты SR или RR, активный источник отправляет SR после отправки последнего пакета или в течение интервала между предыдущим пакетом и следующим пакетом, в противном случае он отправляет RR; пакеты как SR, так и RR Может быть несколько блоков отчета о приеме без блока отчета о приеме, и источник, указанный в его отчете о выпуске, не обязательно является действующим источником в списке CSRC, и каждый блок отчета о приеме предоставляет статистику данных, принятых из конкретного источника. Может быть не более 31 блока отчетов о приеме, встроенных в пакеты SR или RR. Разница в совокупном количестве потерянных пакетов дает количество пакетов, потерянных в течение интервала, а разница в серийных номерах дает количество пакетов, ожидаемых для отправки в течение интервала. Соотношение двух равно Процент потери пакетов в течение интервала. На основании информации об отправителе сторонний монитор может рассчитать среднюю скорость передачи данных нагрузки и среднюю скорость передачи пакетов за неполученный интервал данных. Соотношение между ними дает средний размер загрузки. Если предполагается, что потеря пакета не имеет никакого отношения к размеру пакета, количество пакетов, полученных конкретным приемником, дает видимый трафик, полученный этим приемником.
3、SDES：
Пакет описания источника для отчетов и информации, связанной с сайтом, включая CNAME;
Пакет описания источника SDES предоставляет интуитивно понятную текстовую информацию для описания участников сеанса, включая CNAME, NAME, EMAIL, PHONE, LOC и другие элементы описания источника, что позволяет получателю получить информацию об отправителе. Пакет SDES состоит из заголовка пакета и блока данных. Блок данных может отсутствовать или быть множественным. Заголовок пакета состоит из версии (V), заполнения (P), указания длины, типа пакета (PT) и количества источников (SC). PT занимает 8 битов и используется для идентификации пакетов RTES SDES. SC занимает 5 битов и указывает количество блоков SSRC / CSRC, содержащихся в пакете SDES. Нулевое значение является действительным, но не имеет значения. Блок данных состоит из элементов описания источника. Содержимое элементов описания источника выглядит следующим образом:
CNAME: стандартная идентификация терминала, элемент SDES
Подобно логотипу SSRC, RTCP назначает уникальный логотип CNAME каждому участнику подключения RTP. Когда возникает конфликт или программа перезапускается, поскольку случайно назначенный идентификатор SSRC может измениться, элемент CNAME может обеспечить привязку идентификатора SSRC к идентификатору источника, который все еще остается постоянным.
Чтобы облегчить сторонний мониторинг, CNAME должен подходить для программ или персонала, чтобы найти источник.
NAME: имя пользователя, элемент SDES
Это реальное имя, используемое для описания источника, например «Джон Доу, Бит Рециклер, Мегакорп», которое может быть любой формы, которую хочет пользователь. Поскольку текстовая информация используется для описания, для приложений, таких как конференции, участники могут быть непосредственно отображены в списке. Элемент NAME является наиболее часто отправляемым элементом, кроме элемента CNAME. Значение NAME должно оставаться постоянным во время сеанса RTP, но оно не должно быть единственной зависимостью среди всех подключенных участников.
EMAIL: адрес электронной почты SDES item
Формат адреса электронной почты определяется RFC822, например, «[email protected]». Во время сеанса RTP содержимое элемента EMAIL надеется остаться неизменным.
ТЕЛЕФОН: Номер телефона SDES пункт
LOC: пользовательский географический элемент SDES
В зависимости от приложения этот элемент имеет разные уровни детализации. Для приложений конференции достаточно такой строки, как «Мюррей Хилл, Нью-Джерси». Однако для активных систем маркировки могут применяться строки символов, такие как «Room 2A244, AT & T BL MH». Детали оставлены для реализации или пользователей, но формат и содержание могут быть установлены инструкциями. Ожидается, что во время сеанса RTP, за исключением мобильного хоста, значение LOC останется неизменным.
ИНСТРУМЕНТ: название приложения или инструмента
Элемент TOOL содержит строку, которая представляет имя и версию приложения, сгенерировавшего поток, например «videotool 1.2». Эта часть информации полезна для отладки, аналогично заголовку SMTP почты или версии почтовой системы. Значение TOOL остается неизменным во время сеанса RTP.
ПРИМЕЧАНИЕ: элемент SDES уведомления / статуса
Элемент NOTE предназначен для описания информации о переходе текущего состояния источника, например, «по телефону, не могу говорить», или темы, используемой для передачи разговора во время лекции, его синтаксис может быть явно определен в настройках. Элемент ПРИМЕЧАНИЕ, как правило, используется только для переноса информации об исключениях и не должен включаться во всех участников, поскольку это снизит скорость получения отчетов и отправки CNAME и повредит выполнению соглашения. Как правило, элемент NOTE не используется как элемент в файле настроек пользователя, и при этом он не создается автоматически.
Поскольку элемент NOTE очень важен для отображения, когда участники сеанса активны, скорость передачи других элементов, отличных от CNAME (таких как NAME), будет уменьшена, в результате чего элемент NOTE будет занимать часть полосы пропускания RTCP. Если информация перехода не активна, элемент NOTE продолжает отправляться несколько раз с той же скоростью, и получатель уведомляется строкой нулевой длины строки.
PRIV: специальный расширенный пункт SDES
Обратите внимание, что префикс должен быть максимально коротким. Префикс PRIS SDES не зарегистрирован в IANA. Если подтверждается, что некоторые формы элементов PRIV являются универсальными, IANA должна назначить ему формальный тип элемента SDES, чтобы префикс не требовался, что упрощает применение и повышает эффективность передачи.
Если микшер принимает пакет BYE, микшер пересылает пакет BYE без изменения логотипа SSRC / CSRC. Если микшер выключен, он должен выдать пакет BYE перед закрытием, перечисляя все источники, обработанные микшером, а не только его собственный идентификатор SSRC. Как вариант, пакет BYE может включать 8-значный восьмеричный счет, за которым следует текстовое сообщение с указанием причины ухода, например: «cameramalfunction» или «RTPloop обнаружено». Кодировка строки символов такая же, как описано в пункте SDES. Если строковая информация достигает конца 32-битной границы в пакете BYE, строка не заканчивается нулем, в противном случае пакет BYE заполняется пустым восьмеричным.
Пакет APP используется для разработки новых приложений и экспериментов с новыми функциями и не требует регистрации значений типа пакета. Пакеты APP с неузнаваемыми именами следует игнорировать. После проверки, если определено, что она широко используется, рекомендуется переопределить каждый пакет APP без регистрации сегмента подтипа и имени в IANA.
Примените определенные функции.
резюме:
RTSP отвечает за установление и контроль сеансов, RTP отвечает за передачу мультимедиа, RTCP сотрудничает с RTP для контроля и статистики трафика, и они находятся в кооперативных отношениях.
Четыре, протокол SDP
SDP обычно включает в себя следующие аспекты:
(1) Название и цель сеанса
(2) Время выживания сеанса
(3) Медиа-информация, включенная в сеанс, включая: тип медиа (видео, аудио и т. Д.), Протокол передачи (RTP / UDP / IP, H.320 и т. Д.), Медиа-формат (видео H.261, видео MPEG и т. Д.) ), Multicast или удаленный (unicast) адрес и порт
(4) Информация, необходимая для получения медиа (адреса, порты, форматы и т. Д.)
(5) Используемая информация о пропускной способности
(6) Надежная контактная информация (Контактная информация)
Описание каждого поля:
1.Версия (обязательно)
2. происхождение (обязательно)
Инициатор сеанса описан:
: это числовая строка. Он должен быть уникальным на протяжении всей сессии. Для обеспечения его уникальности рекомендуется использовать временную метку NTP (сетевой протокол времени).
: версия объявления сеанса, чтобы прокси-сервер объявлений мог определить, какие объявления того же сеанса являются последними. Основным требованием является увеличение значения версии после изменения данных сеанса. Рекомендуется использовать временную метку NTP.
: тип сети, обычно «IN», что означает «интернет»
: тип адреса, обычно IP4
3. Название сеанса (обязательно)
Имя сеанса, есть только один «s =» во всем сеансе.
4. Данные подключения (необязательно)
Он представляет информацию о соединении СМИ. Например: c = IN IP4 224.2.1.1/127
В операторе сеанса должен быть элемент «c =» в описании уровня сеанса или элемент «c =» в каждом описании уровня медиа. В описании уровня сеанса и каждом описании уровня мультимедиа может быть элемент «c =».
: тип сети, обычно «IN», что означает «интернет»
: тип адреса, обычно IP4.
: приложение должно иметь дело как с доменным именем, так и с IP-адресом. Для одноадресной передачи это имя домена или IP-адрес. Рекомендуется использовать имя домена. Многоадресная передача является IP-адресом, и за IP-адресом должен быть TTL (диапазон значений 0-255). Адрес и TTL определяют область распространения многоадресного пакета, подлежащего распространению. пример:
5. Пропускная способность (необязательно)
Информация о пропускной способности, единица измерения килобит в секунду.
: включает в себя два типа CT и AS. CT: ConferenceTotal, общая пропускная способность. AS: Application-SpecificMaximum, максимальное значение одной полосы пропускания мультимедиа.
6. Время (обязательно), время повтора и часовые пояса
Описывает время начала и время окончания сеанса.
7. Объявления для СМИ (обязательно)
Название СМИ и адрес передачи. Описание мультимедиа начинается с «m =» и заканчивается следующим «m =».
: указывает тип медиа. Существуют «аудио», «видео», «приложение» (например, информация на доске), «данные» (данные, не отображаемые пользователю) и «управление» (описывает дополнительные каналы управления).
: порт, где медиапоток отправляется на транспортный уровень. Зависит от типа сети, указанного в строке c = и следующего протокола транспортного уровня: 1024-65535 для UDP, даже для RTP. Когда многоуровневый кодированный поток отправляется на адрес одноадресной рассылки, необходимо указать несколько портов. Способ заключается в следующем:
Для RTP четные порты используются для передачи данных, а нечетные порты используются для передачи пакетов RTCP. пример:
: протокол передачи, связанный с типом адреса строки c =. Два типа: RTP / AVP, что означает транспортный протокол реального времени с использованием профиля аудио / видео, передаваемого по UDP;
m=audio49232 RTP/AVP 0
Пример динамического связывания: 16-разрядное линейное кодирование с частотой дискретизации 16 кГц. Если мы хотим, чтобы динамический RTP / AVP тип 98 представлял этот поток, он записывается следующим образом:
m=video49232 RTP/AVP 98 a=rtpmap:98 L16/16000/2
8. rtpmap (необязательно)
0 или более строк атрибутов сеанса: a = rtpmap: / [/ ]
9. Предлагаемые атрибуты (необязательно)
Для аудио a = частота кадров: 50 1 байт * 8000 Гц * 20 мс = 160 B
Тогда объем аудиоданных для каждого пакета rtp составляет 160 В. Приращение временной метки составляет 160
a = lang: // Язык описания сеанса по умолчанию или язык описания мультимедиа
Замечания:Если анализатор SDP не может распознать определенный тип, все описание теряется.
Если значение атрибута «a =» не понято, атрибут будет потерян.
Описание уровня сеанса является значением по умолчанию описания уровня мультимедиа (то есть описание уровня мультимедиа фактически является описанием уровня сеанса, но используются значения по умолчанию параметров описания уровня сеанса, которые не записаны).
Интеллектуальная рекомендация
Совместное использование сухих товаров GitHub (высокая степень интеграции страницы руководства APP-DHGuidePageHUD)
Каждое приложение будет использовать страницу руководства APP, которая не важна, но обязательна. Будь то первая установка приложения или обновление версии, это единственное, что будет показано пользов.
Организуйте некоторые элементы управления диаграммами, которые можно использовать в веб-разработке, в основном для клиентских реализаций, таких как Flash, JavaScript, Silverlight; если для создания ст.