SIP - Краткое руководство

Протокол инициации сеанса (SIP) - один из наиболее распространенных протоколов, используемых в технологии VoIP. Это протокол прикладного уровня, который работает вместе с другими протоколами прикладного уровня для управления сеансами мультимедийной связи через Интернет.

Технология VoIP

Прежде чем двигаться дальше, давайте сначала разберемся с некоторыми моментами о VoIP.

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

• Некоторые преимущества VOIP включают в себя -

  • Бюджетный

  • Portability

  • Без дополнительных кабелей

  • Flexibility

  • Видео-конференция

• Все, что вам нужно для VOIP-звонка, - это компьютер / ноутбук / мобильный телефон с подключением к Интернету. На следующем рисунке показано, как происходит вызов VoIP.

Итак, давайте вернемся к SIP.

SIP - Обзор

Ниже приведены несколько замечаний о SIP:

• SIP - это протокол сигнализации, используемый для создания, изменения и завершения мультимедийного сеанса через Интернет-протокол. Сеанс - это не что иное, как простой вызов между двумя конечными точками. Конечная точка может быть смартфоном, ноутбуком или любым устройством, которое может принимать и отправлять мультимедийный контент через Интернет.

• SIP - это протокол прикладного уровня, определенный стандартом IETF (Internet Engineering Task Force). Это определено вRFC 3261.

• SIP воплощает архитектуру клиент-сервер и использование URL и URI из HTTP а также схему кодирования текста и стиль заголовка из SMTP.

• SIP использует SDP (протокол описания сеанса), который описывает сеанс, и RTP (транспортный протокол реального времени), используемый для доставки голоса и видео по IP-сети.

• SIP может использоваться для двухсторонних (одноадресных) или многосторонних (многоадресных) сеансов.

• Другие приложения SIP включают передачу файлов, обмен мгновенными сообщениями, видеоконференцсвязь, онлайн-игры и распространение мультимедийных файлов.

Где подходит SIP?

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

На следующем рисунке показано место SIP в общей схеме вещей.

Обычно протокол SIP используется для интернет-телефонии и распределения мультимедиа между двумя или более конечными точками. Например, один человек может инициировать телефонный звонок другому человеку, используя SIP, или кто-то может организовать конференц-связь с большим количеством участников.

Протокол SIP был разработан как очень простой с ограниченным набором команд. Он также основан на тексте, поэтому любой может прочитать сообщение SIP, передаваемое между конечными точками в сеансе SIP.

Есть несколько организаций, которые помогают SIP в создании своей сети. В SIP каждый сетевой элемент идентифицируетсяSIP URI(Универсальный идентификатор ресурса), который похож на адрес. Ниже приведены сетевые элементы -

• Пользовательский агент
• Прокси сервер
• Сервер Регистратора
• Сервер перенаправления
• Сервер местоположения

Пользовательский агент

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

Пользовательские агенты логически разделены на две части -

• User Agent Client (UAC) - Сущность, которая отправляет запрос и получает ответ.

• User Agent Server (UAS) - Сущность, которая получает запрос и отправляет ответ.

Протокол SIP основан на архитектуре клиент-сервер, где телефон вызывающего абонента действует как клиент, который инициирует вызов, а телефон вызываемого абонента действует как сервер, который отвечает на вызов.

Прокси сервер

Это сетевой элемент, который принимает запрос от пользовательского агента и пересылает его другому пользователю.

• По сути, роль прокси-сервера очень похожа на маршрутизатор.

• У него есть некоторый интеллект, чтобы понять SIP-запрос и отправить его с помощью URI.

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

• Между источником и местом назначения может быть не более 70 прокси-серверов.

Есть два типа прокси-серверов -

• Stateless Proxy Server- Он просто пересылает полученное сообщение. Этот тип сервера не хранит никакой информации о вызове или транзакции.

• Stateful Proxy Server- Этот тип прокси-сервера отслеживает каждый полученный запрос и ответ и может использовать его в будущем при необходимости. Он может повторно передать запрос, если вовремя не будет ответа с другой стороны.

Сервер Регистратора

Сервер регистратора принимает запросы на регистрацию от пользовательских агентов. Это помогает пользователям аутентифицировать себя в сети. Он хранит URI и местоположение пользователей в базе данных, чтобы помочь другим серверам SIP в том же домене.

Взгляните на следующий пример, который показывает процесс регистрации SIP.

Здесь вызывающий хочет зарегистрироваться в домене TMC. Таким образом, он отправляет запрос REGISTER на сервер регистратора TMC, и сервер возвращает ответ 200 OK, поскольку он авторизовал клиента.

Сервер перенаправления

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

Сервер перенаправления использует базу данных для получения информации о местоположении и отвечает пользователю 3xx (ответ перенаправления). Коды ответов мы обсудим позже в этом руководстве.

Сервер местоположения

Сервер местоположения предоставляет информацию о возможных местоположениях вызывающего абонента на серверы перенаправления и прокси-серверы.

Только прокси-сервер или сервер перенаправления может связаться с сервером местоположения.

На следующем рисунке показаны роли, которые играет каждый из сетевых элементов при установлении сеанса.

SIP - Системная архитектура

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

• Самый нижний уровень SIP - это его syntax and encoding. Его кодировка указывается с помощью расширенногоBackus-Naur Form grammar (БНФ).

• На втором уровне находится transport layer. Он определяет, как Клиент отправляет запросы и получает ответы, а также как Сервер получает запросы и отправляет ответы по сети. Все элементы SIP содержат транспортный уровень.

• Далее идет transaction layer. Транзакция - это запрос, отправленный клиентской транзакцией (с использованием транспортного уровня) в серверную транзакцию, вместе со всеми ответами на этот запрос, отправленный серверной транзакцией обратно клиенту. Любая задача, которую выполняет клиент пользовательского агента (UAC), выполняется с помощью серии транзакций.Stateless proxies не содержат уровня транзакции.

• Слой над transaction layerназывается пользователем транзакции. Каждый из SIP-объектов, кромеStateless proxies, является пользователем транзакции.

На следующем изображении показан основной поток вызовов сеанса SIP.

Ниже приведено пошаговое объяснение вышеуказанного потока вызовов.

• Запрос INVITE, который отправляется на прокси-сервер, отвечает за инициирование сеанса.

