SIP и голосовая связь для команд обмена сообщениями

SIP — протокол инициации сеанса, RFC 3261 — это протокол сигнализации прикладного уровня, который создает, изменяет и разрывает сеансы передачи мультимедиа в реальном времени по IP , чаще всего голосовые и видео. Важно отметить, что SIP не передает само мультимедиа: он согласовывает и контролирует сеанс, а аудио или видео затем передаются отдельно по RTP .

Его дизайн намеренно напоминает HTTP — удобочитаемые текстовые сообщения, методы запросов, трехзначные коды ответов и URI-адресация (sip:alice@example.com) — что делает его доступным для команд, уже хорошо знакомых с веб-протоколами. Именно поэтому голосовая связь органично сочетается с обменом сообщениями в рамках CPaaS: это еще один канал, управляемый API , с привычной структурой запроса/ответа.

Главными действующими лицами являются пользовательские агенты (UAC, отправляющий запросы, и UAS, отвечающий на них), а также инфраструктура: регистраторы регистрируют местоположение пользователя, а прокси-серверы перенаправляют запросы к нему. Для команды, занимающейся обменом сообщениями, голосовая связь чаще всего является резервным каналом OTP и каналом срочных оповещений — поэтому понимание SIP означает понимание того, как этот канал фактически взаимодействует.

SIP определяет небольшой набор методов запроса. INVITE запускает или изменяет сессию, ACK подтверждает окончательный ответ на запрос INVITE , а BYE завершает установленный вызов. REGISTER сообщает регистратору, где можно связаться с пользователем, CANCEL прерывает ожидающий запрос, а OPTIONS запрашивает возможности. В более поздних RFC добавлены такие методы, как INFO, MESSAGE, SUBSCRIBE/NOTIFY и UPDATE.

Ответы в шести классах повторяют трехзначную схему HTTP . 1xx — предварительные (100 Trying, 180 Ringing); 2xx — успешный (200 OK); 3xx — перенаправление; 4xx — ошибки клиента (404 Not Found, 486 Busy Here, 407 Proxy Authentication Required); 5xx — ошибки сервера; и 6xx — глобальные сбои (603 Decline). Изучение сначала класса, а затем кода — это способ быстро выявить и устранить проблему при неудачном вызове.

Классическая особенность, которую нужно усвоить, — это трехэтапное рукопожатие для установления соединения: INVITE , затем 200 OK, затем отдельное ACK — в отличие от большинства протоколов запрос/ответ, ACK для INVITE представляет собой отдельную транзакцию. Неправильная обработка этого ACK — одна из самых распространенных причин, по которым звонки проходят, но соединение так и не устанавливается.

Поскольку SIP только передает сигналы, фактические параметры мультимедиа описываются протоколом SDP (Session Description Protocol, RFC 4566), который передается внутри тел сообщений SIP . В SDP каждая сторона объявляет поддерживаемые ею кодеки, IP адрес и порт, на котором будет приниматься мультимедиа, а также другие атрибуты мультимедиа.

SIP используется модель «предложение/ответ» (RFC 3264): INVITE вызывающего абонента содержит предложение SDP , описывающее его возможности, а ответ вызываемого абонента содержит ответ SDP , выбирающий общий набор возможностей. Именно это согласование позволяет двум конечным точкам договориться о кодеке и пути передачи медиаданных до начала передачи аудиосигнала.

Согласованные медиаданные затем передаются по RTP (Real-time Transport Protocol), который передает аудио/видеопакеты с порядковыми номерами и временными метками, а также по протоколу RTCP для проверки качества. Если медиаданные должны быть конфиденциальными, SRTP (Secure RTP ) шифрует и аутентифицирует эти пакеты. Следует придерживаться следующей модели: SIP + SDP устанавливают соединение, RTP / SRTP передают его — два отдельных пути, которые могут даже проходить по разным маршрутам в сети.

Проведите простой звонок. UAC вызывающего абонента отправляет INVITE (с предложением SDP ) вызываемому абоненту, возможно, через один или несколько прокси. Вызываемая сторона отвечает 100 Trying, затем 180 Ringing (пока телефон подает сигнал оповещения), и, наконец, 200 OK, неся ответ SDP после того, как вызываемый абонент принимает его.

Абонент отвечает ACK, и в этот момент устанавливается сессия: RTP медиапотека передается напрямую между конечными точками в соответствии с согласованным SDP , независимо от прокси-серверов, которые устанавливают соединение. Изменения в ходе разговора — удержание вызова, добавление видео, переключение кодеков — осуществляются с помощью повторного INVITE или UPDATE, передающих новый SDP .

Обе стороны завершают вызов, отправляя BYE , на что отвечают 200 OK, что разрывает сессию и останавливает передачу медиаданных. Сбои прерывают поток: вместо 200 OK приходит ошибка 486 Busy Here или 408 Request Timeout, что означает, что вызов никогда не доходит до стадии ACK. Именно эта последовательность действий делает SIP логи понятными в случае некорректной работы вызова.

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

На границе сети находится контроллер граничных сессий ( SBC ) — элемент, обеспечивающий безопасность и контроль SIP на периферии сети. Он выполняет скрытие топологии, обход NAT, взаимодействие протоколов и нормализацию между различными диалектами SIP , контроль доступа и ограничение скорости, а также часто привязку и транскодирование медиафайлов. SBC для SIP — это примерно то же самое, что сигнальный межсетевой экран для SS7 / Diameter : контролируемая контрольная точка на границе доверия.

VoLTE (Voice over LTE ) — это передача голоса в качестве услуги IMS по сети передачи данных LTE , а управление вызовом осуществляется с помощью SIP работающего внутри IMS — того же протокола, который вы только что изучили, в рамках интерфейсов Cx / HSS и политик мобильного ядра. Таким образом, SIP используемый группой обмена сообщениями для программируемой голосовой связи, и SIP , управляющий вызовом VoLTE — это один и тот же протокол, различающийся окружающей сетью, а не самой сигнализацией.