Протокол инициации сеанса — Введение

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

Технология VoIP

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

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

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

  • Бюджетный

  • портативность

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

  • гибкость

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

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

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

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

Бюджетный

портативность

Никаких дополнительных кабелей

гибкость

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

Для звонка по 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 — это протокол прикладного уровня, определенный стандартом 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. Конечная точка может инициировать, изменять или завершать сеанс. Пользовательские агенты являются наиболее интеллектуальным устройством или сетевым элементом сети SIP. Это может быть программный телефон, мобильный телефон или ноутбук.

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

• User Agent Client (UAC) — объект, который отправляет запрос и получает ответ.

• Сервер агента пользователя (UAS) — объект, который получает запрос и отправляет ответ.

User Agent Client (UAC) — объект, который отправляет запрос и получает ответ.

Сервер агента пользователя (UAS) — объект, который получает запрос и отправляет ответ.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Самым низким уровнем SIP является его синтаксис и кодировка . Его кодировка указана с использованием расширенной грамматики формы Бэкуса-Наура (BNF).

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

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

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

Самым низким уровнем SIP является его синтаксис и кодировка . Его кодировка указана с использованием расширенной грамматики формы Бэкуса-Наура (BNF).

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

Далее идет уровень транзакций . Транзакция — это запрос, отправленный транзакцией клиента (с использованием транспортного уровня) в транзакцию сервера, вместе со всеми ответами на этот запрос, отправленными из транзакции сервера обратно клиенту. Любая задача, выполняемая клиентским агентом пользователя (UAC), выполняется с использованием ряда транзакций. Прокси без сохранения состояния не содержат уровень транзакций.

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

SIP — основной поток вызовов

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Полный вызов (от INVITE до 200 OK) называется диалогом .

SIP Трапеция

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

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

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

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

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

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

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

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

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

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

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

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

SIP — Обмен сообщениями

Сообщения SIP бывают двух типов — запросы и ответы .

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

• Аналогично, открывающая строка ответа содержит код ответа.

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

Аналогично, открывающая строка ответа содержит код ответа.

Методы запроса

SIP-запросы — это коды, используемые для установления связи. Чтобы дополнить их, существуют ответы SIP, которые обычно указывают, был ли запрос успешным или неудачным.

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

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

• МЕТОДЫ различают на два типа —

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

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

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

МЕТОДЫ различают на два типа —

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

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

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

Существует шесть основных методов, которые обсуждаются ниже.

ПРИГЛАШЕНИЕ

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

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

• Сеанс считается установленным, если сообщение INVITE получило ответ об успешном выполнении (2xx) или был отправлен ACK.



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

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

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

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

Сеанс считается установленным, если сообщение INVITE получило ответ об успешном выполнении (2xx) или был отправлен ACK.

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

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

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 или неустановленного сеанса.

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

BYE-запрос обычно проходит сквозной маршрут, минуя прокси-сервер.

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

РЕГИСТР

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

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

• Он содержит AOR (адрес записи) в заголовке « Кому» регистрируемого пользователя.

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

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

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

Он содержит AOR (адрес записи) в заголовке « Кому» регистрируемого пользователя.

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

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

ОТМЕНИТЬ

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

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

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

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

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

ACK

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

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

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

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

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

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

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

ОПЦИИ

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

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

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

ПОДПИСЫВАЕТСЯ используется пользовательскими агентами для установления подписки с целью получения уведомления о конкретном событии.

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

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

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

• Вы можете повторно подписаться снова, отправив другую ПОДПИСАТЬСЯ в диалоговом окне до истечения срока действия.

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

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

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

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

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

Вы можете повторно подписаться снова, отправив другую ПОДПИСАТЬСЯ в диалоговом окне до истечения срока действия.

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

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

ПОСТАВИТЬ В ИЗВЕСТНОСТЬ

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

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

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

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

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

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

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

ПУБЛИКОВАТЬ

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

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

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

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

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

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

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

СМОТРИ

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

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

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

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

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

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

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

ИНФОРМАЦИЯ

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

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

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

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

Прокси всегда будет пересылать запрос INFO.

ОБНОВИТЬ