• Прокси-сервер сенда 100 Trying немедленный ответ вызывающей стороне (Алисе), чтобы остановить повторную передачу запроса INVITE.

• Прокси-сервер ищет адрес Боба на сервере местоположения. После получения адреса он пересылает запрос INVITE дальше.

• После этого 180 Ringing (Предварительные ответы), сгенерированные Бобом, возвращаются Алисе.

• А 200 OK ответ генерируется вскоре после того, как Боб снимает трубку.

• Боб получает ACK от Алисы, как только он получит 200 OK.

• В то же время устанавливается сеанс, и пакеты (разговоры) RTP начинают поступать с обоих концов.

• После разговора любой участник (Алиса или Боб) может отправить BYE запрос на прекращение сеанса.

• BYE достигает напрямую от Алисы к Бобу, минуя прокси-сервер.

• Наконец, Боб отправляет 200 OK ответ для подтверждения BYE, и сеанс завершается.

• В приведенном выше базовом потоке вызовов три transactions (отмечены цифрами 1, 2, 3) доступны.

Полный вызов (от ПРИГЛАШЕНИЯ до 200 ОК) известен как Dialog.

SIP Трапеция

Как прокси помогает связать одного пользователя с другим? Давайте выясним с помощью следующей диаграммы.

Топология, показанная на схеме, известна как трапеция SIP. Процесс происходит следующим образом -

• Когда вызывающий абонент инициирует вызов, на прокси-сервер отправляется сообщение INVITE. После получения сообщения INVITE прокси-сервер пытается разрешить адрес вызываемого абонента с помощью DNS-сервера.

• После получения следующего маршрута прокси-сервер вызывающего абонента (прокси-сервер 1, также известный как исходящий прокси-сервер) пересылает запрос INVITE на прокси-сервер вызываемого абонента, который действует как входящий прокси-сервер (прокси 2) для вызываемого.

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

• Получив информацию от сервера местоположения, он переадресует вызов месту назначения.

• Как только пользовательские агенты узнают свой адрес, они могут обойти вызов, т. Е. Разговоры проходят напрямую.

SIP-сообщения бывают двух типов - requests и responses.

• Первая строка запроса содержит метод, который определяет запрос, и Request-URI, который определяет, куда должен быть отправлен запрос.

• Точно так же первая строка ответа содержит код ответа.

Способы запроса

SIP requestsкоды, используемые для установления связи. В дополнение к ним естьSIP responses которые обычно указывают, был ли запрос успешным или неудачным.

Эти SIP-запросы, известные как МЕТОДЫ, делают SIP-сообщения работоспособными.

• МЕТОДЫ можно рассматривать как SIP-запросы, поскольку они требуют выполнения определенного действия другим пользовательским агентом или сервером.

• МЕТОДЫ делятся на два типа -

  • Основные методы

  • Методы расширения

Основные методы

Ниже описаны шесть основных методов.

ПРИГЛАСИТЬ

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

• INVITE может содержать мультимедийную информацию о вызывающем абоненте в теле сообщения.

• Сеанс считается установленным, если на ПРИГЛАШЕНИЕ получен успешный ответ (2xx) или был отправлен ACK.



• Успешный запрос INVITE устанавливает dialog между двумя пользовательскими агентами, который продолжается до тех пор, пока не будет отправлено BYE для завершения сеанса.

• ПРИГЛАШЕНИЕ, отправленное в установленном диалоге, называется re-INVITE.

• Re-INVITE используется для изменения характеристик сеанса или обновления состояния диалога.

ПРИГЛАСИТЬ Пример

Следующий код показывает, как используется INVITE.

INVITE sips:[email protected] SIP/2.0 
   Via: SIP/2.0/TLS client.ANC.com:5061;branch = z9hG4bK74bf9 
   Max-Forwards: 70 
   From: Alice<sips:[email protected]>;tag = 1234567 
   To: Bob<sips:[email protected]>
   Call-ID: [email protected]  
   CSeq: 1 INVITE 
   Contact: <sips:[email protected]> 
   Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 
   Supported: replaces 
   Content-Type: application/sdp 
   Content-Length: ...  
   
   v = 0 
   o = Alice 2890844526 2890844526 IN IP4 client.ANC.com 
   s = Session SDP 
   c = IN IP4 client.ANC.com 
   t = 3034423619 0 
   m = audio 49170 RTP/AVP 0 
   a = rtpmap:0 PCMU/8000

ДО СВИДАНИЯ

BYE - это метод, используемый для завершения установленного сеанса. Это SIP-запрос, который может быть отправлен как вызывающим, так и вызываемым абонентом для завершения сеанса.

• Его нельзя отправить через прокси-сервер.

• Запрос BYE обычно направляется из конца в конец, минуя прокси-сервер.

• BYE не может быть отправлено на ожидающий INVITE или неустановленный сеанс.

РЕГИСТР

Запрос REGISTER выполняет регистрацию пользовательского агента. Этот запрос отправляется пользовательским агентом на сервер регистратора.

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

• Он несет AOR (адрес записи) в To заголовок зарегистрированного пользователя.

• Запрос REGISTER содержит период времени (3600 сек).

• Один пользовательский агент может отправить запрос REGISTER от имени другого пользовательского агента. Это известно какthird-party registration. ЗдесьFrom содержит URI стороны, подающей регистрацию от имени стороны, указанной в To заголовок.

ОТМЕНИТЬ

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

• Он может быть отправлен либо пользовательским агентом, либо прокси-сервером.

• CANCEL - это hop by hop request, т. е. проходит через элементы между пользовательским агентом и получает ответ, сгенерированный следующим элементом с состоянием.

ACK

ACK используется для подтверждения окончательных ответов на метод INVITE. ACK всегда идет в направлении INVITE. ACK может содержать тело SDP (характеристики среды), если оно не доступно в INVITE.

• ACK нельзя использовать для изменения описания носителя, которое уже было отправлено в начальном сообщении INVITE.

• Прокси-сервер с отслеживанием состояния, получающий ACK, должен определять, следует ли пересылать ACK в нисходящем направлении другому прокси-серверу или пользовательскому агенту.

• Для ответов 2xx ACK является сквозным, но для всех других окончательных ответов он работает по этапам, когда задействованы прокси с отслеживанием состояния.

ПАРАМЕТРЫ

Метод OPTIONS используется для запроса пользовательского агента или прокси-сервера о его возможностях и определения его текущей доступности. В ответе на запрос перечислены возможности пользовательского агента или сервера. Прокси-сервер никогда не генерирует запрос OPTIONS.

