NetBash shop
Login

IP-телефония в компьютерных сетях

VLAN на основе портов и протоколов
    SIP

    Запросы и ответы SIP имеют одинаковый базовый формат сообщения. Сообщение состоит из: start-line( Status Line )
    message-header
    CRLF
    message-body
    Запросы и ответы SIP отличаются содержанием стартовой строки.
    Стартовая строка включает строку запроса (Request-Line), которая содержит имя метода (Method), URI запроса (Request-URI) и версию протокола (SIP-Version)

    Источник: https://learn.dlink.ru/course/view.php?id=155

    Запрос и ответ, описание, спецификация

    RFC 3261 INVITE - запрос(первое сообщение), отправляемый клиентом пользовательского агента (UAC) серверу для инициализации сеанса связи с другим пользователем(или услуго й).
    RFC 3261 ACK - ответ(последнее сообщение в процессе трехстроннего рукопожатия), отправляемый клиентом пользовательского агента (UAC) серверу для подтверждения вызова
    RFC 3261 OPTIONS - запрос информации о функциональных возможностях пользовательского агента (UA) адресата
    RFC 3261 BYE - запрос завершения сеанса связи
    RFC 3261 CANCEL - отмена вызова в стадии установления
    RFC 3261 REGISTER - запрос регистрации пользовательского агента (UA) на сервере
    RFC 6086 INFO - запрос, предназначенный для обмена сигнальной информацией в процессе установления и поддержания соединения
    RFC 3428 MESSAGE - переносит мгновенное сообщение в теле запроса
    RFC 3265 SUBSCRIBE - запрашивает текущее состояние и информацию об обновлениях состояния удаленного ресурса
    RFC 3428 NOTIFY - передает информацию об изменении состоянии ресурса
    RFC 3262 PRACK - ответ сообщающий о состоянии обработки запроса
    RFC 3515 REFER - получатель должен отправить вызов третьей стороне
    RFC 3311 UPDATE - запрос изменения параметров сеанса связи

    Если сообщение является ответом, тогда в качестве стартовой строки будет использоваться строка состояния (Status-Line), которая включает в себя версию протокола (SIP-Ver sion), числовой код состояния (Status-Code), текст причины (Reason-Phrase)
    Код состояния — трехзначное число, которые идентифицируют ответ. Всего существует 6 классов ответов. Ответы делятся на два типа
    Информационные ответы:
    180 Ringing - Звонок. Пользовательский агент (UA), получивший запрос INVITE, пытается оповестить пользователя
    181 Call Is Being Forwarded - Вызов переадресован. Сервер уведомляет, что вызов переадресован в другие пункты назначения
    182 Queued - Вызов поставлен в очередь. Вызываемая сторона временно недоступна, но сервер решил поставить вызов в очередь, а не отклонить его
    183 Session Progressing - прогресс сеанса связи. Ответ используется для передачи информации о ходе вызова
    200 OK - запрос успешно выполнен
    202 Accepted - запрос принят для обработки
    300 Multiple Choices - перенаправление вызов - множественный выбор
    302 Moved Temporarily - пользователь временно сменил местоположение
    305 Use Proxy - используется прокси-сервер. Вызываемый пользователь доступен через прокси-сервер
    380 Alternative Service - запрошенная услуга недоступна, но есть альтернативная услуга
    400 Bad Request - ошибка запроса, неизвестный запрос. Запрос не распознан
    401 Unauthorized - неавторизованный. Требуется аутентификация пользователя
    402 Payment Required - требуется оплата. (Зарезервировано)
    403 Forbidden - запрещенно. Сервер понял запрос, но отказывается его выполнять
    404 Not Found - пользователь не существует в домене, указанном в URI запроса
    405 Method Not Allowed - метод не разрешен. Метод, указанный в строке запроса, понятен, но не разрешен
    406 Not Acceptable - недопустимо
    407 Proxy Authentication Required - требуется аутентификация на прокси-сервере, похож на 401 Unauthorized
    408 Request Timeout - время обработки запроса истекло, сервер не мог выдать ответ в течение определенного времени
    410 Gone - Запрошенный адрес больше недоступен на сервере
    413 Request Entity Too Large - размер запроса слишком велик для обработки на сервере
    414 Request-URI Too Long - URI запроса слишком велик для обработки на сервере
    415 Unsupported Media Type - неподдерживаемый тип мультимедиа
    416 Unsupported URI Scheme - неподдерживаемый синтаксис URI
    420 Bad Extension - сервер не распознал расширение протокола SIP. 421 Extension Required - в заголовке запроса не указано расширение пользовательского агента (UAS) для обработки
    423 Interval Too Brief Интервал слишком короткий
    480 Temporary Unavailable - связь с вызываемым абонентом установлена успешно, но вызываемый абонент в недоступен
    481 Call/Transaction Does Not Exist Звонок/транзакция не существует
    482 Loop Detected - обнаружен замкнутый маршрут передачи запроса
    483 Too Many Hops - слишком много пересылок
    484 Address Incomplete - cервер получил запрос с неполным URI
    485 Ambiguous - адрес вызываемого пользователя неоднозначен
    486 Busy Here - абонент занят
    487 Request Terminated - запрос был прерван запросом BYE или CANCEL
    491 Request Pending - запрос ожидает выполнения
    493 Undecipherable - неразборчивый
    501 Not Implemented - ошибка сервера, сервер не поддерживает функции, необходимые для выполнения запроса
    502 Bad Gateway - неизвестный шлюз
    503 Service Unavailable - сервер временно не может обработать запрос из-за временной технической проблемы
    504 Server Time-out - сервер не получил своевременный ответ от внешнего сервера в попытке обработать запрос
    505 Version Not Supported - сервер не поддерживает версию протокола SIP
    513 Message Too Large - сообщение слишком большое
    600 Busy Everywhere - глобальная проблема, занято везде, связь с системой вызываемого абонента установлена успешно, но вызываемый абонент занят
    603 Decline - вызываемый абонент не желает принимать входящие вызовы, не указывая причину отказа
    604 Does Not Exist Anywhere - вызываемый абонент не существует
    606 Not Acceptable - связь с пользовательским агентом (UA) была успешно установлена, но некоторые аспекты описания сеанса не допустимы

    Источник: https://learn.dlink.ru/course/view.php?id=155

    Поля заголовка содержат отправителя, адресат, пути следования и др., т.е.
    Поля заголовка To, From, CSeq, Call-ID, Max-Forwards, Via обязательны для всех SIP-запросов.
    Поле Via (Через) содержит список всех элементов сети SIP, через которые прошел запрос, он нужен для того, чтобы запрос пошел по замкнутому пути и для того чтобы запрос и ответ обязательно проходили по одному и тому же пути. Каждый элемент добавляет поле со своим адресом.
    Параметр branch в поле заголовка Via служит для идентификации транзакции и используется прокси-серверами для обнаружения петель
    Поле Max-Forwards служит для ограничения количества переходов в пути. Если значение Max-Forwards достигает 0 до того, как запрос достигнет места назначения, он будет отклонен, будет отправлено сообщение с ошибкой 483 (Too Many Hops)
    Поле From содержит идентификатор инициатора запроса (адрес записи пользователя, URI отправителя запроса и возможно имя пользователя
    Поле To (Кому) указывает логического получателя запроса или адрес вызываемого пользователя
    Поле Call-ID (Идентификатор вызова) идентифицирует конкретное приглашение, он должен быть одинаковым для всех запросов и ответов, отправляемых любым пользовательским агентом
    Поле CSeq (Номер последовательности) содержит порядковый номер сообщения и метод, породивший транзакцию
    Поле From ответа должно совпадать с From запроса. Поле Call-ID ответа должно соответствовать полю Call-ID запроса. Поле CSeq ответа должно соответствовать полю CSeq запроса. Значение поля Via в ответе должно соответствовать полю Via в запросе
    Тип тела ответа определяет метод запроса и код состояния ответа
    Тип медиаданных тела сообщения должен быть указан в поле Content-Type
    Content-Encoding - поле тип кодирования

    Источник: https://learn.dlink.ru/course/view.php?id=155

    Прокси

    user agent, UA — пользовательский агент, который может быть как клиентом так и сервером.
    Это может быть оконечная система, например IP-телефон, софтфон или голосовой шлюз
    user agent client ( SIP-клиент ), UAC - клиент, который генерирует запросы
    user agent server, UAS - сервер, который отвечает на поступающие запросы
    UAC может генерировать запрос после внешнего воздействия ( например нажатие кнопки )
    Сообщение SIP — это запрос от UAC к UAS, или ответ UAS элементу UAC.
    UAC запрос может проходить через несколько прокси-серверов, которые перенаправляют запрос к UAS
    Ответы должны маршрутизироваться через те же прокси-сервера, в обратном порядке.
    Прокси-сервер может хранить состояние (stateful mode) или нет (stateless mode) для каждого запроса
    Без сохранения состояния прокси просто ретранслирует запросы и ответы
    Прокси с сохранением состояния хранит в памяти входящий запрос. Запросы хранятся в памяти сервера только до окончания транзакции

    Функции, выполняемые прокси-сервером можно обобщить следующим образом:
    Маршрутизация — определение получателя вызова, поиск маршрута для отправки сообщения
    Безопасность — с помощью функций контроля доступа прокси-сервер авторизует доступ к той или иной услуге или ресурсу
    Дополнительные услуги — перенаправление вызова, уведомление о пропущенных вызовах и др.
    Как устройство пользователя узнает адрес или доменное имя прокси-сервера? Поставщик услуг IP-телефонии или администратор сети сообщает IP-адрес или домен прокси-сервера пользователям. Этот IP-адрес или домен указывается в настройках каждого телефона или голосового шлюза. IP-адрес также может быть получен динамически с помощью DHCP Options 120, если взаимодействующие устройства его поддерживают. При необходимости аутентификации на прокси-сервере на устройстве указывается логин и пароль учетной записи SIP.
    Прежде чем переслать запрос, прокси-сервер должен определить, где находится вызываемый пользователь
    Обмен сообщениями происходит не между устройствами, а между зарегистрированными на SIP-сервере пользователями. При этом пользователь может одновременно использовать несколько SIP-клиентов: на мобильном телефоне, рабочем компьютере, домашнем компьютере и IP-телефоне
    Для определения места нахождения пользователя прокси-сервер обращается к абстрактной службе определения местоположения. Эта служба представляет собой базу данных, в которой хранит временную привязку SIP URI пользователя (так называемый публичный адрес пользователя) к одному или нескольким SIP URI из поля заголовка Contact
    Когда прокси-сервер будет обращаться к службе определения местоположения, она сопоставит полученный от сервера URI с пользовательским агентом(ами), рядом с которым в настоящее время находится желаемый абонент.
    Регистрация подразумевает отсылку пользовательским агентом запроса регистрации (REGISTER) на сервер регистрации (Registrar). Сервер обрабатывает запросы и предоставляет информацию из них службе определения местоположения данного домена.
    Предварительно на пользовательском устройстве надо настроить параметр SIP-ID (SIP-user) или номер, которые предоставлены администратором сети или провайдером, а также логин и пароль, если требуется аутентификация на сервере регистрации.
    Процесс регистрации происходит следующим образом:
    Клиент отправляет запрос регистрации (REGISTER) на сервер. В поле Contact указано его текущее местоположение
    В ответ сервер присылает ответ 401 Unauthorized, т.е. сообщает о необходимости аутентификации и запрашивает идентификационные данные. В поле заголовка WWW-Authenticate ответа сервер отправляет уникальный идентификатор домена realm, строку случайных чисел nonce и сообщает алгоритм хеширования, который следует использовать для подготовки ответа. Напомним, что хеш-функция — функция, отображающая данные произвольной длины в строку битов фиксированной длины, которая может использоваться для аутентификации и сходных данных. Хеш-код — это результат работы хеш-функции.
    Клиент повторно отправляет запрос регистрации, но на этот раз с полем заголовка Authorization, в котором указаны идентификационные данные. Следует отметить, что пароль не передается в открытом виде. Клиент выполняет хеш-функцию над паролем и рядом значений, включая строку случайных чисел nonce, полученную из ответа. Вычисленное значение (параметр response), свое имя, nonce и realm из полученного ответа он помещает в поле заголовка Authorization.
    Сервер проверяет идентификационные данные и выполняет хеш-функцию над nonce, паролем клиента и рядом других значений, используемых при генерации ответа. Если вычисленное и полученное значения хеш-функции совпали, аутентификация считается успешной. После этого сервер выполняет регистрацию, отправляя в ответ клиенту 200 OK.
    Приведенная схема SIP-аутентификации, которая называется Digest Authentication (RFC 8760), уязвима для атак по словарю при использовании запоминаемых паролей. Злоумышленник может получить учетные данные пользователя и далее использовать их для своих звонков. Атака направлена на получение второго запроса REGISTER с полем Authorization
    Следует отметить, что процесс регистрации не обязателен. В настройках телефона его можно отключить. Процедуру регистрации имеет смысл делать в том случае, если в сети компании используется множество телефонов и требуется маршрутизация входящих вызовов.
    В зависимости от реализации конкретной сети функции прокси-сервера и сервера регистрации может выполнять одно устройство
    При необходимости в некоторых архитектурах можно уменьшить нагрузку на прокси-серверы за счет применения перенаправления
    Источники: https://learn.dlink.ru/course/view.php?id=155

    Сервер регистрации

    Сервер переадресации (Redirect server) — это сервер пользовательского агента, который генерирует ответы с кодом 3xx на полученные запросы клиентов, направляя им в ответ информацию о маршрутизации запроса. Сам сервер перенаправления не занимается маршрутизацией пакетов к месту назначения, а только предоставляет информацию, возлагая процесс маршрутизации на клиента. Для реализации своей функции сервер переадресации должен взаимодействовать со службой определения местоположения.
    Когда отправитель запроса получает перенаправление, он отправляет новый запрос на полученный им URI

    Источник: https://learn.dlink.ru/course/view.php?id=155

    Взаимодействие двух клиентов

    Транзакция начинается с того, что пользователь Софтфона 2 (вызывающая сторона) набирает номер пользователя Софтфона 1 (вызываемая сторона). В результате этого пользовательский агент Софтфона 2 отправляет инициирующий запрос INVITE, адресованный на SIP URI Софтфона 1 (sip:11@192.168.1.10:5060). Запрос содержит поля заголовка, которые включают уникальный идентификатор вызова, адрес назначения и адрес отправителя. Также в запрос инкапсулировано сообщение протокола SDP, которое содержит информацию о сеансе связи, который Софтфон 2 хочет установить с Софтфоном 1.
    Поскольку Софтфон 2 не знает IP-адрес Софтфона 1, он отправляет инициирующий запрос не напрямую, а прокси-серверу, чей адрес указан в его настройках.
    Прокси-сервер — это логическая роль элемента SIP. Когда поступает запрос, элемент, который играет роль прокси-сервера, сначала решает, нужно ли ему ответить на запрос самостоятельно. Поэтому когда SIP-сервер получил первый запрос INVITE, он не пересылает его сразу в направлении адресата. Прежде чем он начнет действовать в качестве прокси, Софтфон 2 должен предоставить ему свои учетные данные, о чем сервер сообщает в ответе 401 Unauthorized. Другими словами, прежде чем начать обрабатывать полученный запрос, сервер должен аутентифицировать Софтфон 2.
    Софтфон 2 подтверждает, что он не авторизован, отправкой запроса ACK, вслед за которым отправляет второй запрос INVITE, содержащий идентификационную информацию в поле заголовка Authorization.
    SIP-сервер получает идентификационную информацию и проверяет ее. Проверка прошла успешно, поэтому сервер начинает действовать как прокси. Он выясняет у службы определения местоположения (может находиться на одном устройстве), где находится получатель, чтобы переслать ему приглашение на установление сеанса связи. В это же время он отправляет вызывающей стороне ответ 100 Trying (Попытка), который сообщает, что запрос INVITE был получен и прокси его обрабатывает.
    Когда прокси-сервер пересылает запрос, он добавляет свое имя (имя сервера) в начало списка в поле Via в заголовке SIP-сообщения. Это поле позволяет возвращать ответы по тому же маршруту, по которому проходил запрос. На обратном пути прокси-сервер удаляет свое имя из поля Via после обработки SIP-ответа.
    Софтфон вызываемой стороны получает INVITE и предупреждает пользователя о входящем вызове, то есть звонит. В это же время он отправляет обратно через прокси-сервер ответ 180 Ringing (Звонок).
    Когда софтфон инициатора звонка получает 180 Ringing, он передает эту информацию пользователю, используя звуковой сигнал обратного вызова или отображая сообщение на экране.
    Когда вызываемый пользователь поднимает трубку, его софтфон отправляет ответ 200 OK на запрос INVITE, чтобы сообщить, что на вызов ответили; в теле ответа указываются функциональные возможности этого клиента (сообщение протокола SDP) для согласования параметров сеанса связи. Это сообщение также передается через прокси-сервер.
    Получив сообщение 200 OK, Софтфон 2 отправляет сообщение ACK, подтверждая, что получил уведомление о снятии трубки.
    После этого начинается передача сообщений сеанса связи ( например голосовых сообщений). Эти сообщения передаются напрямую между Софтфонами 1 и 2 с помощью протокола RTP.
    Когда одна из сторон кладет трубку, отправляется сообщение BYE. Ответ 200 ОК на запрос BYE означает завершение сеанса связи.

    Источник: https://learn.dlink.ru/course/view.php?id=155

    Протокол сеанса связи

    Протокол описания сеанса (Session Description Protocol - передает информацию о медиапотоках в мультимедийных сеансах, чтобы получатели сведений о сеансе связи могли участвовать в нем. SDP — это строго описательный протокол, который используется протоколами более высокого уровня
    Описание сеанса связи SDP включает следующую информацию:
    Тип мультимедиа (аудио, видео, текст, сообщение)
    Транспортный протокол (RTP/UDP/IP и т.д.)
    Формат мультимедиа (H.261, MPEG, G.711 и т.д.)
    В дополнение к формату и транспортному протоколу, SDP описывает информацию об IP-адресе и порте. Для групповой рассылки она включает:
    Групповой IP-адрес назначения для мультимедийного потока
    Порт назначения протокола транспортного уровня для мультимедийного потока
    Для одноадресной IP-сессии сообщается:
    IP-адрес назначения для мультимедийного потока
    Порт назначения протокола транспортного уровня для мультимедийного потока.
    Описание сеанса SDP состоит из нескольких строк текста в форме:
    <тип> = <значение>
    где тип — это единственный чувствительный к регистру символ, значение — текстовая структура, чей формат зависит от типа.
    Типы описаний можно разделить на три следующих категории:
    Описание сессии (Session description)
    v= (версия протокола)
    o= (инициатор и идентификатор сессии)
    s= (имя сессии)
    i=* (информация о сессии)
    u=* (URI адрес описания)
    e=* (email)
    p=* (номер телефона)
    c=* (информация о соединении)
    b=* (0 или более строк с информацией о полосе пропускания)
    z=* (корректировка часового пояса)
    k=* (ключ шифрования)
    a=* (0 или более строк атрибутов сессии)
    Описание времени (Time description)
    t= (время активности сессии)
    r=* (0 или более повторений)
    Описание мультимедийного потока (Media description), если присутствует
    m= (название медиа и транспортный адрес)
    i=* (заголовок медиа)
    c=* (информация о соединении)
    b=* (0 или более строк с информацией о полосе пропускания)
    k=* (ключ шифрования)
    a=* (0 или более строк атрибутов сессии)
    Поля отмеченные * – необязательные
    Описание сеанса связи может содержать несколько описаний мультимедиа (Media Descriptions), которые имеют следующий формат:
    m= ...
    Каждое описание мультимедийного потока начинается с поля m= и заканчивается либо следующим полем m=, либо концом описания сеанса. Медиа-поле имеет несколько подполей:
    media — это тип медиаданных. В настоящее время определены типы «audio» (аудио), «video» (видео), «text» (текст), «application» (приложение) и «message» (сообщение). В нашем примере сообщение SDP содержит описания для двух типов медиаданных: аудио и видео.
    port — это транспортный порт, на который отправляется медиапоток. Значение транспортного порта зависит от используемой сети, как указано в поле информации о соединении c=, и от транспортного протокола, определенного в подполе protocol
    protocol — это транспортный протокол. Поле c=IP4 указывает, что транспортный протокол работает по IP4. Расшифровываются названия протоколов следующим образом:
    UDP — означает протокол UDP
    RTP/AVP: Означает использование профиля RTP для Audio and Video Conferences with Minimal Control, работающего поверх протокола UDP
    RTP/SAVP: означает Secure Real-time Transport Protocol, работающий поверх протокола UDP.
    format — это описание формата мультимедиа, т.е. схемы кодирования. Когда приводится список форматов передачи, это означает, что все они могут использоваться в сеансе, но первый из них следует использовать в качестве формата по умолчанию
    Работа протокола SDP начинается, когда один пользовательский агент отправляет первоначальное предложение другому пользовательскому агенту средствами протокола SIP.
    В предложении содержится описание сеанса, в котором агент предлагает желаемый способ коммуникации (аудио, видео, приложение, сообщение, текст) и соответствующие схемы кодирования, а также адреса для принятия определенного вида медиаданных.
    Другой пользовательский агент помещает ответ в соответствующее сообщение SIP, где перечисляет, какие из предложенных средств коммуникации приемлемы, и приводит адреса, на которых будут приниматься эти медиаданные.
    Для обмена предложением/ответом с целью установления сеанса связи может использоваться только начальная транзакция INVITE
    В процессе сеанса связи пользовательский агент может менять согласованные параметры

    Источник: https://learn.dlink.ru/course/view.php?id=155

    RTP

    Real-time Transport Protocol (RTP, транспортный протокол реального времени)
    RTP и Real-time Transport Control Protocol (RTCP, протокол управления передачей в реальном времени). Первый используется для обмена мультимедийными данными, а второй — для периодической отправки управляющей информации, связанной с определенным потоком данных.
    Хотя протокол RTP считается протоколом транспортного уровня, обычно он функционирует поверх протокола UDP. Следует отметить, что RTP и RTCP являются независимыми от нижележащих уровней — транспортного и сетевого, поэтому протоколы RTP/RTCP могут использоваться с другими подходящими транспортными протоколами.
    При работе через UDP поток данных RTP и связанный с ним поток управления RTCP используют последовательные порты транспортного уровня. Для данных RTP используется четный номер порта, а для управляющей информации RTCP используется на единицу больший (нечетный) номер порта. Четко определенных номеров портов для RTP/RTCP нет. Администратор сети может указать диапазон портов RTP в настройках устройств.
    Блоки данных протоколов RTP/RTCP называются пакетами. Пакеты, формируемые в соответствии с протоколом RTP и служащие для передачи мультимедийных данных, называются информационными пакетами или пакетами данных (data packets), а пакеты, генерируемые в соответствии с протоколом RTCP и служащие для передачи служебной информации, называют пакетами управления или служебными пакетами (control packets).
    RTP не гарантирует своевременную доставку пакетов и не сохраняет последовательность пакетов. RTP возлагает ответственность за восстановление потерянных пакетов и изменение их последовательности на приложение.
    RTP предоставляет:
    Идентификацию типа полезной нагрузки.
    Идентификацию источника
    Порядковую нумерацию
    Метку времени
    Трафик различных типов должен передаваться отдельно в разных сеансах связи RTP. Сеанс RTP обычно состоит из номера порта RTP (порта UDP), номера порта RTCP (следующего по порядку порта UDP) и IP-адреса участника. Например, в видеоконференции, составленной из аудио- и видеосигнала, кодированных отдельно, трафик каждого типа нужно передавать в отдельном сеансе RTP со своим собственным транспортным адресом назначения.
    Протокол RTP поддерживает как двустороннюю связь, так и передачу данных группе адресатов, если групповая передача поддерживается нижележащими протоколами.

    Источник: https://learn.dlink.ru/course/view.php?id=155

    Трансляторы и микшеры

    Трансляторы и микшеры - промежуточные системы на уровне RTP, предназначенные для различных целей, добавление шифрования, изменение кодировки, тип полезной нагрузки, метку времени, репликация между групповым адресом или между индивидуальными адресами. Транслятор пропускает потоки данных из разных источников по отдельности, тогда как микшер объединяет их в один новый поток.
    Транслятор передает пакеты RTP, не изменяя их идентификаторы SSRC.
    Трансляторами могут быть устройства, преобразующие кодировки без объединения потоков, репликаторы с групповой рассылки на одноадресную, фильтры уровня приложений в межсетевых экранах
    Микшер объединяет потоки данных RTP из одного или нескольких источников, возможно изменяет формат данных
    Информационные пакеты, отправленные микшером, будут содержать в поле источника синхронизации идентификатор SSRC микшера. Микшер также включает свой собственный идентификатор SSRC в список CSRC.
    Преобразователи и микшеры также должны обрабатывать пакеты RTCP

    Источник: https://learn.dlink.ru/course/view.php?id=155

    RTCP

    RTCP - протокол управления, предназначен для передачи управляющих пакетов между членами группы. Позволяет оценивать размер группы, вычислять специфичную для сеанса связи информацию, например потерю пакетов или круговую задержку
    Поток управления RTPC связан с соответствующим потоком данных RTP
    RTCP пакеты могут содержкать информацию для мониторинга качества обслуживания
    Отчет отправителя ( sender report ) и отчет получателя ( receiver report ) служат для обмена между участниками информации о потере пакетов, джиттере, например для управления потоком.
    Круговая задержка ( round trip time ) время необходимое для подтверждения, что пакет был получен
    Вариация задержки передачи пакета и джиттера (IP packet Delay Variation, IPDV или jitter) - разница между односторонней задержкой IP-пакета и эталонной задержкой доставки IP-пакета
    Пакеты описания источника (Source description, SDES) включают идентификатор транспортного уровня (называемый каноническим именем (Canonical End-Point Identifier, CNAME)) для источника RTP, который используется для отслеживания каждого участника. Эти пакеты также могут содержать другую текстовую информацию об источнике (имя пользователя, адрес электронной почты). Хотя отправитель пакетов RTP определяется идентификатором SSRC, приложение может запустить несколько потоков RTP, которые можно легко связать с этой текстовой информацией. Получатели используют CNAME для сопоставления и синхронизации различных потоков RTP, исходящих от одного и того же отправителя, например, при синхронизации аудио- и видеосигнала.
    Пакеты RTCP периодически отправляются каждым участником сеанса другим участникам в режиме многоадресной рассылки. Чем больше участников, тем большим количеством сообщений RTCP нужно обмениваться. Если не предпринять каких-либо шагов для их ограничения, они потенциально могут стать значительным потребителем полосы пропускания.

    Источник: https://learn.dlink.ru/course/view.php?id=155

    Кодеки

    Кодеки - савокупность кодера и декодера
    С точки зрения VoIP кодек это метод преобразования аналогового сигнал в цифровой и обратно
    Аудиоданные (audio data), аудиосигнал (audio signal) — аналоговый сигнал, несущий информацию об изменении во времени амплитуды звука
    Аналого-цифровой преобразователь, АЦП (analog-to-digital converter, ADC) — устройство, преобразующее входной аналоговый аудиосигнал в оцифрованные аудиоданные
    Импульсно-кодовая модуляция (Pulse Code Modulation, PCM) — метод модуляции, заключающийся в дискретизации, квантовании и цифровом кодировании исходного сигнала
    Дискретизация (sampling) — операция построения дискретного сигнала по заданному аналоговому сигналу
    Дискретный сигнал (discrete signal) — сигнал, принимающий конечные значения в некоторые дискретные моменты времени и не определенный в другие моменты времени
    Частота дискретизации (sample rate) — число отсчетов в секунду (или в другую единицу измерения), полученных из непрерывного сигнала и используемых для получения дискретного сигнала. Единица частоты дискретизации — герц (Гц)
    Квантование (quantization) — замена непрерывного интервала значений сигнала конечным множеством значений
    Цифровое кодирование (digital coding) — замена квантованных значений сигнала набором двоичных символов
    Битовая глубина (bit depth) — число битов, используемых для представления квантованных значений.
    Аналоговый сигнал — это сигнал данных, у которого каждый из представляющих параметров описывается функцией времени и непрерывным множеством возможных значений.
    Цифровой сигнал — это сигнал данных, у которого каждый из представляющих параметров описывается функцией дискретного времени и конечным множеством возможных значений. Другими словами, в отличие от аналогового сигнала, он имеет дискретное и конечное число значений между двумя любыми точками.
    В IP-телефонии широко используется импульсно-кодовая модуляция (ИКМ) (Pulse Code Modulation, PCM). Она является методом преобразования аналоговых данных в цифровой сигнал. При преобразовании аудиосигнала в цифровую форму в общем случае имеют место три процесса — дискретизация, квантование и кодирование. Эти функции выполняются аналого-цифровыми преобразователями (АЦП), расположенными в оборудовании.
    Компрессия (сжатие) оцифрованных аудиоданных (digitzed audio data compression) — это обработка оцифрованных аудиоданных с целью уменьшения их объема.
    Аудиокодер (audio encoder) — это программные, аппаратные или аппаратно-программные средства, с помощью которых осуществляется компрессия оцифрованных аудиоданных.
    Аудиодекодер (audio decoder) —это программные, аппаратные или аппаратно-программные средства, с помощью которых осуществляется декомпрессия сжатых аудиоданных.
    Декомпрессия сжатых аудиоданных (decompression of compressed digitized audio data) — восстановление оцифрованных данных из сжатых аудиоданных.

    Источник: https://learn.dlink.ru/course/view.php?id=155

    Аудиокодеки

    Кодек - это программный или аппаратный модуль, способный выполнять как компрессию так и декомпрессию аудиоданных
    Аудиокодек характеризуется скоростью передачи данных, качеством, сложностью, задержкой.
    Размер кадра (frame size) — размер одного голосового пакета для определенного кодека. Может выражаться в количестве байт (или бит) или миллисекундах.
    Битрейт (bitrate) — выраженная в битах оценка количества сжатых аудиоданных, определенная для некоторого временного интервала и отнесенная к длительности выбранного временного интервала в секундах.
    Обычно измеряется в килобит в секунду (Кбит/с). Другими словами, это количество единиц информации, выраженных в битах, необходимое для передачи (или хранения) одной секунды потока аудиоданных. Желаемая скорость передачи данных (битрейт) определяется пропускной способностью канала связи или емкостью памяти, в зависимости от приложения.
    Имейте в виду, что битрейт кодека не равен фактическому IP-трафику, поскольку типичные пакеты VoIP имеют небольшой размер, а заголовки IP, RTP и UDP приводят к значительным накладным расходам
    Одним из ключевых атрибутов аудиокодека является ширина полосы аудиосигнала, которую он кодирует и воспроизводит.
    Узкополосные кодеки (narrowband codecs) — это кодеки, которые используются для оцифровки звуковых частот от 300 Гц до 3400 Гц. Это ограничение частот заставляет голос приобретать характерный «телефонный» тон. Музыка использует более высокие частоты, которые отсекаются узкополосными кодеками, что приводит к искажению звука при прослушивании по телефону.
    Широкополосные кодеки (wideband codecs) — это кодеки, которые оцифровывают широкий частотный диапазон звукового спектра, что приводит к более четкому и естественному звучанию голоса. Охватываемый частотный диапазон обычно составляет от 50 до 7000 Гц.
    Сверхширокополосные кодеки (super-wideband codecs) — это кодеки, которые оцифровывают частотный диапазон звукового спектра от 50 до 14000 Гц.
    Средняя экспертная оценка (Mean Opinion Score, MOS) — значения на заранее определенной шкале, по которой субъекты оценивают качественные показатели работы телефонной системы передачи, используемой для разговора или для слушания речевого материала.
    Широкополосный диапазон улучшает воспроизведение звука, приближая звучание голоса к более естественному.
    Полнополосный диапазон позволяет воспроизводить высококачественные музыкальные записи.
    Детектор голосовой активности (Voice Activity Detector, VAD) — алгоритм, определяющий наличие речевого сигнала или фоновых шумов. Другими словами, это алгоритм, который может отличить интервалы активной речи от пауз.
    Поддержка прерывистой передачи (Discontinuous Transmission, DTX) позволяет кодеку прекратить передачу пакетов в тот момент, когда VAD обнаружил период молчания.
    Алгоритмы маскирования потери пакетов (Packet Loss Concealment, PLC), также известные как алгоритмы маскирования стирания кадров, скрывают потери передачи в аудиосистемах, где входной сигнал кодируется и пакетируется, отправляется по сети, принимается и декодируется перед воспроизведением. В настоящее время алгоритмы PLC реализованы в большинстве стандартных речевых кодеров.

    Источник: https://learn.dlink.ru/course/view.php?id=155

    Наиболее распространненые кодеки

    G.711
    G.729
    G.723.1
    G.726
    G.722
    iLBC
    SPEEX

    Источник: https://learn.dlink.ru/course/view.php?id=155

    Качество телефонной связи

    На качество телефонной связи влияет нижележащая структура IP-сети, потеря пакетов, джиттер, задержка
    Вызов VoIP начинается как аналоговый сигнал, который оцифровывается и возможно сжимается в кодеке. Фрагмент слова ( 10-30 мс ) помещается в ip-пакет и передается по сети
    Принимающее устройство компенсирует задержки ( джиттер ), восстанавливает слова и преобразует полученный сигнал в аналоговый
    Потеря пакетов может происходить из за перегрузки сети ( буферы ), неисправное оборудование или кабели, неправильная настройка сетевого оборудования, в том числе беспроводного, недостаточный размер буфера устранения дрожания, задержка кодека.
    В настоящее время в IP-сетях применяются следующие стандартизированные модели качества обслуживания (Quality of Service, QoS):
    модель негарантированной доставки данных (Best Effort Service);
    модель интегрированных услуг (Integrated Services, IntServ);
    модель дифференцированных услуг (Differentiated Services, DiffServ);
    модель многопротокольной коммутации по меткам (Multi-Protocol Label Switching, MPLS).
    Для обеспечения Qos на канальном уровне, маршрутизаторы и коммутаторы поддерживают стандарт IEEE 802.1р, который позволяет задать до 8 уровней приоритетов
    QoS на канальном уровне в сетях Wi-Fi кадр содержит поле управления QoS (QoS Control), которое включает в себя подполе TID (Traffic Indicator, индикатор трафика), данное поле позволяет задать приоритет кадра от 0 до 7.
    На сетевом уровне в заголовке протокола IP предусмотрено 8-битное поле Type of Service (ToS), в IPv6 — Traffic Class (ТС).
    Первые 6 бит поля DS называются Differentiated Services Codepoint (DSCP), определяет класс обслуживания
    Класс определяет приоритет обслуживания пакета на коммутаторе и маршрутизаторе
    Коммутатор или маршрутизатор получает пакет, выполняет его классификацию к одному из классов обслуживания

    Классификация на основе агрегированного потока (BA, Behavior Aggregate). Behavior Aggregate — множество пакетов с одинаковым значением DSCP, передающихся через канал связи в определенном направлении.
    Классификация на основе полей пакета (MF, Multi-Field), таких как IP-/MAC-адрес источника, IP, MAC-адрес назначения, поле DS, идентификатор протокола, номер порта назначения, VLAN и др.
    Первоначально поле Type of Service предназначалось для определения функций качества обслуживания (QoS) для доставки IP-пакетов
    RFC 2474 «Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers», который переопределяет байт ToS для поддержки модели дифференцированного обслуживания (Differentiated Services, DiffServ).
    Под параметрами QoS понимаются задержка передачи IP-пакета, джиттер, доля потерянных IP-пакетов и доля IP-пакетов с ошибкой. Далее определяются классы трафика.
    Потери голосовых пакетов могут происходить по следующим причинам:
    Перегрузка сети. Наиболее часто перегрузка сети возникает в местах соединения сетей с разной полосой пропускания, например, 1000 Мбит/с и 100 Мбит/с. В случае возникновения перегрузки сети пакеты начинают буферизироваться и распределяться по очередям. Когда приемные буферы устройств переполнены, пакеты начинают отбрасываться.
    Неисправное оборудование или кабели. На пути следования пакета к месту назначения может находиться различное сетевое оборудование, соединенное кабелями. Оборудование, его интерфейсы, соединительные кабели могут быть повреждены или отключены, что послужит причиной потери пакета
    Передача через беспроводную сеть. Путь пакета может лежать через беспроводную сеть. В случае ее неправильного проектирования или неверной установки беспроводного оборудования, сигнал может не достигать места назначения, что приведет к потере пакета
    Неверная настройка оборудования. Неверная конфигурация оборудования может стать причиной отбрасывания пакетов. Например, могут быть ошибки при настройке фильтров, VLAN, протоколов аутентификации
    Трансляция сетевых адресов (Network Address Translation). Проблема возникает при отправке пакетов между локальной сетью, использующей IP-адреса из частного диапазона и внешней сетью. Протокол RTP использует динамические номера портов, что не позволяет NAT корректно выполнять трансляцию. Вследствие этого пакеты могут не доходить до получателя
    Недостаточный размер буфера устранения дрожания. Если время доставки пакета превышает размер буфера, то пакет считается «прибывшим слишком поздно» относительно предполагаемого времени его использования и будет отброшен
    ITU-T серьезно занимался исследованием проблем, связанных с задержками при передаче голоса по сети. В результате была разработана Рекомендация МСЭ-Т G.114, в которой отмечается, что задержки менее 150 мс при сквозной передаче (то есть задержки на пути передачи сигнала от говорящего до слушающего) не оказывают существенного влияния на большинство речевых приложений. Другими словами, при планировании сети надо исходить из того факта, что суммарная задержка при передаче голосового пакета от источника к приемнику не должна превышать 150 мс. Задержка выше 400 мс считается неприемлемой, хотя есть исключения. Например, при телефонном разговоре через спутник
    Можно выделить следующие причины задержки при сквозной передаче речи от источника к приемнику:
    Задержка кодека (иногда называется алгоритмической задержкой): эта задержка обусловлена необходимостью сбора входных речевых выборок и преобразования их в сжатый кадр. Величина задержки определяется типом аудиокодека
    Задержка в IP-среде: кадр, полученный в результате работы кодека, будет немедленно помещен в IP-пакет. Дополнительная задержка, требуемая для сборки IP-пакетов и передачи на канальный уровень, будет зависеть от канального уровня. Когда канальным уровнем является локальная сеть (LAN) (например, Ethernet), эта задержка обычно невелика. Когда канальный уровень является уровнем с более низкой тактовой частотой (например, модемное соединение) или сетью с большим количеством трафика (например, перегруженная сеть LAN), эта задержка будет существенно возрастать
    Задержка, обусловленная джиттер-буфером: влияние буфера устранения дрожания на задержку при односторонней передаче основано на среднем времени пребывания пакетов в этом буфере, которое меньше его максимального размера. В зависимости от конкретного типа реализации, а также от настройки буфера устранения дрожания, вносимая им задержка может составлять половину его максимального размера
    Задержка среды передачи: задержка, обусловленная используемой физической средой передачи, необходимостью подавления эха, обработкой пакета транзитными устройствами.
    Источник: https://learn.dlink.ru/course/view.php?id=155

    Маркировка пакетов

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

    Отбрасывание хвоста (Tail drop), этого метода есть два важных недостатка. В некоторых ситуациях отбрасывание хвоста позволяет одному соединению или нескольким потокам монополизировать очередь, не позволяя другим соединениям получить место в ней. Алгоритм отбрасывания хвоста позволяет очередям поддерживать состояние «заполнена» (или почти заполнена) в течение длительного периода времени, поскольку сигнализирует о перегрузке (посредством отбрасывания пакетов) только тогда, когда очередь становится полной
    Алгоритм отбрасывания хвоста может привести к глобальной синхронизации TCP. Отбрасывание пакета будет служить сигналом о перегрузке сети источнику ТСР-соединения, т.к. он не получит подтверждения о доставке сегмента от приемника ТСР-соединения. Поскольку коммутатор/маршрутизатор обрабатывает сегменты множества ТСР-потоков в один момент времени, это послужит сигналом о перегрузке тысячам источникам ТСР-соединений, которые снизят скорость передачи. С каждой удачной передачей TCP-сегмента будет увеличиваться размер окна перегрузки и скорость передачи. До тех пор, пока очереди не переполнены, скорость передачи почти всех источников ТСР-соединений будет увеличиваться. Увеличение интенсивности трафика в какой-то момент вызовет переполнение очередей в узком месте, которое приведет к отбрасыванию пакетов, и весь процесс повторится вновь.
    Процесс, когда каждый источник ТСР-соединения уменьшает и увеличивает скорость передачи одновременно с другими источниками ТСР-соединений, получил название эффекта глобальной синхронизации (global synchronization). Эффект глобальной синхронизации приводит к неэффективному использованию полосы пропускания, а также к возрастанию задержки передачи пакетов
    Помимо отбрасывания хвоста, при заполнении очереди могут применяться два альтернативных алгоритма: случайное отбрасывание при заполнении (random drop on full) или отбрасывание первого пакета при заполнении (drop front on full). Названия методов говорят сами за себя. Они решают проблему монопольного захвата очереди, но не справляются с главной задачей механизма управления очередями: не позволяют уменьшить размер постоянной очереди
    Методы активного управления очередями (Active Queue Management, AQM) позволяют коммутаторам/маршрутизаторам отбрасывать пакеты до того как очередь заполнится. Таким образом, конечные узы смогут среагировать на перегрузку до переполнения буфера. Отбрасывая пакеты до переполнения буферов, активное управление очередью позволяет коммутаторам/маршрутизаторам контролировать, когда и сколько пакетов нужно отбросить
    Random Early Detection (RED) — это первый метод активного управления очередями, который был предложен для преодоления ограничений пассивного подхода к управлению очередями. В отличие от алгоритма отбрасывания хвоста, алгоритм RED отбрасывает поступающие пакеты вероятностно, на основе оценки среднего размера очередей
    Средний размер очереди сравнивается с двумя пороговыми значениями – минимальным и максимальным. Если средний размер очереди превысит определенное минимальное пороговое значение, то пакеты начинают отбрасываться с некоторой вероятностью. Это позволяет избежать эффекта глобальной синхронизации, т.к. будут отбрасываться не все пакеты, а только пакеты произвольным образом выбранных потоков. Интенсивность отбрасывания пакетов возрастает прямо пропорционально возрастанию среднего размера очереди. Когда средний размер очереди превысит максимальное пороговое значение, алгоритм RED будет отбрасывать все пакеты, предназначенные для постановки в очередь
    Для RED все пакеты одинаковы, независимо от приоритета. Пакеты с высоким приоритетом отбрасываются с той же вероятностью, что и пакеты с низким приоритетом. Он решает проблему глобальной синхронизации, но не учитывает важность данных
    В коммутаторах D-Link поддерживается взвешенный алгоритм случайного раннего обнаружения (Weighted Random Early Detection, WRED), который является расширенной версией алгоритма RED. Он учитывает приоритеты поступающих пакетов, позволяя администратору задать для каждой очереди собственные пороговые значения размера — минимальное (minimum threshold) и максимальное (maximum threshold). Если текущий средний размер очереди меньше минимального порогового значения, поступающие пакеты помещаются в очередь. Если текущий средний размер очереди находится в интервале между минимальным и максимальным пороговыми значениями, пакет или отбрасывается, или помещается в очередь в зависимости от его вероятности отбрасывания. Если средний размер очереди больше максимального порогового значения, все пакеты будут отбрасываться
    Администратор может настроить вероятностное отбрасывание входящих «окрашенных» пакетов. «Окрашивание» пакетов позволяет реализовать разные политики обслуживания пакетов (различную вероятность отбрасывания) на основе их приоритетов. Так пакеты, «окрашенные» в зеленый цвет обладают наивысшим приоритетом. Пакеты «окрашенные» в желтый цвет – средним, в красный цвет – низшим приоритетом. Если средний размер очереди будет находиться в интервале между минимальным и максимальным пороговыми значениями, т.е. будет наблюдаться умеренная перегрузка, то пакеты «окрашенные» в красные и желтые цвета будут отбрасываться с заданной вероятностью. Если средняя длина очереди превысит максимальное пороговое значение, то пакеты любых цветов будут отбрасываться с заданной вероятностью. Таким образом, алгоритм WRED обеспечивает возможность настройки более интенсивного отбрасывания пакетов низкоприоритетного трафика и менее интенсивного отбрасывания пакетов высокоприоритетного трафика. Например, администратор может настроить более низкие пороговые значения для пакетов из низкоприоритетной очереди
    Информация о поддержке коммутаторами D-Link алгоритма WRED указывается в технической документации. Если WRED не настроен или не поддерживается, используется метод отбрасывания хвоста
    Чтобы пакеты не скапливались в очередях, коммутатор/маршрутизатор должен решить какой пакет из какой очереди и когда отправлять через выходной интерфейс

    Источник: https://learn.dlink.ru/course/view.php?id=155

    Механизмы организации очередей

    FIFO (First-In, First-Out) - передает пакеты, поставленные в одну очередь в том порядке, в котором они поступили в нее. Как правило, механизм FIFO поддерживается на выходном порту, когда не настроена другая дисциплина планирования очереди. Не обеспечивает классификацию пакетов и рассматривает их как принадлежащие одному классу.
    Какой-то поток может занять все буферное пространство, и пакеты других потоков будут вынуждены ждать до тех пор, пока его пакеты не будут обслужены.

    Очереди приоритетов (Priority Queuing) - PQ пакеты сначала классифицируются системой, а затем помещаются в очереди с разными приоритетами. Пакеты из данной очереди передаются, только если все очереди с более высоким приоритетом пусты. В каждой из очередей приоритетов пакеты передаются в порядке FIFO.
    Если объем трафика с более высоким приоритетом становится чрезмерным, трафик с более низким приоритетом может быть отброшен, поскольку буферное пространство, выделенное для очередей с низким приоритетом, начинает переполняться. Если это происходит, возможно, что сочетание отбрасывания пакетов, увеличения задержки и повторной передачи пакетов конечными узлами может в итоге привести к полной нехватке ресурсов для трафика с более низким приоритетом. Неправильно функционирующий поток с высоким приоритетом может значительно увеличить величину задержки и вариации задержки для других потоков с высоким приоритетом, находящихся в этой же очереди.
    Взвешенный алгоритм кругового обслуживания (Weighted Round-Robin, WRR) - алгоритм кругового обслуживания (Round-Robin, RR) - из каждой очереди он передает равное количество пакетов. Как только будет обслужена последняя очередь, процесс начинается вновь.
    Взвешенный алгоритм кругового обслуживания с дефицитом (Weighted Deficit Round-Robin, WDRR) - также основан на алгоритме RR. В отличие от WRR, алгоритм WDRR учитывает размер пакетов при обслуживании очередей. Он справедливо распределяет полосу пропускания между пакетами большого и малого размера.
    Источник: https://learn.dlink.ru/course/view.php?id=155

    VOICE VLAN

    Стандарт IEEE 802.1Q определяет изменения в структуре кадра Ethernet, позволяющие передавать информацию о VLAN по сети.
    Первые 2 байта (поле Tag Protocol Identifier, TPID) с фиксированным значением 0х8100 определяют, что кадр содержит тег протокола 802.1Q. Остальные 2 байта содержат следующую информацию:
    Priority (Приоритет) — 3 бита поля приоритета передачи кодируют до восьми уровней приоритета (от 0 до 7, где 7 – наивысший приоритет), которые используются в стандарте 802.1р;
    Canonical Format Indicator (CFI) — 1 бит индикатора канонического формата зарезервирован для обозначения кадров сетей других типов (Token Ring, FDDI), передаваемых по магистрали Ethernet;
    VID (VLAN ID) — 12-ти битный идентификатор VLAN определяет, какой VLAN принадлежит трафик. Поскольку под поле VID отведено 12 бит, то можно задать 4094 уникальных VLAN (VID 0 и VID 4095 зарезервированы).
    Tagging (Маркировка кадра) — процесс добавления информации о принадлежности к 802.1Q VLAN в заголовок кадра Ethernet
    Untagging (Извлечение тега из кадра) — процесс извлечения информации о принадлежности к 802.1Q VLAN из заголовка кадра Ethernet
    VLAN ID (VID) — идентификатор VLAN
    Port VLAN ID (PVID) — идентификатор порта VLAN
    Ingress port (Входной порт) — порт коммутатора, на который поступают кадры, и при этом принимается решение о принадлежности к VLAN
    Egress port (Выходной порт) — порт коммутатора, с которого кадры передаются на другие сетевые устройства – коммутаторы, маршрутизаторы, точки доступа, серверы или рабочие станции, и при этом приниматься решение о маркировке
    Любой порт коммутатора может быть настроен как tagged (маркированный) или как untagged (немаркированный). Функция untagging позволяет работать с теми сетевыми устройствами виртуальной сети, которые не понимают тегов в заголовке кадра Ethernet. Функция tagging позволяет настраивать VLAN между несколькими коммутаторами, поддерживающими стандарт IEEE 802.1Q.
    При настройке на коммутаторе Voice VLAN должна быть активирована глобально и на соответствующих портах устройства. Членство порта в Voice VLAN может устанавливаться автоматически или вручную администратором сети. В автоматическом режиме коммутатор автоматически добавляет порт, подключенный к IP-телефону, в голосовую VLAN, если уникальный идентификатор производителя оборудования (Organizationally Unique Identifier, OUI) в MAC-адресе источника кадров, отправленных с IP-телефона, совпадает с настроенным OUI. Напомним, что OUI присваивается производителю институтом IEEE и указывается в первой части MAC-адреса.
    Стоит отметить, что при работе в автоматическом режиме порт не является постоянным членом Voice VLAN. Когда IP-телефон, подключенный к порту, перестанет отправлять трафик и его MAC-адрес в таблице коммутации устареет, запустится таймер старения Voice VLAN (Aging time). Порт будет удален из Voice VLAN по истечении таймера. Если голосовой трафик возобновится до истечения времени, установленного таймером, таймер будет остановлен и сброшен. Администратор сети может при необходимости настроить таймер старения или оставить значение по умолчанию.
    Если порт работает в автоматическом режиме и настроен опциональный режим tag (tagged), он автоматически присоединится к Voice VLAN в качестве маркированного члена.
    Когда порт получает от IP-телефона маркированные кадры с идентификатором VID в заголовке равным идентификатору Voice VLAN, коммутатор отправляет их в голосовую VLAN, изменив при этом значение поля приоритета на приоритет Voice VLAN. Когда порт получает от IP-телефона немаркированные кадры, коммутатор будет перенаправлять их в VLAN, идентифицируемую PVID порта. Напомним, что каждый физический порт коммутатора имеет идентификатор порта VLAN (PVID). Этот параметр используется для того, чтобы определить, в какую VLAN коммутатор направит входящий немаркированный кадр с подключенного к порту сегмента, когда кадр нужно передать на другой порт (внутри коммутатора в заголовки всех немаркированных кадров добавляется идентификатор VID равный PVID порта, на который они были приняты)
    Если порт работает в автоматическом режиме и настроен опциональный режим untag (untagged), он автоматически присоединится к Voice VLAN в качестве немаркированного члена. Когда порт получает от IP-телефона маркированные кадры с идентификатором VID в заголовке равным идентификатору Voice VLAN, коммутатор отправляет их в голосовую VLAN, изменив при этом значение поля приоритета на приоритет Voice VLAN. Когда порт получает от IP-телефона немаркированные кадры, коммутатор будет отправлять их в Voice VLAN. К кадрам будет добавляться приоритет и тег Voice VLAN. Этот режим настроен по умолчанию.
    Автоматический режим удобен тем, что при физическом перемещении IP-телефона и подключении его к другому порту коммутатора с настроенной функцией, он все равно останется в Voice VLAN и ручная настройка ее параметров не потребуется.
    Ручной режим удобно использовать при подключении серверов или других устройств, перемещение которых не планируется. В ручном режиме порт коммутатора, подключенный к IP-телефону или серверу, может пересылать пакеты голосовых данных только после того, как будет вручную добавлен в Voice VLAN в качестве маркированного или немаркированного члена. Принадлежность кадра к Voice VLAN будет определяться по идентификатору VID в заголовке кадра, если кадр маркированный. Если кадр немаркированный, то в его заголовок коммутатор добавит тег с идентификатором VID, равным идентификатору PVID порта, через который этот кадр был принят и перешлет в Voice VLAN.
    IP-телефоны, как правило, оборудованы портом LAN для подключения компьютера и портом WAN для подключения к сети. Когда компьютер подключен к телефону, то через порт WAN передается и голосовой трафик, и трафик данных.
    Администратор сети может настроить на телефоне собственную конфигурацию Voice VLAN и задать медиа-трафику и трафику сигнализации наивысшие приоритеты 802.1p. Также администратор может настроить VLAN 802.1Q для трафика, передаваемого через порт LAN, и определить приоритет его обработки.

    Источник: https://learn.dlink.ru/course/view.php?id=155

    Безопасность в сетях VoIP

    Прослушиванию подлежат не только голосовые вызовы, но и сообщения, которые передаются телефонной системой. Сюда относится прием факсимильных данных и DTMF-сигналов (данных о нажатых кнопках) для получения паролей или номеров банковских карт, используемых во время сеансов интерактивного голосового вызова.
    Управляемые коммутаторы обычно имеют установленные по умолчанию логин/пароль, например, admin/admin. Функция Port Mirroring (Зеркалирование портов) позволяет отображать (копировать) кадры, принимаемые и отправляемые портом-источником на целевой порт коммутатора, к которому подключен компьютер с установленным анализатором трафика. Эта функция полезна администраторам для мониторинга и анализа кадров с целью поиска неисправностей, обнаружения атак в сети, записи VoIP-вызовов.

    Некоторые рекомендации, которые позволят защитить коммутатор от несанкционированного доступа:
    Рекомендуется для управления и мониторинга устройств локальной сети создавать выделенную виртуальную локальную сеть, отличную от VLAN по умолчанию (VLAN 1).
    Настройте протокол SSL/TLS для доступа к Web-интерфейсу управления.
    Используйте длинные пароли, невосприимчивые к атаке по словарю. Добавьте цифры или замените буквы цифрами и символами
    Операционная система коммутатора поддерживает создание учетных записей с различными уровнями привилегий
    Настройте протокол SSL/TLS для доступа к Web-интерфейсу управления
    Используйте протокол SSH вместо протокола Telnet
    Ограничьте доступ к консоли с помощью списков управления доступом (ACL) и используйте сложные пароли
    Настройте запись в журнал регистрации событий (log-файл). При этом убедитесь, что в сети настроен сервис NTP для синхронизации часов сетевых устройств
    Используйте ААА-аутентификацию при возможности
    Ограничьте доступ по SNMP
    Одним из инструментов злоумышленников для прослушивания вызовов является спуфинг. Спуфинг — это тип кибератаки, в которой маскировка под легальный объект (компьютер, устройство или сеть) используется как средство проникновения в другие компьютерные сети
    ARP-спуфинг (ARP Spoofing) относится к атакам типа «man-in-the-middle» (человек посередине). Он позволяет перенаправить голосовые пакеты и данные на устройство злоумышленника. Атакующий перехватывает в сети ARP-запрос и отправляет ложный ARP-ответ, в котором объявляет себя искомым устройством локальной сети (указывает в нем МАC-адрес ложного устройства и IP-адрес реального). Коммутатор или IP-телефон получит ложный ARP-ответ и обновит ARP-таблицу. Таким образом, вместо того, чтобы отправлять трафик легитимному устройству, коммутатор или IP-телефон начнет перенаправлять его на устройство злоумышленника. В итоге правильный пункт назначения не получит данные, а злоумышленник сможет перехватывать голосовые пакеты и другую информацию. Одним из типов ARP Spoofing является использование пакетов Gratuitous ARP, т.к. эти пакеты не требуют запросов или ответов. Злоумышленник «отравляет» ARP-таблицу коммутатора или IP-телефона, отправляя Gratuitous ARP Request, в котором для определенного IP-адреса указан ложный МАС-адрес. После получения злонамеренного пакета Gratuitous ARP Request запись для этого IP-адреса в ARP-таблице устройства обновляется
    Для защиты от подобных атак может использоваться функция IP-MAC-Port Binding (IMPB), которая позволяет фильтровать пакеты и таким образом контролировать доступ в сеть устройств, подключенных к коммутатору. При настройке функции порт будет проверять идентичны ли МАС- и IP-адреса источника входящих пакетов параметрам хранящихся на коммутаторе записей, связывающих МАС- и IP-адреса клиентских устройств с портами и VLAN подключения:
    если все составляющие (IP/MAC-адреса, порт, VLAN) совпадают, пакеты будут передаваться, и клиенты получат доступ в сеть;
    если все составляющие частично или полностью не совпадают, коммутатор заблокирует MAC-адрес соответствующего узла с занесением его в «черный лист».
    Другими словами, аутентификация 802.1Х — это аутентификация на основе портов. Это означает, что для защиты от подключения к сети неавторизованных клиентских устройств, порт коммутатора сначала помещается в состояние «заблокирован» и через него возможна передача только идентификационной информации клиента, например, логина и пароля. Эта идентификационная информация проверяется на специальном сервере аутентификации, который находится в сети. Идентификационная информация не может передаваться по сети в открытом виде, поэтому для ее передачи используется специальный протокол Extensible Authentication Protocol over LAN (EAPOL). Если аутентификация прошла успешно, порт коммутатора разблокируется и клиентскому устройству предоставляется доступ в сеть. После этого он может начать передачу обычного трафика
    В стандарте IEEE 802.1X определены три роли устройств в общей схеме аутентификации:
    Клиент (Client/Supplicant)
    Аутентификатор (Authenticator)
    Сервер аутентификации (Authentication Server)
    Опишем эти роли относительно проводной сети.
    Клиент (Client/Supplicant) — Другими словами, это устройство, подключенное к коммутатору, которое пытается пройти аутентификацию, чтобы получить доступ к сети. На устройстве должно быть установлено ПО клиента 802.1Х.
    Аутентификатор (Authenticator) — это объект, облегчающий аутентификацию других, подключенных к нему устройств. В локальной проводной сети эту роль исполняет коммутатор. Он работает как посредник (Proxy) между клиентом и сервером аутентификации: получает запрос на проверку подлинности от клиента, проверяет данную информацию при помощи сервера аутентификации и пересылает ответ клиенту. Коммутатор реализует функциональность клиента RADIUS, который отвечает за инкапсуляцию и деинкапсуляцию кадров EAP и взаимодействие с сервером аутентификации.
    Сервер аутентификации (Authentication Server) — это объект, предоставляющий аутентификатору услугу аутентификации. Сервер аутентификации выполняет фактическую аутентификацию клиента. Он определяет на основе учетных данных, предоставленных клиентом его подлинность, и информирует коммутатор о предоставлении или отказе клиенту в доступе к локальной сети. В качестве сервера аутентификации обычно используется сервер RADIUS (Remote Authentication Dial-In User Service).
    Remote Authentication Dial-In User Service (RADIUS) — это сетевой протокол, который обеспечивает централизованное управление аутентификацией, авторизацией и ведением учетных записей пользователей (Authentication, Authorization, Accounting (AAA)), которые подключаются к сети и используют ее сервисы
    МАС-спуфинг (MAC Spoofing) также позволяет перенаправить голосовые пакеты и данные на устройство злоумышленника. Атака заключается в изменении MAC-адреса сетевого устройства (сетевой карты). В результате злоумышленник может захватить данные, адресованные другому устройству (легитимному), находящемуся в том же широковещательном домене. Злоумышленник отправляет в сеть кадр, в котором вместо реального МАС-адреса будет указан МАС-адрес атакуемого узла. Когда коммутатор получит этот кадр, то обновит соответствующую запись в таблице коммутации. Теперь MAC-адрес атакуемого узла будет ассоциирован с портом, к которому подключено устройство злоумышленника. До тех пор, пока коммутатор не получит кадр от атакованного устройства, он будет пересылать все данные, адресованные ему, на устройство злоумышленника
    Функция Port Security позволяет настроить какой-либо порт коммутатора так, чтобы доступ к сети через него мог осуществляться только определенными устройствами. Устройства, которым разрешено подключаться к порту определяются по МАС-адресам. МАС-адреса могут быть изучены динамически или вручную настроены администратором сети. Помимо этого, функция Port Security позволяет ограничивать количество изучаемых портом МАС-адресов, тем самым, ограничивая количество подключаемых к нему узлов
    Функционал IP-телефона позволяет получать настройки протокола IP динамически с использованием протокола DHCP. В протоколе DHCP не реализованы методы защиты и проверки подлинности пакетов. В связи с этим, он может быть подвергнут разного рода атакам. Целью атаки Rogue DHCP Server является подмена легитимного сервера DHCP сервером злоумышленника. Угроза заключается в том, что, когда в сети одновременно находятся два сервера DHCP, один из которых злонамеренный, часть клиентов автоматически получит неправильные IP-адреса, в том числе IP-адрес шлюза по умолчанию, адрес сервера DNS. Если неавторизованный сервер DHCP настроен на предоставление в качестве шлюза по умолчанию IP-адреса устройства, контролируемого злоумышленником, тот сможет прослушивать весь трафик клиентов, при этом получая возможность маршрутизировать пакеты по своему усмотрению
    Существуют разнообразные методы, с помощью которых можно вызвать перезагрузку IP-телефона, чтобы в последующем он получил фальшивые настройки от DHCP-сервера злоумышленника. Для защиты от подобных атак можно настроить на телефоне статический IP-адрес или использовать на коммутаторе функцию IP-MAC-Port Binding.
    Целями DoS-атаки в VoIP-сети на основе протокола SIP являются:
    SIP-сервер. Наиболее важный компонент сети телефонии чаще всего становится целью злоумышленников потому что его отключение означает нарушение работы всей службы SIP
    SIP-клиент. Если злоумышленник не хочет отключать всю службу, а только сделать ее недоступной для одного пользователя, он обычно нацеливается на соответствующего SIP-клиента.
    Злоумышленники осуществляют DoS-атаки на протокол SIP разными способами: UDP Flood, TCP SYN Flood, SIP INVITE Flood, SIP REGISTER Flood, вредоносные потоки RTP. Кратко рассмотрим некоторые из атак, т.к. в их основе лежит одинаковый механизм лавинной рассылки (flooding).
    Сообщения SIP могут передаваться с использованием протокола TCP или UDP. Наиболее предпочтительным является использование UDP. Это означает, что атака на основе лавинной рассылки сегментов UDP (UDP Flood) возможна против большинства серверов и клиентских устройств SIP. Она заключается в отправке множества UDP-сегментов (как правило, большого объёма) на определённый или случайный номер порта целевого сервера или IP-телефона. При получении сегмента UDP устройство будет вынуждено его обработать: проверить, есть ли приложение, прослушивающее данный порт, и если оно не активно или отсутствует, отправить сообщение ICMP о недоступности пункта назначения (Destination Unreachable). Из-за огромного количества поступающих на обработку сегментов UDP ресурсы устройства будут частично или полностью недоступны для обработки легитимных данных, т.к. в протоколе UDP отсутствует механизм предотвращения перегрузок. В рамках UDP-флуда атакующий может подделать IP-адреса пакетов для перенаправления ICMP-ответов и сохранения работоспособности атакующих узлов, а также обеспечения их анонимности
    Протокол UDP является протоколом без установления соединения, что затрудняет фильтрацию UDP-флуда и делает его эффективным средством для атаки
    В RFC 4987 описаны хорошо известные методы, позволяющие бороться с DoS-атаками на протокол TCP
    Атака SIP INVITE Flood использует отправку множества запросов INVITE, которые используются для инициации вызовов. Запрос INVITE является ключевым, поскольку он запускает обработку вызова в прокси-сервере SIP или телефоне. Если скорость атаки очень высока, память сервера или телефона будет исчерпана и устройство не сможет обрабатывать легитимные вызовы
    Атака SIP REGISTER Flood основана на переполнении сети запросами на регистрацию. Это происходит в том случае, когда множество клиентских VoIP-устройств пытаются одновременно зарегистрироваться на сервере. Если объем запросов регистрации превышает возможности сервера, некоторые сообщения теряются. Клиентские устройства пытаются снова зарегистрироваться, тем самым увеличивая перегрузку. Из-за перегрузки сети пользователи не смогут получить к ней доступ в течение некоторого времени
    Рассмотрим методы, которые позволяют бороться с DoS-атаками на протокол SIP или снизить их эффективность. Одним из методов является пользование на IP-телефонах и прокси-серверах протокола TCP, вместо UDP при установлении соединения.
    При использовании TCP SIP-телефоны обычно устанавливают постоянные соединения с прокси-сервером, а прокси-серверы между собой. Из-за того, что TCP использует порядковые номера сегментов, злоумышленнику сложнее обманом заставить целевое устройство принимать потоки пакетов. Оно по-прежнему будет задействовать свои ресурсы для обработки пакетов лавинной рассылки, но сможет отбрасывать их на уровне протокола TCP.
    Сообщения SIP могут передаваться с использованием протокола TLS. В этом случае протокол SIP считается защищенным и называется SIPs. Протокол TLS предоставляет приложениям, работающим поверх него три основных сервиса: аутентификацию, конфиденциальность и целостность данных. Он использует шифрование для обеспечения конфиденциальности. Благодаря этому TLS предотвращает возможность прослушивания злоумышленниками сообщений сигнализации. Из-за необходимости аутентификации, которая использует шифрование, злоумышленнику очень сложно (если вообще возможно) заставить прокси-сервер принимать потоки пакетов. Как и в случае с TCP, поддельные пакеты будут отбрасываться на уровне TLS.
    Прежде чем SIP-клиент и прокси-сервер начнут обмениваться сообщениями через безопасное соединение SIP/TLS, они должны договориться об используемых параметрах безопасности: согласовать версию протокола TLS, алгоритмы шифрования, проверки целостности, криптографические ключи и дополнительно аутентифицировать друг друга. Этот процесс состоит из трех фаз, включающих обмен серией сообщений между клиентом и сервером
    Согласование алгоритмов безопасности и аутентификация сервера
    Клиент отправляет серверу сообщение Client Hello, в котором указывает версию протокола TLS, идентификатор сессии, набор поддерживаемых алгоритмов шифрования и метод сжатия
    Если не произошла ошибка прокси-сервер отвечает сообщением Server Hello, в котором указывает версию протокола TLS, номер сессии, единственный набор алгоритмов шифрования, выбранный сервером из предложенных клиентом и метод сжатия, выбранный сервером среди предложенных клиентом
    Вслед за сообщением Server Hello в сообщении Certificate сервер может отправить клиенту свой сертификат или цепочку сертификатов X.509.v3 для проверки. Это выполняется, если требуется аутентифицировать сервер
    Если у сервера нет сертификата или сертификат используется только для подписи, он отправляет сообщение обмена ключами Server Key Exchange
    Прокси-сервер может запросить сертификат у клиента для обеспечения взаимной аутентификации, отправив сообщение Certificate Request
    Сервер отправляет сообщение Server Hello Done, которое позволяет клиенту понять, что первоначальные переговоры завершились.
    Аутентификация клиента и обмен ключами
    Если прокси-сервер запрашивал сертификат, клиент отправляет ему сертификат или цепочку сертификатов в сообщении Certificate
    Клиент отправляет сообщение Client Key Exchange, содержимое которого зависит от алгоритма обмена ключами, выбранного клиентом и сервером в процессе обмена сообщениями Hello
    Клиент может отправить сообщение Certificate Verify, которое используется для точной проверки его сертификата. Это сообщение посылается только вслед за клиентским сертификатом, имеющим возможность подписи.
    Окончание обмена
    Клиент отправляет сообщение Change Cipher Spec, чтобы изменить режим шифрования
    Сразу после отправки Change Cipher Spec, клиент посылает шифрованное сообщение Finished, содержащее новые алгоритмы, ключи и секреты. Оно подтверждает, что обмен ключами и аутентификация выполнены успешно
    Сервер отправляет сообщение Change Cipher Spec, чтобы изменить режим шифрования
    Сразу после отправки Change Cipher Spec, сервер посылает шифрованное сообщение Finished. При его приеме клиент должен убедиться в правильности всех параметров. Как только стороны соединения отправили друг другу свои сообщения Finished, получили их и проверили параметры, они могут начать обмен шифрованными данными.
    TLS используется для защиты соединений «точка - точка» между прокси-серверами и/или прокси-серверами и SIP-телефонами. TLS не является сквозным протоколом. Чтобы вызов был безопасным, TLS должен использоваться для всех соединений между конечными точками SIP, участвующими в вызове
    Следует отметить, что если одни SIP-телефоны используют TLS, а другие нет, то модель безопасности не работает, как и в случае TCP
    Выделение голосового трафика и трафика данных в разные VLAN позволит предотвратить ряд атак на систему телефонии. При правильной настройке Voice VLAN возможно заблокировать DoS-атаку с взломанного компьютера, находящегося в другой VLAN. Однако использование софтфонов на ПК может помешать использованию VLAN в качестве меры безопасности. Пакеты софтфона должны приниматься прокси-сервером SIP. Мошенническое приложение может имитировать софтфон и генерировать флуд-атаки. Одним из решений этой проблемы является использование TLS для аутентификации программного телефона
    Для повышения сетевой безопасности рекомендуется подключать устройства к управляемому коммутатору или маршрутизатору. Чтобы избежать возможной атаки в случае, если злоумышленник получит физический доступ к коммутатору и подключит свое устройство к его порту, на коммутаторе нужно настроить функции контроля доступа к портам: аутентификацию 802.1X, IMPB, Port Security. Помимо этого, коммутаторы поддерживают функции предотвращения DoS-атак и защиты от широковещательного/многоадресного/одноадресного шторма.
    В типичной сети предприятия или организации SIP-телефон регистрируется на прокси-сервере SIP, поэтому прокси-сервер знает, куда направлять входящие вызовы. Регистрация телефона выполняется при загрузке и через заданный интервал окончания регистрации, который можно настроить (по умолчанию установлено 3600 секунд). Прокси-сервер может изменить запрошенный интервал окончания регистрации в ответе 200 OK. В этом случае телефон изменит значение интервала окончания регистрации на рекомендуемое сервером.
    Злоумышленник может удалить регистрацию SIP-телефона, отправив запрос REGISTER с заголовком. Ключевыми параметрами являются Contact: * и Expires: 0, которые удаляют все регистрации SIP-телефона на прокси-сервере. После этого SIP-телефон не сможет принимать входящие вызовы
    Удаление регистрации влияет только на прием звонков. Совершать исходящие вызовы с SIP-телефона будет возможно.
    Особенностью взаимодействия по протоколу SIP является то, что обмен сообщениями происходит не между устройствами, а между пользователями. При этом пользователь может одновременно использовать несколько SIP-клиентов и регистрировать несколько местоположений, например, свое рабочее место, конференц-зал, лабораторию и т.д. При поступлении входящего вызова каждый из телефонов, используемых пользователем, может звонить. Такое поведение создает возможность для атак на основе добавления регистрации. Например, злоумышленник может добавить группу контактов для каждого пользователя, заставляя множество SIP-телефонов звонить при каждом входящем звонке, раздражая пользователей.
    Перехват регистрации относится к ситуации, когда злоумышленник заменяет законную регистрацию ложной. Это приводит к тому, что входящие вызовы направляются на несуществующее устройство, устройство, принадлежащее злоумышленнику или приложение, которое имитирует предполагаемого пользователя, предлагая, например, оставить голосовое сообщение. Эти атаки основаны, в том числе, на уязвимости схемы SIP-аутентификации на основе алгоритма MD5 в процессе регистрации
    Атака перенаправления вызова основана на том, что злоумышленник может отправить на запрос INVITE ответ о перенаправлении вызова — 301 Moved Permanently (изменил местоположение на постоянной основе) или 302 Moved Temporarily (временно сменил местоположение). Инициирующий вызов телефон, после получения ответа 301 или 302, должен использовать значение в поле заголовка Contact, которое указывает, где можно найти вызываемого абонента. Ответ 302 также будет содержать поле заголовка Expires, который сообщает относительное время, в течение которого будет продолжаться перенаправление. В результате атаки злоумышленник своим ответом 301 или 302 может фактически отказать в обслуживании вызываемой стороне или обманом (заменив значения в поле заголовка Contact) заставить вызывающего абонента связаться с мошенническим UA.
    Недобросовестные продавцы и мошенники всегда ищут новые способы заставить людей отвечать на звонки. Большинство телефонов имеют возможность фильтровать вызовы, предоставляя информацию о вызывающем абоненте, когда звонит телефон. Но все более распространенной техникой, которую используют мошенники, является фальсификация или «подделка» информации об идентификаторе вызывающего абонента (Caller ID). Поле заголовка From запросов INVITE, ACK указывает логический идентификатор инициатора запроса. Оно содержит URI отправителя запроса и, возможно, отображаемое имя пользователя. Эта информация передается в открытом виде без использования какого-либо механизма аутентификации, что делает SIP уязвимым для такой категории злонамеренных действий, как атаки с имитацией личности (подмена Caller ID, Caller ID spoofing).
    При подмене Caller ID на дисплее телефона вызываемого абонента отображается номер и/или имя звонящего абонента, которые создают впечатление, что звонки исходят от другого человека или компании. Хотя информация о звонящем может казаться местной, звонки часто осуществляются операторами телемаркетинга или мошенниками, находящимися за пределами страны. Этот тип спуфинга обычно выполняется с недобросовестными намерениями или злым умыслом, что заставило многих людей с недоверием относиться к идентификатору вызывающего абонента. Мошенники могут использовать и хорошо знакомые вызываемому абоненту номера, например, короткий номер банка, что делает многие методы социальной инженерии, такие как спам по IP-телефонии и вишинг, более эффективными.
    Вишинг (vishing, от Voice phishing) — это устная разновидность мошенничества, при которой злоумышленники, используя телефонную коммуникацию, под разными предлогами стимулируют людей к совершению действий якобы в их собственных интересах. В основе вишинга лежит социальная инженерия, которая предусматривает маскировку мошенников под определенную организацию – банк, поставщика услуг, государственную организацию, сотрудника ИТ-службы, и создание ощущения срочности или страха, что помогает уменьшить время на размышления и соответственно избежать подозрений со стороны жертвы
    Единственной эффективной контрмерой против подмены Caller ID является аутентификация отправителя SIP-запроса.
    Логическая «служба аутентификации» в исходной сети SIP-вызова, которая обычно реализуется на прокси-сервере, проверяет исходящие неподписанные цифровой подписью запросы от UA. Как только отправитель сообщения был аутентифицирован с помощью заранее согласованных со службой аутентификации средств, она создает и добавляет в исходящий запрос SIP поле заголовка Identity. Для этого требуется вычисление криптографической информации, включая цифровую подпись над некоторыми частями сообщения, которая позволяет другим объектам SIP проверить, что отправитель прошел аутентификацию, и его идентификационные данные были авторизованы
    Логическая «служба проверки подлинности» в сети завершения вызова SIP проверяет цифровую подпись и может предпринять соответствующие действия на основе результатов проверки.
    RFC 8225 «PASSporT: Personal Assertion Token» определяет метод создания и проверки токена, который криптографически подтверждает подлинность отправителя или, в более общем случае, URI или номер телефона, представляющий инициатора сообщений. PASSporT полезен для многих приложений персональной связи по IP-сетям и других сценариев межсетевого взаимодействия, где исходящая и принимающая стороны могут не иметь прямых доверительных отношений.
    RFC 8226 «Secure Telephone Identity Credentials: Certificates» определяет как сертификаты используются для безопасного подтверждения телефонного номера, если он используется в качестве идентификационной информации.
    Протокол RTP повсеместно используется в VoIP для передачи мультимедиа. RTP всегда работает поверх UDP. Нет смысла использовать TCP, потому что это добавит слишком много накладных расходов, а такая функции, как повторная передача пакетов, не имеет смысла для данных в реальном времени. Атаки на RTP особенно опасны, потому что они просты и применимы практически в любой среде VoIP
    Одна из атак заключается в том, чтобы вставить или смешать новый звук с активным разговором. Идея атаки в том, что одна или обе стороны слышат шум, слова или какой-то другой звук. Вставка звука приводит к тому, что реальный звук перезаписывается. Микширование звука приводит к добавлению или объединению новых звуков. Если новый звук имеет низкую громкость, слушатель интерпретирует его как фоновый шум.
    В качестве контрмеры также можно использовать шифрование RTP-потока. IP-телефоны D-Link предлагают возможность шифрования RTP-пакетов с использованием протокола SRTP.
    Источник: https://learn.dlink.ru/course/view.php?id=155

    NAT

    Для решения проблемы прохождения NAT трафиком телефонии на стороне клиента служат функции STUN, NAT Public IP, SIP ALG и Rport, подключение к внешнему SIP-серверу по VPN.
    Application Layer Gateway (ALG) — шлюз уровня приложений, является программным компонентом безопасности, реализованном на маршрутизаторе или межсетевом экране, и служит для управления протоколами 7 уровня, такими как SIP, FTP и другими
    Шлюз уровня приложений SIP (SIP ALG) проверяет и модифицирует IP-адреса и номера портов TCP/UDP в сообщениях SIP и SDP при прохождении трафика через межсетевой экран/маршрутизатор, позволяя, таким образом, устанавливать двухстороннюю SIP-сессию с абонентом, расположенным за NAT. При передаче сообщения SIP во внешнюю сеть SIP ALG меняет в соответствующих полях частный IP-адрес и номер порта в соответствии с таблицей трансляции NAT, а когда ответный пакет в рамках этой же сессии передается во внутреннюю сеть, выполняется обратное преобразование. Другими словами, SIP ALG можно рассматривать как NAT, работающий на 7 уровне модели OSI и умеющий менять IP-адреса и номера портов в сообщениях SIP и SDP.
    Следует отметить, что NAT также может быть реализован и на стороне провайдера Интернет, что в итоге приводит к двойному NAT для SIP-клиента. В этом случае использование SIP ALG может не дать желаемого результата.

    Источник: https://learn.dlink.ru/course/view.php?id=155

    Протокол STUN

    Протокол Session Traversal Utilities for NAT - может использоваться конечной точкой для определения IP-адреса и порта, выделенного ей NAT
    В качестве сервера STUN может использоваться маршрутизатор.
    Сервер STUN (STUN server): это объект, который получает запросы STUN (STUN request) и индикации STUN (STUN indication) и отправляет ответы STUN (STUN response).
    Клиент STUN (STUN client): это объект, который отправляет запросы STUN и получает ответы STUN и индикации STUN. Клиент STUN также может отправлять индикации. IP-телефон или маршрутизатор могут функционировать в качестве клиента STUN.
    В качестве транспортного протокола STUN использует UDP, TCP или TLS. Общеизвестный номер порта UDP/TCP для сообщений STUN 3478. Для TLS общеизвестный номер порта 5349.
    В настоящее время STUN поддерживает единственный метод Binding, который находит привязку IP-адреса и порта, созданную NAT для определенного клиента STUN.
    Каждый STUN-клиент отправляет запрос привязки (Binding request) серверу STUN.
    До того как запрос привязки поступит на сервер STUN, он может пройти через один или несколько NAT, расположенных между STUN-клиентом и STUN-сервером.

    Источник: https://learn.dlink.ru/course/view.php?id=155

    NAT Public IP

    Функция NAT Public IP, реализованная на VoIP-маршрутизаторах D-Link, предназначена для решения проблемы прохождения NAT трафиком голосовой сессии. Она позволяет администратору сети вручную настроить публичный IP-адрес и номер порта ближайшего к внешнему SIP-серверу маршрутизатора с NAT. Настроенные адресные параметры будут указываться в соответствующих полях, отправляемых клиентом из внутренней сети сообщений SIP и SDP при их прохождении через маршрутизатор, соединяющий локальную сеть с Интернет.

    Источник: https://learn.dlink.ru/course/view.php?id=155

    rport

    Функция rport поддерживается IP-телефонами и VoIP-маршрутизаторами
    Данное расширение протокола SIP служит для обеспечения симметричной маршрутизации ответов, когда клиент находится за NAT
    Оно определяет новый параметр для поля заголовка Via, называемый «rport», который позволяет клиенту запрашивать SIP-сервер, чтобы он отправил ответ на IP-адрес источника, взятый из заголовка полученного пакета и порт из заголовка TCP/UDP. Данная функция позволяет решить проблему двухсторонней связи при нахождении клиента за NAT, т.к. SIP-сервер будет отправлять телефону ответы, не на те IP-адрес и порт, которые указаны в поле заголовка Via сообщения SIP, а на те, которые указаны в поле IP-адреса источника пакета и поле с номером порта источника после трансляции адресов.
    Для корректной работы функции rport она должна поддерживаться и клиентом, и сервером SIP.
    Когда SIP-сервер получит от клиента запрос, он проверит самый верхний заголовок Via на наличие параметра rport без значения. Если он присутствует, сервер должен установить значение параметра в исходный порт запроса. SIP-сервер также должен вставить в ответ параметр received, содержащий IP-адрес источника из заголовка пакета с запросом, даже если он идентичен значению, указанному в заголовке Via:
    SIP-сервер отправит ответ на IP-адрес, указанный в параметре received и порт, указанный в параметре rport.

    Источник: https://learn.dlink.ru/course/view.php?id=155

    VPN

    В контексте IP-телефонии VPN могут использоваться для решения следующих задач:
    обход NAT;
    подключение к внешнему SIP-серверу;
    подключение к сервису телефонии удаленных сотрудников или сотрудников удаленных офисов, в случае географически распределенной сети организации.
    VPN-соединения могут создаваться на различных уровнях модели OSI. Наиболее распространённые типы VPN второго уровня представлены соединениями Point-to-Point Tunneling Protocol (PPTP) и Layer Two Tunneling Protocol (L2TP)
    Протоколы PPTP и L2TP основаны на протоколе PPP (Point-to-Point Protocol). Они разрабатывались и были приняты практически одновременно, но L2TP считается более эффективным для построения VPN, хотя его требования к вычислительным ресурсам немного выше по сравнению с PPTP. В большинстве случаев L2TP используется интернет-провайдерами для подключения клиентов и корпоративными пользователями.
    Протокол L2TP определяет создание туннелей между клиентами LAC (L2TP Access Concentrator, концентратор доступа L2TP) и LNS (L2TP Network Server, сетевой сервер L2TP) и последующую инкапсуляцию туннелируемых РРР-сессий
    Клиентом LAC может быть компьютер с установленным программным обеспечением L2TP, IP-телефон, маршрутизатор или межсетевой экран с поддержкой функции клиента L2TP. Эту функцию поддерживают IP-телефоны и маршрутизаторы D-Link. Оборудование с клиентом L2TP должно иметь подключение в Интернет. В этом случае создается виртуальное PPP-соединение, и клиент напрямую устанавливает туннель к LNS.
    Клиент LAC устанавливает L2TP-соединение с LNS на основе информации об имени пользователя/пароле, передаваемых в кадрах PPP.
    L2TP не обеспечивает механизмов безопасности, но позволяет дополнительно выполнять аутентификацию конечных точек при установлении туннеля. Она защищена от атак повторного воспроизведений и от атак, связанных с подделкой, при установлении туннеля. Однако данный механизм не предполагает никакой аутентификации после того, как туннель установлен. Это приводит к тому, что злоумышленнику достаточно просто вставить вредоносные пакеты в передаваемый PPP-поток после того, как выполнена аутентификация конечных точек туннеля.
    В IP-сетях пакеты L2TP инкапсулируются в UDP-дейтаграммы. Общеизвестный номер порта UDP для L2TP — 1701. Для обеспечения безопасности L2TP требуется, чтобы нижележащий транспортный протокол мог предоставлять сервисы шифрования, целостности и аутентификации для всего L2TP-трафика. Поэтому для обеспечения шифрования, целостности и аутентификации на уровне пакетов L2TP интегрируется с протоколом IPSec (L2TP over IPSec). Все управляющие пакеты и пакеты данных L2TP, относящиеся к конкретному туннелю, являются для IPSec однородными UDP/IP пакетами и инкапсулируются в ESP или AH в зависимости от выбранного алгоритма защиты пакетов.
    IP Security или IPSec используются на сетевом уровне для обеспечения сервисов VPN. Он представляет собой набор открытых стандартов, специально разработанный для обеспечения частных коммуникаций через сети, работающие на основе протоколов IPv4 и IPv6.
    Таблица 5.1. Стандарты IPSec
    Номер RFC Название
    4301 Security Architecture for the Internet Protocol
    4302 IP Authentication Header
    4303 IP Encapsulating Security Payload (ESP)
    8221 Cryptographic Algorithm Implementation Requirements For Encapsulating Security Payload (ESP) and Authentication Header (AH)
    2408 Internet Security Association and Key Management Protocol (ISAKMP)
    2409 The Internet Key Exchange (IKE)
    7296 The Internet Key Exchange (IKEv2) Protocol
    2412 The OAKLEY Key Determination Protocol
    В зависимости от того как IPSec реализован и сконфигурирован, он может предоставлять любые комбинации из следующих видов защиты:
    Конфиденциальность: IPSec может гарантировать, что данные не будут прочитаны неавторизованными сторонами. Это достигается путем шифрования данных с использованием криптографических алгоритмов и секретных ключей. Данные могут быть расшифрованы только с помощью секретных ключей.
    Целостность: IPSec может определять была ли информация изменена в процессе передачи. Целостность данных обеспечивается генерацией кода идентификации сообщения (message authentication code, MAC), который является криптографической контрольной суммой данных. Если данные были изменены, значения МАС вычисленные на стороне приемника и передатчика будет отличаться.
    Взаимная аутентификация: каждая конечная точка IPSec подтверждает идентификационную информацию другой конечной точки IPSec, с которой хочет обмениваться информацией. Это гарантирует, что сетевой трафик и данные отправлены ожидаемым узлом.
    Защита от replay-атак: одна и та же информация не доставляется множество раз, и данные не доставляются не по порядку. Однако IPSec не гарантирует, что данные доставляются строго в том порядке, в котором были отправлены.
    Управление доступом: конечные точки IPSec могут выполнять фильтрацию, гарантируя, что только авторизованные IPSec пользователи могут получать доступ к определенным сетевым ресурсам. Конечные точки IPSec также разрешают или блокируют прохождение определенного типа сетевого трафика.
    Перечисленные сервисы предоставляются на сетевом уровне, обеспечивая защиту для протокола IP и всех протоколов более высокого уровня, которые могут передаваться по IP.

    Достоинством SSL/TLS VPN является то, что из-за их широкого применения, они беспрепятственно пропускаются практически всеми публичными сетями. Недостаток — не слишком высокая производительность, сложность в настройке, а также необходимость установки дополнительного ПО.
    Популярной реализацией SSL/TLS VPN является OpenVPN (SSL 3.0/TLS 1.2/ TLS 1.3). OpenVPN в силу своей открытости имеет множество реализаций практически для всех платформ и на данный момент считается наиболее надежным вариантом VPN.
    Источник: https://learn.dlink.ru/course/view.php?id=155

    DHCP в телефонии

    В качестве протокола транспортного уровня DHCP использует UDP, порт 67 для отправки сообщений от клента к серверу и порт 68 для отправки сообщений от сервера к клиенту
    Клиент DHCP получает конфигурационные параметры от сервера DHCP
    Relay-агент узел ( маршрутизатор, коммутатор ), который передает сообщения между клиентом и сервером, когда клиент и сервер находятся в разных сетях
    Клиентом DHCP сервера может быть маршрутизатор, коммутатор, точка доступа, IP-телефон и др.
    Чтобы определить сеть, в которой находится клиент, и выдать IP-адрес из правильного диапазона серверы DHCP анализируют следующую информацию:
    IP-адрес интерфейса, на который пришел запрос.
    Наличие IP-адреса relay-агента в запросе.
    Сервер должен определить, находится ли клиент в той же сети, к которой подключен его интерфейс или для передачи запроса использовался relay-агент. Когда используется relay-агент, в поле giaddr (Gateway IP Address = Relay agent address) сообщения указан его IP-адрес. Если агент не используется, в этом поле указано значение 0.0.0.0. Далее сервер по IP-адресу интерфейса или relay-агента ищет нужный диапазон. Если диапазон существует, из него выбирается IP-адрес.
    Получив сообщение от клиента, каждый сервер определяет требуемую конфигурацию в соответствии с указанными сетевым администратором настройками. При выделении нового адреса, серверы должны проверить, что этот адрес в настоящий момент не используется. После этого они отправляют в ответ клиенту сообщение DHCPOFFER. Оно содержит предлагаемый IP-адрес в поле Your IP Address и другие конфигурационные параметры в поле options (маску подсети, адрес шлюза по умолчанию, адрес DNS-сервера, время аренды и др.). Каждый сервер резервирует предлагаемый адрес до тех пор, пока клиент не примет предложение. Если клиент находится в другой сети, сервер передает сообщение DHCPOFFER через relay-агента.
    Сообщение DHCPOFFER может отправляться широковещательно на IP-адрес 255.255.255.255, на IP-адрес, выделенный клиенту или на IP-адрес relay-агента, если он используется.
    В сообщениях DHCPDISCOVER и DHCPOFFER поле chaddr (Сlient MAC address) содержит MAC-адрес клиента. Когда сервер или relay-агент находятся с клиентом в пределах одного широковещательного домена (подключены к одному сегменту сети), они указывают в качестве МАС-адреса назначения сообщения МАС-адрес клиента.
    Клиент получает одно или несколько сообщений DHCPOFFER от одного или нескольких DHCP-серверов. Если предложений несколько, он выбирает лучшее из них и широковещательно отправляет выбранному серверу сообщение DHCPREQUEST с целью запроса предложенных конфигурационных параметров. Сообщение DHCPREQUEST должно включать опцию Server identifier, которая содержит IP-адрес выбранного сервера и опцию Requested IP address, содержащую предложенный IP-адрес. Широковещательная отправка сообщения гарантирует, что все серверы, отправившие предложения, будут проинформированы о выборе клиента. Если необходимо, это сообщение будет перенаправлено relay-агентом соответствующим серверам. Серверы, которые не были выбраны клиентом, могут отменить резервирование предложенного IP-адреса.
    После отправки сообщения DHCPREQUEST клиент переходит в состояние REQUESTING и ожидает ответ от выбранного сервера.
    Сервер, выбранный клиентом, сохраняет конфигурационные параметры клиента в памяти. Он также отправляет клиенту одноадресное подтверждение DHCPACK, содержащее конфигурационные параметры, аналогичные ранее предложенным в сообщении DHCPOFFER. Комбинация МАС-адреса клиента и назначенного ему IP-адреса становятся уникальным идентификатором времени аренды.

    Источник: https://learn.dlink.ru/course/view.php?id=155

    Источники
    Последнее изменение: 01.12.2024 17:53
    Предложить изменение
    Здесь пока нет комментариев
    Добавлять комментарии могут только авторизованные пользователи

    Авторизоваться
    Я буду рекламой
    Я тоже буду рекламой
    И я
    ВВЕРХ