UPDATE используется для изменения состояния сеанса, если сеанс не установлен. Пользователь может изменить кодек с помощью UPDATE.

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

PRACK

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

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

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

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

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

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

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

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

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

СООБЩЕНИЕ

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

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

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

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

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

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

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

SIP — коды ответов

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

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

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

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

• 1xx считается предварительным ответом, а остальные являются окончательными .

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

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

От 1xx до 5xx заимствовано из HTTP, а 6xx введено в SIP.

1xx считается предварительным ответом, а остальные являются окончательными .

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

Информационные ответы используются для индикации хода вызова . Обычно ответы от начала до конца (кроме 100 попыток).

Этот класс ответов предназначен для указания того, что запрос принят.

Обычно эти ответы класса отправляются серверами перенаправления в ответ на сообщение INVITE. Они также известны как ответы класса перенаправления.

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

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

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

SIP — Заголовки

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

Поля заголовка SIP в большинстве случаев следуют тем же правилам, что и поля заголовка HTTP. Поля заголовка определены как Заголовок: поле , где Заголовок используется для представления имени поля заголовка, а поле — это набор токенов, который содержит информацию. Каждое поле состоит из имени поля, за которым следуют двоеточие («:») и значение поля (т. Е. Имя-поля: значение-поля ).

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

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

заголовок	Компактная форма
к	T
С помощью	В
Call-ID	я
контакт	M
От	F
Предмет	S
Content-Length	я

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

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

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

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

SIP — протокол описания сеанса

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

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

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

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

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

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

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

Назначение СДП

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

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

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

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

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

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

  x = параметр1 параметр2 … параметрN

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

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

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

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

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

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

x = параметр1 параметр2 … параметрN

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

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

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

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

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

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

происхождения

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

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

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

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

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

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

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

Поле содержит —

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

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

Параметр ID сеанса представляет собой временную метку сетевого протокола времени (NTP) или случайное число, используемое для обеспечения уникальности.

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

Тип сети всегда IN для Интернета. Параметр типа адреса — это IP4 или IP6 для адреса IPv4 или IPv6 в десятичной форме с точками или полное имя хоста.

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

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

URI

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

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

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

Данные соединения

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

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

  c = <тип сети> <тип адреса> <адрес подключения>

• Параметр типа сети определяется как IN для Интернета.

• Тип адреса определяется как IP4 для адресов IPv4 и IP6 для адресов IPv6.

• Адрес подключения — это IP-адрес или хост, который будет отправлять медиа-пакеты, которые могут быть как многоадресными, так и одноадресными.

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

  Соединение-адрес = базовый адрес многоадресной / ТТЛ / число-адресов

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

Поле содержит —

c = <тип сети> <тип адреса> <адрес подключения>

Параметр типа сети определяется как IN для Интернета.

Тип адреса определяется как IP4 для адресов IPv4 и IP6 для адресов IPv6.

Адрес подключения — это IP-адрес или хост, который будет отправлять медиа-пакеты, которые могут быть как многоадресными, так и одноадресными.

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

Соединение-адрес = базовый адрес многоадресной / ТТЛ / число-адресов

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Формат-список содержит больше информации о СМИ. Обычно он содержит типы полезных данных мультимедиа, определенные в профилях аудио-видео RTP.

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

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

Атрибуты

Необязательное поле a = содержит атрибуты предыдущего мультимедийного сеанса. Это поле может использоваться для расширения SDP для предоставления дополнительной информации о мультимедиа . Если пользователь 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

SIP — Модель предложения / ответа

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

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

• Вызываемая сторона перечисляет свои мультимедийные возможности в ответе 200 OK на сообщение INVITE.

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

Вызываемая сторона перечисляет свои мультимедийные возможности в ответе 200 OK на сообщение INVITE.

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

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

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

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

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

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

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

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

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

В стандарте SDP поле субъекта является обязательным полем и должно содержать хотя бы один символ, предположительно s = — если субъекта нет.

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

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

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

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

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

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

пример