Методы расширения

Подписывайся

SUBSCRIBE используется пользовательскими агентами для создания подписки с целью получения уведомления о конкретном событии.

• Он содержит Expires поле заголовка, указывающее продолжительность подписки.

• По истечении указанного периода подписка автоматически прекращается.

• Подписка устанавливает диалог между пользовательскими агентами.

• Вы можете повторно оформить подписку снова, отправив еще одну ПОДПИСКУ в диалоговом окне до истечения срока действия.

• На подписку от пользователя будет получено 200 OK.

• Пользователи могут отказаться от подписки, отправив другой метод SUBSCRIBE со значением Expires 0 (ноль).

УВЕДОМЛЯТЬ

NOTIFY используется пользовательскими агентами для получения информации о наступлении определенного события. Обычно сообщение NOTIFY запускается в диалоговом окне, когда между подписчиком и уведомителем существует подписка.

• Каждый NOTIFY получит ответ 200 OK, если он получен уведомителем.

• NOTIFY содержат Event поле заголовка с указанием события и subscriptionstate поле заголовка, указывающее текущее состояние подписки.

• УВЕДОМЛЕНИЕ всегда отправляется при начале и прекращении подписки.

ПУБЛИКОВАТЬ

PUBLISH используется пользовательским агентом для отправки информации о состоянии события на сервер.

• ПУБЛИКАЦИЯ в основном полезна при наличии нескольких источников информации о событиях.

• Запрос PUBLISH похож на NOTIFY, за исключением того, что он не отправляется в диалоговом окне.

• Запрос PUBLISH должен содержать Expires поле заголовка и Min-Expires поле заголовка.

ССЫЛКА

REFER используется пользовательским агентом, чтобы направить другого пользовательского агента для доступа к URI для диалога.

• REFER должен содержать Refer-Toзаголовок. Это обязательный заголовок для REFER.

• REFER может быть отправлен внутри или вне диалога.

• А 202 Accepted вызовет запрос REFER, который указывает, что другой пользовательский агент принял ссылку.

ИНФОРМАЦИЯ

INFO используется пользовательским агентом для отправки информации сигнализации вызова другому пользовательскому агенту, с которым он установил медиа-сеанс.

• Это сквозной запрос.

• Прокси-сервер всегда пересылает запрос INFO.

ОБНОВИТЬ

ОБНОВЛЕНИЕ используется для изменения состояния сеанса, если сеанс не установлен. Пользователь мог изменить кодек с помощью UPDATE.

ЕСЛИ сеанс установлен, используется повторное приглашение для изменения / обновления сеанса.

PRACK

PRACK используется для подтверждения получения надежной передачи предварительного ответа (1XX).

• Обычно PRACK генерируется клиентом, когда он получает предварительный ответ, содержащий RSeq надежный порядковый номер и supported:100rel заголовок.

• PRACK содержит значение (RSeq + CSeq) в rack заголовок.

• Метод PRACK применяется ко всем предварительным ответам, кроме ответа 100 Trying, который никогда не передается надежно.

• PRACK может содержать тело сообщения; его можно использовать для обмена предложениями / ответами.

СООБЩЕНИЕ

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

• СООБЩЕНИЕ может быть отправлено в диалоге или вне диалога.

• Содержимое СООБЩЕНИЯ переносится в теле сообщения как MIME привязанность.

• А 200 OK Обычно принимается ответ, указывающий, что сообщение было доставлено в место назначения.

Ответ SIP - это сообщение, сгенерированное сервером пользовательского агента (UAS) или сервером SIP для ответа на запрос, сгенерированный клиентом. Это может быть формальное подтверждение для предотвращения повторной передачи запросов от UAC.

• Ответ может содержать некоторые дополнительные поля заголовка с информацией, необходимой для UAC.

• SIP имеет шесть ответов.

• 1xx до 5xx были заимствованы из HTTP, а 6xx введен в SIP.

• 1xx считается provisional ответ, а остальные final ответы.

S.No.	Описание функции
1	1xx: предварительные / информационные ответы Информационные ответы используются для обозначения call progress. Обычно ответы идут от конца до конца (кроме 100 попыток).
2	2xx: успешные ответы Этот класс ответов предназначен для указания того, что запрос был принят.
3	3xx: ответы перенаправления Обычно эти ответы класса отправляются серверами перенаправления в ответ на INVITE. Они также известны как ответы класса перенаправления.
4	4xx: ответы клиента при сбое Ответы клиента об ошибках указывают, что запрос не может быть выполнен, поскольку некоторые ошибки обнаруживаются со стороны UAC.
5	5xx: ответ при отказе сервера Этот ответ класса используется, чтобы указать, что запрос не может быть обработан из-за ошибки на сервере.
6	6xx: глобальное реагирование на сбой Этот класс ответа указывает, что сервер знает, что запрос не будет выполнен, где бы он ни был. В результате запрос не следует отправлять в другие места.

Заголовок - это компонент сообщения SIP, который передает информацию о сообщении. Он структурирован как последовательность полей заголовка.

Поля заголовка SIP в большинстве случаев подчиняются тем же правилам, что и поля заголовка HTTP. Поля заголовка определены какHeader: field, где заголовок используется для представления имени поля заголовка, а поле - это набор токенов, содержащих информацию. Каждое поле состоит из имени поля, за которым следует двоеточие (":") и значения поля (т. Е.field-name: field-value).

Заголовки SIP - компактная форма

Многие общие поля заголовка SIP имеют компактную форму, в которой имя поля заголовка обозначается одним символом нижнего регистра. Некоторые примеры приведены ниже -

Заголовок	Компактная форма
Чтобы	Т
Через	V
Call-ID	я
Связаться с нами	M
Из	F
Тема	S
Content-Length	я

Формат заголовка SIP

На следующем изображении показана структура типичного заголовка SIP.

Заголовки подразделяются на следующие категории в зависимости от их использования в SIP:

• Запрос и ответ
• Только запрос
• Только ответ
• Тело сообщения

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

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

• SDP обычно содержится в основной части протокола инициации сеанса, обычно называемого SIP.

• SDP определен в RFC 2327. Сообщение SDP состоит из серии строк, называемых полями, имена которых сокращены одной строчной буквой и расположены в необходимом порядке для упрощения синтаксического анализа.

