rtp протокол что это
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.
Внутренности протокола, которым браузеры передают голос и видео
WebRTC, технология голосовых и видеозвонков в браузерах (а еще realtime передачи произвольных данных, peer-to-peer пробивания NAT и захвата экрана) никогда не была простой. Долгая история, несовместимости между браузерами, запутанная документация, множество решаемых задач и используемых протоколов. Возможность позвонить и принять звонок из браузера всегда была одной из ключевых «фишек» нашей платформы Voximplant, и так как мы в этом неплохо разбираемся, то стараемся следить за интересными статьями и адаптировать их для аудитории Хабра. Под катом перевод свежей статьи от ребят из callstats.io — сервиса сбора статистики по качеству звонков для браузера. В небольшой статье они рассказывают о протоколе RTP с помощью которого, собственно, браузер и передает пакеты с голосом или видео.
WebRTC использует протокол SRTP (Secure Real-time Transport Protocol), чтобы обеспечить шифрование, аутентификацию и целостность сообщений, а также защитить RTP-данные от атак повторного воспроизведения. Это система безопасности, которая дает конфиденциальность за счет шифрования RTP-нагрузки и проверки подлинности. Эти фишки безопасности в WebRTC – ключевой момент надежности и основа для всего, что касается RTP (Real-time Transport Protocol). Но что такое RTP, как оно работает?
Что такое RTP?
RTP это сетевой протокол, спроектированный для мультимедийных коммуникаций (VoIP, видеоконференции, телепрезентации), потоковой передачи мультимедиа (видео по запросу, прямые трансляции) и широковещательное медиа. Протокол был определен организацией IETF (Internet Engineering Task Force) в стандарте RFC1889. Изначально RTP создали для поддержки видеоконференций, в которых есть географически распределенные участники, разработку вела рабочая группа IETF по аудио- и видеотранспорту. На текущий момент, версия v2 из стандарта RFC3550 используется уже 15 лет!
В основе RTP лежат фундаментальные принципы формирования фреймов на уровне приложения и их обработки на уровне протокола. RTP описывает типы медиа данных и «полезной нагрузки» пакетов, механизм синхронизации медиапотоков, объясняет что делать с потерянными и перепутанными пакетами, как отслеживать состояние передаваемых медиаданных.
Для получения информации о качестве медиапотока внутри RTP используется «вложенный» протокол RTCP (RTP Control Protocol).
При использовании RTP отправляющая сторона упаковывает медиапоток в формат RTP пакетов и время от времени отсылает «RTCP Sender Report» для синхронизации медиапотоков между собой. Принимающая сторона организует «Jitter buffer» для сбор получаемых пакетов в правильном порядке и воспроизведения медиапотока в соответствии с информацией о таймингах, указанной в полученных пакетах. Если пакет теряется, то получающая сторона по возможности получает его еще раз или же “скрывает” проблему, интерполируя звук или разбивая видео на цветные квадратики. И, наконец, принимающая сторона передает в обратную сторону грубую или детальную статистику с помощью “RTCP Receiver Report”. Статистика позволяет отправителю выбирать битрейт, менять кодеки и выбирать объем коррекции ошибок.
Формат заголовка пакета RTP
Заголовок RTP пакета разделен на 4 части: источник синхронизации, метка времени, порядковый номер и тип полезной нагрузки.
1. Источник синхронизации. Позволяет определить, откуда идет медиапоток. Особенно полезно, когда источник отсылает несколько медиапотоков, которые надо синхронизировать.
2. RTP метка времени позволяет собирать из RTP пакетов медиа фреймы и воспроизводить медиапоток.
3. RTP порядковый номер: он и в африке порядковый номер, с его помощью находятся потерянные пакеты, а те что не потеряны — выстраиваются по порядку. UDP все-таки.
4. Тип полезной нагрузки определяет кодировку медиа данных в пакетах, его указывает кодек.
Отчеты RTCP
Известные в спецификации как «RTCP Reports», бывают трех типов: «Sender Reports» для отправителя, «Receiver Reports» для получателя и «Extended Reports» для всех участников процесса.
RTCP Sender Reports
Используются отправляющей стороной для синхронизации медиапотоков. Метки времени всех отправляемых потоков устанавливаются относительно часов этого компьютера, так что принимающая сторона понимает как потоки нужно воспроизводить друг относительно друга. В этом же отчете указывается количество отправляемых в секунду пакетов и байт.
RTCP Receiver Reports
Принимающая сторона осматривает получаемые потоки и отчитывается о происходящем с помощью пакетов «RTCP Receiver Report». В отчете указывается текущий уровень потерь пакетов, джиттер (буфер, в котором хранятся пакеты перед проигрыванием, чтобы подождать опоздавших и поменять местами запутавшихся), максимальный порядковый номер. Часть этих данных используется для расчета round trip time.
RTCP Extended Reports
Используются как отправляющей, так и принимающей стороной для передачи сложных метрик о происходящем между ними. К таким метрикам относится производительность самих компьютеров, состояние сети, джиттер буфера, вариации в задержках пакетов, просто информация о задержках, количество не обработанных пакетов, QoS и другие. Также в этот пакет можно добавлять собственные метрики, так что обе стороны могут отслеживать специфичные для приложения параметры.
Как выглядят форматы полезной нагрузки для RTP?
«Формат полезной нагрузки», payload format, задается такой штукой, которая в спецификации называется «кодированием», encoding. Непереводимая на русский игра слов описыват три варианта. Это может быть кодек, например H.264, H.263, H.261, MPEG-2, JPEG, G.711, G.722 или AMR. Это может быть «полезная нагрузка общего назначения», такая как «Forward Error Correction» (FEC), NACK и другие страшные акронимы. И, наконец, это могут быть мультиплексированные медиапотоки (несколько медиапотоков в рамках одного).
Спецификация жестко задает формат для кодеков и определяет два правила: агрегации и фрагментации. Правила агрегации описывают, как RTP работает с кодеками, которые производят пакеты меньше MTU — например, звуковыми кодеками. Правила фрагментации, наоборот, описывают работу с кодеками, предпочитающими большие пакеты, например пакеты с I-фреймами видеокодирования. RTP задает собственное фрагментирование, потому что IP фрагментирование для UDP как правило не работает, и NAT’ы с Firewall’ами просто молча дропают такие пакеты.
Для чего в RTP используются «Header Extensions»?
«Расширения» заголовков пакетов используются для информации, не имеющей отношения к медиапотокам. Обычно это та информация, которую нужно передавать в реальном времени — чаще, чем отсылаются RTCP отчеты.
Например, для интерактивных медиапотоков (видеочат?) RTP пакеты отправляются каждые несколько десятков миллисекунд. Расширение к RTP заголовкам может использоваться для индикации потерянных и полученных пакетов — чтобы реагировать быстрее, чем это позволяют получаемые время от времени RTCP отчеты с NACK/ACK.
Расширение заголовков обратно совместимо: если один из участников передачи данных не понимает этот формат, то он будет просто игнорировать соответствующую часть заголовка пакета. Заголовки описаны в спецификации как штука «общего назначения» и их не нужно отдельно указывать для каждого используемого кодека.
Они часто используются для передачи состояния сети и таких специфичных для приложения штук как громкость звука для нескольких каналов в конференции.
Что такое «отчетный интервал» для RTCP?
Использование протокола RTP выглядит как замкнутый цикл: мы отправляем RTP пакеты и получаем RTCP пакеты с обратной связью. Почти как TCP с его ACK. Обычно отчетный интервал выбирается так, чтобы объем передаваемых пакетов RTCP был гораздо меньше, чем объем передаваемых медиаданных. Выбор происходит на основании количества потоков, которые нужно синхронизировать, и ширины канала.
Теоретически, ширина канала должна равномерно делиться по участникам (аудио или видео конференции). На практике приложения рассчитывают ширину исходя из предполагаемого количества одновременно активных участников. Например, для аудиоконференции это обычно один участник: если несколько людей начнут говорить одновременно, то никто ничего не поймет. А вот для видеоконференции все сложнее: показывать видео с нескольких участников это вполне популярный сценарий. В таких ситуациях отчетный интервал рассчитывается индивидуально для каждого участника.
5% ширины канала выделяется для RTCP пакетов.
Для сценариев с большим количеством принимающих устройств и малым количеством отправляющих устройств (вебинар, голосовая конференция) четверть канала для отчетов равномерно распределяется для передающих устройств, а оставшиеся три четверти для принимающих. Такое распределение позволяет новым подключившимся устройствам быстро получить CNAME и метки времени для синхронизации. А чтобы новые подключившиеся устройства могли быстро передать информацию о себе, интервал отправки RTCP пакетов для них выбирается в два раза меньше, чем для остальных участников.
Рекомендованный минимальный интервал отправки RTCP пакетов составляет 5 секунд.
Это значение может быть уменьшено до 360 / ширина канала (в секундах) для ситуаций, когда данные передаются в обе стороны и нужно быстро передавать дополнительную информацию для управления потерями пакетов.
Расширенный профиль RTP для обратной связи с помощью RTCP
Если клиент замечает потери пакетов или проблемы с сетью, то он не может сразу отослать RTCP пакет и должен подождать окончания интервала. А там, на секундочку, 5 секунд. Для решения вопроса в спецификации есть «Extended RTP Profile for RTCP-Based Feedback» — это расширение правил RTP о таймингах.
Если оба устройства поддерживают такой профиль, то они могут договориться отсылать RTCP пакеты чаще, чем положено по спецификации. До тех пор, пока средняя скорость отправки пакетов укладывается в специфицированный интервал. Это же расширение описывает несколько дополнительных сообщений, которые клиенты могут использовать для описания происходящего с медиаданными: Negative Acknowledgement (NACK), Picture Loss Indication (PLI), Slice Loss Indication (SLI) и Reference Picture Selection Indication (RPSI).
Национальная библиотека им. Н. Э. Баумана
Bauman National Library
Персональные инструменты
RTP (Real-time Transport Protocol)
RTP (Real-time Transport Protocol) — протокол передачи данных, работает на прикладном уровне и используется при передаче трафика реального времени. Впервые опубликован в 1996 году, выведен из употребления в 2003 году.
Содержание
Описание протокола
RTP был разработан как протокол для передачи потоковых данных в режиме реального времени по технологии end-to-end. Рассматривался как основной стандарт для передачи голоса и видео в IP-сетях. В протокол заложена возможность компенсации джиттера и обнаружения нарушения последовательности пакетов данных — типичных событий при передаче через IP-сети. RTP поддерживает передачу данных для нескольких адресатов через Multicast.
Основное отличие RTP от TCP состоит в том, что TCP позволяет себе временную задержку ради полной достоверности передаваемых данных, в то время как RTP допускает некоторую потерю пакетов ради оперативной доставки информации в режиме реального времени. Поэтому большинство реализаций RTP базируются на UDP.
Компоненты протокола
Спецификация RTP описывает два подпротокола:
Структура пакета
0-1 — Ver. (2 бита) указывает версию протокола. Текущая версия — 2.
2 — P (один бит) используется в случаях, когда RTP-пакет дополняется пустыми байтами на конце.
3 — X (один бит) используется для указания расширений протокола, задействованных в пакете.
4-7 — CC (4 бита) содержит количество CSRC-идентификаторов, следующих за постоянным заголовком.
8 — M (один бит) используется на уровне приложения и определяется профилем. Если это поле установлено, то данные пакета имеют какое-то особое значение для приложения.
9-15 — PT (7 бит) указывает формат полезной нагрузки и определяет её интерпретацию приложением.
64-95 — SSRC указывает источник синхронизации.
EHL (Extension Header Length) — — количество 32-битных слов в блоке данных расширения заголовка.
L — последний байт в пакете, определяющий длину области заполнения в байтах (используется для выравнивания в последнем пакете).