В следующем примере вызывающая сторона Tesla хочет установить аудио- и видеовызов с двумя возможными аудиокодеками и видеокодеком в 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вызов снова становится активным путем отправки другого сообщения INVITE с присутствующим атрибутом a = sendrecv . На следующем рисунке показан поток вызовов при удержании вызова.

SIP — Мобильность

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

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

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

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

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

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

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

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

Первая регистрация выполняется с новым оператором службы, который связывает 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

Первое сообщение INVITE, представленное на рисунке выше, будет отправлено на sip: registrar2.in; второе сообщение INVITE будет отправлено по адресу sip: sip: [email protected], которое будет перенаправлено на sip: [email protected] . Он достигает Тома и позволяет установить сессию. Периодически обе регистрации должны быть обновлены.

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

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

Посмотрите на поток вызовов, упомянутый на рисунке ниже.

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

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

• Выполняет re-INVITE, чтобы разрешить передачу сигналов и медиа на новый IP-адрес.

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

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

Выполняет re-INVITE, чтобы разрешить передачу сигналов и медиа на новый 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

Re-INVITE содержит новый IP-адрес Bowditch в полях заголовка Via и Contact и медиа-информацию SDP.

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

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

Например, если для прохождения NAT необходим прокси-сервер, необходимо изменить контактный URI — необходимо создать новый диалог. Следовательно, он должен отправить новое сообщение INVITE с заголовком Replaces, который идентифицирует существующий сеанс.

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

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

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

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

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

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

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

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

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

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

В результате Том отправляет сообщение INVITE with Replaces, которое создает новое диалоговое окно, которое включает новый посещаемый прокси-сервер, но не старый посещенный прокси-сервер.

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

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

Сервис Мобильность

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

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

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

SIP — Форкинг

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

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

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

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

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

• Параллельная форкинг
• Последовательный Форкинг

Параллельная форкинг

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

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

Последовательный Форкинг

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

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

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

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

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

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

Вызов колла и идентификатор звонка

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

UAC начинается с отправки приглашения. Из-за разветвления он может получить несколько 200 OK от разных UA. Каждый из них соответствует отдельной ветви вызова в пределах одного и того же вызова.

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

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

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

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

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

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

• Используя Request-URI, чтобы сигнализировать эту информацию

Используя расширение поля заголовка 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.

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

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

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

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

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

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

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

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

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

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

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

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

Record-Route

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

С помощью

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

SIP для PSTN

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

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

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

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

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

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

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

• SIP-телефон отправляет сообщение INVITE непосредственно на шлюз.

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

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

• Телефон генерирует мелодию звонка и переходит на телефонный коммутатор. Шлюз отображает 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-телефон набирает глобальный номер +91401234567, чтобы связаться с Джерри. Пользовательский агент SIP понимает его как глобальный номер и преобразует его в request-uri, используя DNS, и инициирует запрос.

SIP-телефон отправляет сообщение INVITE непосредственно на шлюз.

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

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

Телефон генерирует мелодию звонка и переходит на телефонный коммутатор. Шлюз отображает 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 — Кодеки

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

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

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

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

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

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

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

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

G.711

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

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

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

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

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

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. Он совместим по проводам с оригинальным кодеком, но имеет более низкие требования к процессору.

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

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

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

Часто используемым вариантом G.729 является G.729a. Он совместим по проводам с оригинальным кодеком, но имеет более низкие требования к процессору.

G.723.1

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

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

• Скорость передачи первого варианта составляет 6,4 кбит / с, а для второго варианта — 5,3 кбит / с.

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

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

Скорость передачи первого варианта составляет 6,4 кбит / с, а для второго варианта — 5,3 кбит / с.

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

GSM 06.10

GSM 06.10 — это кодек, разработанный для мобильных сетей GSM. Это также известно как GSM Full Rate.

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

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

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

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

SIP — B2BUA

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

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

B2BUA — как это работает?

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

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

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

Функции B2BUA

B2BUA обеспечивает следующие функции —

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

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

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

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

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

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

Часто B2BUA также внедряются в медиашлюзы, чтобы соединить медиапотоки для полного контроля над сеансом.

Пример B2BUA

Многие корпоративные телефонные системы АТС используют логику B2BUA.

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

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