Назначение SDP

Цель SDP - передавать информацию о медиапотоках в мультимедийных сеансах, чтобы помочь участникам присоединиться или собрать информацию о конкретном сеансе.

• SDP - это краткое структурированное текстовое описание.

• Он передает название и цель сеанса, медиа, протоколы, форматы кодеков, информацию о времени и транспортировке.

• Предварительный участник проверяет эту информацию и решает, присоединиться ли к сеансу, а также как и когда присоединиться к сеансу, если он решит это сделать.

• Формат имеет записи в виде <тип> = <значение>, где <тип> определяет уникальный параметр сеанса, а <значение> предоставляет конкретное значение для этого параметра.

• Общая форма сообщения SDP -

  x = parameter1 parameter2 ... parameterN

• Строка начинается с одной строчной буквы, например x. Между буквой и знаком = никогда не бывает пробелов, и между каждым параметром есть ровно один пробел. Каждое поле имеет определенное количество параметров.

Сессия Описание Параметры

Описание сеанса (* означает необязательно)

• v = (версия протокола)
• o = (владелец / создатель и идентификатор сеанса)
• s = (имя сеанса)
• i = * (информация о сеансе)
• u = * (URI описания)
• e = * (адрес электронной почты)
• p = * (номер телефона)
• c = * (информация о подключении - не требуется, если присутствует на всех носителях)
• b = * (информация о пропускной способности)
• z = * (настройки часового пояса)
• k = * (ключ шифрования)
• a = * (ноль или более строк атрибутов сеанса)

Версия протокола

Поле v = содержит номер версии SDP. Поскольку текущая версия SDP - 0, допустимое сообщение SDP всегда будет начинаться с v = 0.

Происхождение

Поле o = содержит информацию об отправителе сеанса и идентификаторах сеанса. Это поле используется для однозначной идентификации сеанса.

• Поле содержит -

  o = <имя пользователя> <идентификатор-сеанса> <версия> <тип-сети> <тип-адреса>

• В username Параметр содержит логин или хост отправителя.

• В session-id параметр - отметка времени протокола сетевого времени (NTP) или случайное число, используемое для обеспечения уникальности.

• В version - это числовое поле, которое увеличивается при каждом изменении сеанса, также рекомендуется использовать метку времени NTP.

• В network-typeвсегда IN для Интернета. Параметр типа адреса - IP4 или IP6 для адреса IPv4 или IPv6 в десятичной форме с точками или полное имя хоста.

Название сеанса и информация

Поле s = содержит имя сеанса. Он может содержать любое ненулевое количество символов. Необязательное поле i = содержит информацию о сеансе. Он может содержать любое количество символов.

URI

Необязательное поле u = содержит универсальный индикатор ресурса (URI) с дополнительной информацией о сеансе.

Адрес электронной почты и номер телефона

Необязательное поле e = содержит адрес электронной почты хоста сеанса. Необязательное поле p = содержит номер телефона.

Данные подключения

Поле c = содержит информацию о медиа-соединении.

• Поле содержит -

  c = <тип-сети> <тип-адреса> <адрес-соединения>

• В network-type Параметр определяется как IN для Интернета.

• В address-type определяется как IP4 для адресов IPv4 и IP6 для адресов IPv6.

• В connection-address IP-адрес или хост, который будет отправлять медиапакеты, которые могут быть многоадресными или одноадресными.

• Если многоадресная передача, поле адреса подключения содержит -

  адрес-соединения = базовый-многоадресный-адрес / ttl / количество-адресов

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

Пропускная способность

Необязательное поле b = содержит информацию о требуемой полосе пропускания. Это имеет вид -

b = модификатор: пропускная способность - значение

Время, время повтора и часовые пояса

Поле t = содержит время начала и время окончания сеанса.

t = время начала время остановки

Необязательное поле r = содержит информацию о времени повтора, которое может быть указано либо в NTP, либо в днях ( d ), часах ( h ) или минутах ( m ).

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

Объявления СМИ

Необязательное поле m = содержит информацию о типе медиа-сеанса. Поле содержит -

m = список транспортных форматов медиа-порта

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

• Параметр транспорта содержит используемый транспортный протокол или профиль RTP.

• Список форматов содержит дополнительную информацию о носителе. Обычно он содержит типы полезной нагрузки мультимедиа, определенные в профилях аудио-видео RTP.

Example:
m = audio 49430 RTP/AVP 0 6 8 99

Один из этих трех кодеков может использоваться для сеанса аудио-мультимедиа. Если предполагается установить три аудиоканала, будут использоваться три отдельных поля мультимедиа.

Атрибуты

Необязательное поле a = содержит атрибуты предыдущего сеанса мультимедиа. Это поле можно использовать дляextend SDP to provide more information about the media. Если пользователь SDP не полностью понимает это, поле атрибута можно игнорировать. Для каждого типа полезных данных мультимедиа, перечисленных в поле мультимедиа, может быть одно или несколько полей атрибутов.

Атрибуты в SDP могут быть либо

• уровень сеанса, или
• уровень СМИ.

Уровень сеанса означает, что атрибут указан перед первой строкой мультимедиа в SDP. Если это так, атрибут применяется ко всем строкам мультимедиа под ним.

Уровень СМИ означает, что он указан после строки СМИ. В этом случае атрибут применяется только к этому конкретному медиапотоку.

SDP может включать атрибуты как уровня сеанса, так и уровня мультимедиа. Если один и тот же атрибут отображается как оба, атрибут уровня мультимедиа переопределяет атрибут уровня сеанса для этого конкретного мультимедийного потока. Обратите внимание, что поле данных подключения также может быть либо уровнем сеанса, либо уровнем мультимедиа.

Пример SDP

Ниже приведен пример описания сеанса, взятый из RFC 2327 -

v = 0
o = mhandley2890844526 2890842807 IN IP4 126.16.64.4
s = SDP Seminar
i = A Seminar on the session description protocol
u = http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps
e = [email protected](Mark Handley)
c = IN IP4 224.2.17.12/127
t = 2873397496 2873404696
a = recvonly
m = audio 49170 RTP/AVP 0
m = video 51372 RTP/AVP 31
m = application 32416udp wb
a = orient:portrait

Использование SDP с SIP описано в ответе на предложение SDP RFC 3264. Тип тела сообщения по умолчанию в SIP - application/sdp.

• Вызывающая сторона перечисляет медиа-возможности, которые они желают получить в SDP, обычно либо в сообщении INVITE, либо в ACK.

• Вызываемая сторона перечисляет свои медиа-возможности в ответе 200 OK на ПРИГЛАШЕНИЕ.

Типичное использование SDP протоколом SIP включает следующие поля: версия, источник, тема, время, соединение, а также одно или несколько носителей и атрибутов.

• Поля темы и времени не используются SIP, но включены для совместимости.

• В стандарте SDP поле темы является обязательным и должно содержать по крайней мере один символ, предлагается использовать s = - если тема отсутствует.

• Поле времени обычно устанавливается на t = 00. SIP использует поля соединения, медиа и атрибутов для установки сеансов между UA.

• Поле происхождения имеет ограниченное использование с SIP.

• Идентификатор сеанса обычно остается постоянным на протяжении всего сеанса SIP.

• Версия увеличивается каждый раз при изменении SDP. Если отправляемый SDP не отличается от ранее отправленного, версия остается той же.

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

Спецификация предложения / ответа, RFC 3264, рекомендует использовать атрибут, содержащий a = rtpmap: для каждого поля мультимедиа. Медиапоток отклоняется путем установки номера порта на ноль для соответствующего поля мультимедиа в ответе SDP.

пример

В следующем примере вызывающий Тесла хочет настроить аудио- и видеовызов с двумя возможными аудиокодеками и видеокодеком в SDP, передаваемым в начальном INVITE -

v = 0 
o = John 0844526 2890844526 IN IP4 172.22.1.102  
s = - 
c = IN IP4 172.22.1.102 
t = 0 0 
m = audio 6000 RTP/AVP 97 98 
a = rtpmap:97 AMR/16000/1 
a = rtpmap:98 AMR-WB/8000/1 
m = video 49172 RTP/AVP 32 
a = rtpmap:32 MPV/90000

Кодеки обозначаются номерами профиля RTP / AVP 97, 98.

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

v = 0 
o = Marry 2890844526 2890844526 IN IP4 172.22.1.110 
s = - 
c = IN IP4 200.201.202.203 
t = 0 0 
m = audio 60000 RTP/AVP 8 
a = rtpmap:97 AMR/16000 
m = video 0 RTP/AVP 32

Если этот аудиовызов неприемлем, Том отправит ACK, а затем BYE, чтобы отменить вызов. В противном случае будет установлен аудиосеанс и обмен RTP-пакетами.

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

Правила предложения / ответа кратко изложены в следующих разделах.

Правила генерации предложения

Предложение SDP должно включать все необходимые поля SDP (включая v =, o =, s =, c = и t =). Это обязательные поля в SDP.

Обычно он включает медиа-поле ( m = ), но это не обязательно. Строки мультимедиа содержат все кодеки, перечисленные в порядке предпочтения. Единственное исключение из этого - если конечная точка поддерживает огромное количество кодеков, должны быть указаны наиболее вероятные или наиболее предпочтительные кодеки. Различные типы мультимедиа включают аудио, видео, текст, MSRP, BFCP и т. Д.

Правила генерации ответа

Ответ SDP на предложение должен быть построен в соответствии со следующими правилами:

• В ответе должно быть такое же количество m = строк в том же порядке, что и в ответе.

• Отдельные медиапотоки можно отклонить, установив для номера порта значение 0.

• Потоки принимаются путем отправки ненулевого номера порта.

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

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

Правила изменения сеанса

Любая из сторон может инициировать другой обмен предложением / ответом для изменения сеанса. При изменении сеанса необходимо соблюдать следующие правила:

• Номер версии исходной строки ( o = ) должен быть таким же, как и последняя отправленная, что указывает на то, что этот SDP идентичен предыдущему обмену, или он может быть увеличен на единицу, что указывает на новый SDP, который необходимо проанализировать.

• Предложение должно включать все существующие строки СМИ, и они должны быть отправлены в том же порядке.

• Дополнительные медиапотоки можно добавить в конец списка m = line.

• Существующий медиапоток можно удалить, установив номер порта на 0. Эта линия мультимедиа должна оставаться в SDP и во всех будущих обменах предложениями / ответами для этого сеанса.

Удержание вызова

Один участник вызова может временно перевести другого в режим ожидания. Это делается путем отправки сообщения INVITE с таким же SDP, что и исходное INVITE, но сa = sendonly атрибут присутствует.

Вызов снова становится активным, отправляя еще одно ПРИГЛАШЕНИЕ с a = sendrecvатрибут присутствует. На следующем рисунке показан поток вызовов при удержании вызова.

Personal mobility- это возможность иметь постоянный идентификатор на нескольких устройствах. SIP поддерживает базовую персональную мобильность с использованием метода REGISTER, который позволяет мобильному устройству изменять свой IP-адрес и точку подключения к Интернету, сохраняя при этом возможность принимать входящие вызовы.

SIP также может поддерживать service mobility - возможность пользователя сохранять те же услуги в мобильном телефоне

Мобильность SIP во время передачи обслуживания (предварительный вызов)

Устройство связывает свой контактный URI с адресом записи с помощью простой регистрации sip. В соответствии с IP-адресом устройства, регистрация разрешает автоматическое обновление этой информации в сети sip.

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

Например, давайте возьмем пример следующего потока вызовов. UA, который временно получил новый SIP URI от нового поставщика услуг. Затем UA выполняет двойную регистрацию -

• Первая регистрация выполняется с новым оператором службы, который связывает контактный URI устройства с URI AOR нового поставщика услуг.

• Второй запрос REGISTER направляется обратно к исходному поставщику услуг и предоставляет AOR нового поставщика услуг в качестве контактного URI.

Как показано ниже в потоке вызовов, когда запрос поступает в сеть исходного поставщика услуг, сообщение INVITE перенаправляется новому поставщику услуг, который затем направляет вызов пользователю.

Для первой регистрации сообщение, содержащее URI устройства, будет:

REGISTER sip:visited.registrar1.com SIP/2.0 
Via: SIP/2.0/UDP 172.22.1.102:5060;branch = z9hG4bK97a7ea349ce0fca 
Max-Forwards: 70 
To: Tom <sip:[email protected]> 
From: Tom <sip:[email protected]>;tag = 72d65a24 
Call-ID: [email protected] 
CSeq: 1 REGISTER 
Contact: <sip:[email protected]:5060> 
Expires: 600000 
Content-Length: 0

Второе регистрационное сообщение с перемещаемым URI будет -

REGISTER sip:home.registrar2.in SIP/2.0 
Via: SIP/2.0/UDP 172.22.1.102:5060;branch = z9hG4bKah4vn2u 
Max-Forwards: 70 
To: Tom <sip:[email protected]> 
From: Tom <sip:[email protected]>;tag = 45375 
Call-ID:[email protected] 
CSeq: 6421 REGISTER 
Contact: <sip:[email protected]> 
Content-Length: 0

Первое ПРИГЛАШЕНИЕ, представленное на рисунке выше, будет отправлено на адрес sip: registrar2.in; второе ПРИГЛАШЕНИЕ будет отправлено на sip: sip: [email protected], которое будет отправлено наsip:[email protected]. Он достигает Тома и позволяет установить сеанс. Периодически необходимо обновлять обе регистрации.

Мобильность во время разговора (повторное приглашение)

Пользовательский агент может изменить свой IP-адрес во время сеанса при переключении из одной сети в другую. Базовый SIP поддерживает этот сценарий, так как повторное ПРИГЛАШЕНИЕ в диалоговом окне можно использовать для обновления контактного URI и изменения медиаинформации в SDP.

Взгляните на поток вызовов, показанный на рисунке ниже.

• Здесь Том обнаруживает новую сеть,

• Использует DHCP для получения нового IP-адреса и

• Выполняет повторное ПРИГЛАШЕНИЕ, чтобы разрешить передачу сигналов и мультимедиа на новый IP-адрес.

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

Повторное ПРИГЛАШЕНИЕ будет выглядеть следующим образом -

INVITE sip:[email protected] SIP/2.0  
Via: SIP/2.0/UDP 172.22.1.102:5060;branch = z9hG4bK918f5a84fe6bf7a 
Max-Forwards: 70 

To: <sip:[email protected]> 

From: sip:[email protected];tag = 70133df4 
Call-ID: 76d4861c19c 
CSeq: 1 INVITE 
Accept: application/sdp 
Accept-Language: en 

Allow: INVITE,ACK,CANCEL,BYE,INFO,OPTIONS,REFER,NOTIFY,SUBSCRIBE 
Contact: <sip:172.22.1.102:5060>; 
Content-Type: application/sdp 
Content-Length: 168 

v = 0
o = PPT 40467 40468 IN IP4 192.168.2.1 
s = - 
c = IN IP4 192.168.2.1 
b = AS:49 
t = 0 0 
b = RR:0 
b = RS:0 
a = rtpmap:97 AMR/8000/1 
m = audio 6000 RTP/AVP 96 
a = fmtp:102 0-15 
a = ptime:20 
a = maxptime:240

Повторное ПРИГЛАШЕНИЕ содержит новый IP-адрес Bowditch в полях заголовка Via и Contact, а также медиа-информацию SDP.

Мобильность в Midcall (с заменой заголовка)

При промежуточной мобильности фактический набор маршрутов (набор прокси-серверов SIP, по которым должны проходить сообщения SIP) должен измениться. Мы не можем использовать re-INVITE в мобильной связи

Например, если для прохождения NAT необходим прокси-сервер, необходимо изменить URI контакта - необходимо создать новый диалог. Следовательно, он должен отправить новое ПРИГЛАШЕНИЕ с заголовком Replaces, который идентифицирует существующий сеанс.

Note - Предположим, что A и B оба находятся в состоянии вызова, и если A получает еще одно ПРИГЛАШЕНИЕ (скажем, от C) с заголовком замены (должно соответствовать существующему диалогу), то A должен принять INVITE и завершить сеанс с помощью B и передать все ресурсы в вновь сформированный диалог.

Поток вызовов показан на следующем рисунке. Это похоже на предыдущий поток вызовов с использованием re-INVITE, за исключением того, что BYE автоматически генерируется для завершения существующего диалога, когда принимается INVITE с заменами.

Ниже приведены моменты, которые следует отметить в этом сценарии -

• Существующий диалог между Томом и Джерри включает старый посещенный прокси-сервер.

• Новый диалог, использующий новую беспроводную сеть, требует включения нового посещенного прокси-сервера.

• В результате Том отправляет ПРИГЛАШЕНИЕ с заменами, которое создает новый диалог, который включает новый посещенный прокси-сервер, но не старый посещенный прокси-сервер.

• Когда Джерри принимает ПРИГЛАШЕНИЕ, автоматически отправляется BYE для завершения старого диалога, который проходит через старый посещенный прокси-сервер, который теперь больше не участвует в сеансе.

• Результирующий медиа-сеанс устанавливается с использованием нового IP-адреса Тома из SDP в сообщении INVITE.

Мобильность услуг

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

SIP может легко поддерживать мобильность услуг через Интернет. При подключении к Интернету UA, настроенный на использование набора прокси в Индии, может по-прежнему использовать эти прокси в роуминге в Европе. Это не влияет на качество сеанса мультимедиа, поскольку мультимедиа всегда проходит напрямую между двумя UA и не проходит через прокси-серверы SIP.

Резидентные службы конечной точки доступны только тогда, когда конечная точка подключена к Интернету. Завершающая служба, такая как служба переадресации вызовов, реализованная в конечной точке, выйдет из строя, если конечная точка временно потеряла подключение к Интернету. Следовательно, некоторые службы реализуются в сети с использованием прокси-серверов SIP.

Иногда прокси-сервер пересылает один вызов SIP нескольким конечным точкам SIP. Этот процесс известен как разветвление. Здесь один вызов может одновременно звонить нескольким конечным точкам.

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

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

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

У нас есть два типа разветвления -

• Параллельное разветвление
• Последовательное разветвление

Параллельное разветвление

В этом сценарии прокси-сервер разветвляет ПРИГЛАШЕНИЕ, скажем, двум устройствам (UA2, UA3) одновременно. Оба устройства сгенерируют 180 звонков, и тот, кто получит звонок, сгенерирует 200 OK. Ответ (предположим, что UA2), который первым достигает отправителя, устанавливает сеанс с UA2. Для другого ответа будет запущена ОТМЕНА.

Если отправитель получает оба ответа одновременно, то на основе q-значения он пересылает ответ.

Последовательное разветвление

В этом сценарии прокси-сервер отправит сообщение INVITE одному устройству (UA2). Если UA2 в это время недоступен или занят, прокси-сервер отправит его на другое устройство (UA3).

Филиал - ID и тег

Идентификаторы веток помогают прокси-серверам сопоставлять ответы на разветвленные запросы. Без идентификаторов филиалов прокси-сервер не сможет понять ответвленный ответ. Идентификатор ветки будет доступен в заголовке Via.

Теги используются UAC для различения нескольких окончательных ответов от разных UAS. UAS не может определить, был ли запрос разветвлен или нет. Следовательно, необходимо добавить тег.

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

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

Участок вызова и идентификатор вызова

Участок вызова относится к сигнальным отношениям один к одному между двумя пользовательскими агентами. Идентификатор вызова - это уникальный идентификатор, передаваемый в сообщении SIP, который относится к вызову. Вызов - это набор ветвей вызова.

UAC начинается с отправки ПРИГЛАШЕНИЯ. Из-за разветвления он может получить несколько 200 OK от разных UA. Каждый соответствует отдельному участку вызова в рамках одного вызова.

Таким образом, вызов - это группа ветвей вызова. Участок вызова относится к сквозному соединению между UA.

Пространства CSeq в двух направлениях ветви вызова независимы. В одном направлении порядковый номер увеличивается для каждой транзакции.

Голосовая почта

Голосовая почта сейчас очень распространена среди корпоративных пользователей. Это телефонное приложение. Когда вызываемая сторона недоступна или не может принять вызов, УАТС сообщит вызывающей стороне, чтобы она оставила голосовое сообщение.

Пользовательский агент либо получит ответ 3xx, либо перенаправит на сервер голосовой почты, если номер вызываемой стороны недоступен. Однако требуется какое-то расширение SIP, чтобы указать системе голосовой почты, какой почтовый ящик использовать, то есть какое приветствие следует воспроизвести и где сохранить записанное сообщение. Есть два способа добиться этого -

• Используя расширение поля заголовка SIP

• Используя Request-URI для передачи этой информации

Предположим для пользователя sip:[email protected] имеет систему голосовой почты по адресу sip: voicemail.tutorialspoint.com, которая предоставляет голосовую почту, Request-URI сообщения INVITE, когда оно пересылается на сервер голосовой почты, может выглядеть так:

sip:voicemail.tutorialspoint.com;target = sip:[email protected];cause = 486

На следующем рисунке показано, как Request-URI переносит идентификатор почтового ящика и причину (здесь 486).

Как мы знаем, прокси-сервер может быть как без состояния, так и с отслеживанием состояния. Здесь, в этой главе, мы обсудим больше прокси-серверов и маршрутизации SIP.

Прокси-сервер без сохранения состояния

Прокси-сервер без сохранения состояния просто пересылает полученное сообщение. Этот тип сервера не хранит никакой информации о вызове или транзакции.

• Прокси-серверы без сохранения состояния забывают о запросе SIP после его перенаправления.
• Транзакция будет быстрой через прокси без сохранения состояния.

Прокси-сервер с отслеживанием состояния

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

• Прокси-серверы с отслеживанием состояния запоминают запрос после того, как он был перенаправлен, поэтому они могут использовать его для предварительной маршрутизации. Прокси-серверы с отслеживанием состояния поддерживают состояние транзакции . Транзакция подразумевает состояние транзакции,notсостояние вызова .

• Транзакции с прокси-серверами с отслеживанием состояния выполняются не так быстро, как без сохранения состояния.

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

Через и Рекорд-маршрут

Запись-Маршрут

Заголовок Record-Route вставляется в запросы прокси-серверами, которые хотели быть на пути последующих запросов для того же идентификатора вызова. Затем он используется пользовательским агентом для маршрутизации последующих запросов.

Через

Заголовки Via вставляются серверами в запросы для обнаружения петель и помогают ответам найти путь обратно к клиенту. Это полезно только для ответов, которые достигают места назначения.

• UA сам генерирует и добавляет свой собственный адрес в поле заголовка Via при отправке запроса.

• Прокси-сервер, пересылающий запрос, добавляет поле заголовка Via, содержащее его собственный адрес, в начало списка полей заголовка Via.

• Прокси-сервер или UA, генерирующий ответ на запрос, копирует все поля заголовка Via из запроса по порядку в ответ, а затем отправляет ответ на адрес, указанный в верхнем поле заголовка Via.

• Прокси-сервер, получающий ответ, проверяет верхнее поле заголовка Via и сопоставляет его собственный адрес. Если он не совпадает, ответ был отклонен.

• Затем верхнее поле заголовка Via удаляется, а ответ пересылается на адрес, указанный в следующем поле заголовка Via.

Поля заголовка Via содержат имя протокола, номер версии и транспорт (SIP / 2.0 / UDP, SIP / 2.0 / TCP и т. Д.) И содержат номера портов и параметры, такие как получено, rport, ветвь.

• Полученный тег добавляется в поле заголовка Via, если UA или прокси-сервер получает запрос с адреса, отличного от адреса, указанного в верхнем поле заголовка Via.

• UA и прокси-серверы добавляют параметр ветвления в поля заголовка Via, который вычисляется как хэш-функция Request-URI, а также номера To, From, Call-ID и CSeq.

SIP (программный телефон) и PSTN (старый телефон) являются разными сетями и говорят на разных языках. Поэтому нам нужен транслятор (здесь шлюз) для связи между этими двумя сетями.

Давайте рассмотрим пример, чтобы показать, как SIP-телефон выполняет телефонный звонок в PSTN через шлюз PSTN.

В этом примере Том (sip:[email protected]) это sip-телефон, и Джерри использует глобальный номер телефона +91401234567.

SIP в PSTN через шлюзы

На следующем рисунке показан поток вызовов от SIP к PSTN через шлюзы.

Ниже приводится пошаговое объяснение всего процесса, который происходит при выполнении звонка с SIP-телефона на PSTN.

• Прежде всего, (Том) SIP-телефон набирает глобальный номер +91401234567, чтобы связаться с Джерри. Пользовательский агент SIP понимает его как глобальное число и преобразует его в URI запроса с помощью DNS и инициирует запрос.

• SIP-телефон отправляет ПРИГЛАШЕНИЕ прямо на шлюз.

• Шлюз инициирует вызов в PSTN, выбирая соединительную линию SS7 ISUP для следующего телефонного коммутатора в PSTN.

• Набранные цифры из сообщения INVITE отображаются в ISUP IAM. Сообщение о завершении адреса ISUP (ACM) отправляется обратно по PSTN, чтобы указать, что транк был создан.

• Телефон издает сигнал вызова, и он поступает на телефонный коммутатор. Шлюз отображает ACM в ответ 183 Session Progress, содержащий SDP, указывающий порт RTP, который шлюз будет использовать для передачи звука из PSTN.

• После приема 183 UAC вызывающего абонента начинает принимать RTP-пакеты, отправленные от шлюза, и представляет вызывающему абоненту звук, чтобы он знал, что вызываемый абонент продвигается в PSTN.

• Вызов завершается, когда вызываемая сторона отвечает на телефонный звонок, в результате чего телефонный коммутатор отправляет ответное сообщение (ANM) на шлюз.

• Затем шлюз прерывает аудиосоединение PSTN в обоих направлениях и отправляет вызывающему абоненту ответ 200 OK. Поскольку медиа-путь RTP уже установлен, шлюз отвечает на SDP в 183, но не вызывает изменений в RTP-соединении.

• UAC отправляет ACK для завершения обмена сигналами SIP. Поскольку в ISUP нет эквивалентного сообщения, шлюз принимает ACK.

• Вызывающий отправляет BYE на шлюз для завершения. Шлюз отображает BYE в сообщение о выпуске ISUP (REL).

• Шлюз отправляет 200OK в BYE и получает RLC от PSTN.

Кодек, сокращение от кодер-декодер, выполняет две основные операции:

• Во-первых, он преобразует аналоговый речевой сигнал в его эквивалентную цифровую форму, чтобы его можно было легко передать.

• После этого он преобразует сжатый цифровой сигнал обратно в его исходную аналоговую форму, чтобы его можно было воспроизвести.

На рынке доступно множество кодеков - некоторые из них бесплатны, а другие требуют лицензирования. Кодеки различаются по качеству звука и соответственно по полосе пропускания.

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

Здесь, в этой главе, мы обсудим несколько популярных аудиокодеков SIP, которые широко используются.

G.711

G.711 - это кодек, который был представлен ITU в 1972 году для использования в цифровой телефонии. Кодек имеет два варианта:A-Law используется в Европе и на международных телефонных линиях, uLaw используется в США и Японии.

• G.711 использует логарифмическое сжатие. Он сжимает каждую 16-битную выборку до 8 бит, таким образом, достигается степень сжатия 1: 2.

• Битрейт составляет 64 кбит / с в одном направлении, поэтому вызов потребляет 128 кбит / с.

• G.711 - это тот же кодек, который используется в сети PSTN, поэтому он обеспечивает наилучшее качество передачи голоса. Однако он потребляет больше полосы пропускания, чем другие кодеки.

• Лучше всего он работает в локальных сетях, где у нас есть большая пропускная способность.

G.729

G.729 - это кодек с низкими требованиями к полосе пропускания; он обеспечивает хорошее качество звука.

• Кодек кодирует звук в кадрах длиной 10 мс. При частоте дискретизации 8 кГц кадр 10 мс содержит 80 отсчетов звука.

• Алгоритм кодека кодирует каждый кадр в 10 байтов, поэтому результирующая скорость передачи данных составляет 8 кбит / с в одном направлении.

• G.729 - лицензированный кодек. Конечные пользователи, которые хотят использовать этот кодек, должны купить оборудование, которое его реализует (будь то телефон VoIP или шлюз).

• Часто используемый вариант G.729 - G.729a. Он совместим по проводам с исходным кодеком, но требует меньших требований к процессору.

G.723.1

G.723.1 является результатом конкурса, объявленного ITU с целью разработки кодека, который позволял бы звонить по модемным каналам со скоростью 28,8 и 33 кбит / с.

• У нас есть два варианта G.723.1. Оба они работают с аудиокадрами длительностью 30 мс (т. Е. 240 отсчетов), но алгоритмы различаются.

• Битрейт первого варианта составляет 6,4 кбит / с, а для второго варианта - 5,3 кбит / с.

• Кодированные кадры для двух вариантов имеют длину 24 и 20 байтов соответственно.

GSM 06.10

GSM 06.10 - это кодек, разработанный для мобильных сетей GSM. Он также известен как полная скорость GSM.

• Этот вариант кодека GSM можно свободно использовать, поэтому вы часто найдете его в приложениях VoIP с открытым исходным кодом.

• Кодек работает с аудиокадрами длиной 20 мс (т. Е. 160 отсчетов) и сжимает каждый кадр до 33 байтов, поэтому результирующая скорость передачи данных составляет 13 кбит / с.

Двухкомпонентный пользовательский агент (B2BUA) - это логический сетевой элемент в приложениях SIP. Это тип SIP UA, который получает запрос SIP, затем переформулирует запрос и отправляет его как новый запрос.

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

B2BUA - Как это работает?

Агент B2BUA работает между двумя конечными точками телефонного звонка и делит канал связи на два. call legs. B2BUA - это объединение UAC и UAS. Он участвует во всей сигнализации SIP между обоими концами установленного вызова. Поскольку B2BUA доступен в диалоговом режиме, поставщик услуг может реализовывать некоторые дополнительные функции.

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

B2BUA поддерживает полное состояние для вызовов, которые он обрабатывает. Каждая сторона B2BUA работает как стандартный сетевой элемент SIP, как указано в RFC 3261.

Функции B2BUA

B2BUA предоставляет следующие функции -

• Управление вызовами (биллинг, автоматическое отключение вызова, перевод вызова и т. Д.)

• Сетевое взаимодействие (возможно, с адаптацией протокола)

• Скрытие внутреннего устройства сети (частных адресов, топологии сети и т. Д.)

Часто B2BUA также реализуются в медиашлюзах для объединения медиапотоков для полного контроля над сеансом.

Пример B2BUA

Многие корпоративные телефонные системы частных телефонных станций (PBX) включают логику B2BUA.

Некоторые межсетевые экраны имеют встроенную функциональность ALG (Application Layer Gateway), которая позволяет межсетевому экрану авторизовать SIP и медиа-трафик, сохраняя при этом высокий уровень безопасности.

Другой распространенный тип B2BUA известен как пограничный контроллер сеанса (SBC).