Перейти к основному содержимому

Установление SIP-видеозвонка: пошаговый разбор сигнального процесса

04-03-02

В этом разделе подробно рассматривается типовой процесс установления видеозвонка по протоколу SIP (Session Initiation Protocol) между двумя участниками через прокси-сервер. Основное внимание уделяется последовательности сигнальных сообщений, роли SDP (Session Description Protocol) в согласовании параметров медиа, а также особенностям маршрутизации и обработки NAT. Этот процесс лежит в основе большинства корпоративных систем видеоконференцсвязи (ВКС), IP-телефонии и интеграционных решений.

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

1. Общая архитектура участников SIP-вызова​

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

  • Инициатор вызова (Caller) — устройство или программный клиент (например, IP-телефон, видеотерминал, softphone), который хочет установить соединение.
  • Вызываемый абонент (Callee) — получатель вызова, второй участник, которому поступает приглашение.
  • Прокси-сервер (Proxy Server) — промежуточное звено, отвечающее за маршрутизацию SIP-сообщений. Он не участвует в передаче медиа, но управляет сигнальным обменом.

💡 Аналогия: представьте, что SIP — это телефонный звонок через оператора. Вы набираете номер (отправляете INVITE), оператор (прокси) соединяет вас с нужным абонентом, передаёт сигнал «идёт вызов», а когда абонент берёт трубку — подтверждает соединение. После этого вы разговариваете напрямую, а оператор больше не вмешивается.

2. Шаг 1: Инициация вызова — сообщение INVITE​

Процесс начинается с того, что инициатор отправляет сообщение INVITE на прокси-сервер. Это основное сообщение, которое инициирует установление сессии.

Что содержит INVITE?​

  • Адрес назначения — SIP-URI вызываемого, например sip:alice@company.com.
  • Тело сообщения в формате SDP — описание возможностей инициатора.

SDP в теле INVITE: что это и зачем?​

SDP (Session Description Protocol) — это текстовый формат, описывающий параметры мультимедийной сессии. Он не передаёт медиаданные, но сообщает, как их можно передавать.

Пример содержания SDP в INVITE:

v=0
o=caller 12345 1 IN IP4 192.168.1.100
s=-
c=IN IP4 203.0.113.5
t=0 0
m=audio 5004 RTP/AVP 0 8 111
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:111 opus/48000/2
m=video 5006 RTP/AVP 96 97
a=rtpmap:96 H264/90000
a=fmtp:96 profile-level-id=42e01f;packetization-mode=1
a=rtpmap:97 VP8/90000

Пояснение ключевых полей SDP:​

ПолеЗначениеПояснение
c=IN IP4 203.0.113.5Публичный IP-адрес, на который нужно отправлять медиапоток. Важно при NAT.
m=audio5004 RTP/AVP 0 8 111Аудиопоток: порт 5004, протокол RTP, поддерживаемые кодеки (по их Payload Type — PT).
a=rtpmap111 opus/48000/2Сопоставление PT с названием кодека: PT 111 — это Opus, частота 48 кГц, стерео.
m=video5006 RTP/AVP 96 97Видеопоток: порт 5006, кодеки с PT 96 (H.264) и 97 (VP8).
a=fmtpprofile-level-id=42e01fДополнительные параметры H.264: профиль, уровень, режим пакетизации.

⚠️ Важно: SDP в INVITE указывает, какие кодеки поддерживает инициатор и на какой IP-адрес и порт он ожидает получить медиа. Это не гарантирует, что они будут использованы — окончательный выбор делается позже.

3. Шаг 2: Подтверждение получения — 100 Trying​

После получения INVITE прокси-сервер отправляет ответ:

SIP/2.0 100 Trying

Что означает 100 Trying?​

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

💡 Аналогия: вы отправили письмо, и получатель ответил: «Получил, читаю». Это не значит, что он уже принял решение, но вы знаете, что письмо дошло.

4. Шаг 3: Пересылка INVITE вызываемому​

Прокси-сервер анализирует адрес в INVITE, находит маршрут к вызываемому абоненту и пересылает INVITE напрямую к нему.

При этом:

  • Прокси добавляет в заголовок Via информацию о себе, чтобы ответы могли вернуться обратно.
  • В заголовке Contact указывается, как связаться с инициатором напрямую (учитывая NAT).

🛠 Техническая деталь: поля Via и Contact критически важны при работе через NAT. Они позволяют прокси отслеживать маршрут и обеспечивать двустороннюю доставку сообщений, даже если один из участников находится за маршрутизатором с приватным IP.

5. Шаг 4: Уведомление о вызове — 180 Ringing​

Когда вызываемый абонент получает INVITE, он:

  • Начинает проигрывать гудки (ringing tone) пользователю.

  • Отправляет ответ:

    SIP/2.0 180 Ringing

Этот ответ проходит обратно через прокси к инициатору.

Что даёт 180 Ringing?​

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

🎧 Визуализация: вы звоните коллеге. Он слышит звонок, вы — гудки. Пока никто не ответил, но связь уже частично установлена.

6. Шаг 5: Принятие вызова — 200 OK​

Когда вызываемый принимает вызов (нажимает «ответить»), он формирует ответ:

SIP/2.0 200 OK

Что содержит 200 OK?​

  • Тело в формате SDP, аналогичное тому, что было в INVITE, но от имени вызываемого.
  • В SDP указаны:
    • Выбранные аудио- и видеокодеки (уже согласованные).
    • IP-адрес и порт, на которые вызываемый будет принимать медиапоток.
    • Направления потоков (sendrecv, sendonly и т.д.).

Пример:

m=audio 4002 RTP/AVP 111
a=rtpmap:111 opus/48000/2
m=video 4004 RTP/AVP 96
a=rtpmap:96 H264/90000
a=fmtp:96 profile-level-id=42e01f;packetization-mode=1

🔍 Обратите внимание: в 200 OK вызываемый подтверждает, какие кодеки он готов использовать. Например, если инициатор предлагал Opus и PCMU, а вызываемый поддерживает только Opus, он укажет только его.

7. Шаг 6: Подтверждение получения — ACK​

После получения 200 OK инициатор отправляет:

ACK

Назначение ACK:​

  • Это финальное подтверждение получения 200 OK.
  • Оно завершает сигнальную фазу установления сессии.
  • После ACK сигнальный канал считается установленным.

⚠️ Важно: ACK не содержит SDP. Все параметры уже согласованы в INVITE и 200 OK.

8. Шаг 7: Передача медиаданных — начало RTP/RTCP​

С этого момента начинается передача аудио- и видеоинформации.

Как передаётся медиа?​

  • По протоколу RTP (Real-time Transport Protocol) — для передачи полезной нагрузки (аудио, видео).
  • По протоколу RTCP (RTP Control Protocol) — для передачи служебной информации: статистика потерь, задержка, джиттер, качество связи.

Ключевые особенности:​

  • Медиапотоки идут напрямую между участниками, минуя прокси-сервер.
  • Это называется peer-to-peer (P2P) медиа-соединение.
  • Прокси больше не участвует — он нужен только для сигнализации.

🧭 Почему так сделано?
Прямая передача снижает задержку, нагрузку на сервер и стоимость инфраструктуры. Прокси — как навигатор, который помог найти путь, а дальше вы идёте сами.

9. Согласование параметров медиа: как выбираются кодеки и адреса​

На этапе обмена INVITE и 200 OK происходит согласование (negotiation) параметров сессии.

Этапы согласования:​

  1. Обмен возможностями:
    • Инициатор в INVITE говорит: «Я могу Opus, PCMU, H.264, VP8».
    • Вызываемый в 200 OK отвечает: «Я беру Opus и H.264».
  2. Выбор общих кодеков:
    • Система ищет пересечение поддерживаемых кодеков.
    • Если общих нет — вызов не может быть установлен (ошибка 488 Not Acceptable Here).
  3. Уточнение IP и портов:
    • В c= строке SDP указывается публичный адрес, доступный для медиасоединения.
    • Это особенно важно при NAT: если устройство за NAT, оно может указать свой внешний адрес, полученный через STUN.
  4. Направление потока:
    • Через атрибут a=sendrecv (двусторонний), sendonly (только отправка), recvonly (только приём).

🛠 Пример проблемы:
Инициатор указал в c= приватный адрес 192.168.1.100. Вызываемый пытается отправить медиа туда — не получается.
Решение: использовать STUN/TURN/ICE для определения публичного адреса.

10. Особенности обработки NAT и роль SIP-заголовков​

Одна из главных сложностей в SIP — работа через NAT (Network Address Translation), когда устройства находятся за маршрутизаторами с приватными IP.

Как SIP с этим справляется?​

МеханизмРоль
Поле ViaУказывает путь, по которому ответы должны вернуться. Прокси добавляет себя в цепочку.
Поле ContactСодержит адрес для прямого обращения к устройству. Может содержать публичный IP:порт.
Строка c= в SDPУказывает, на какой адрес направлять медиапоток. Должен быть публичным.

⚠️ Типичная ошибка: устройство за NAT указывает в c= свой приватный адрес. Решение — использовать STUN-сервер для определения внешнего адреса или TURN для ретрансляции.

11. Диагностика проблем: как читать логи SIP-устройств​

Для инженера умение читать логи — ключевой навык. Вот что искать:

1. Проверьте наличие SDP в INVITE и 200 OK​

  • Если SDP отсутствует — вызов не установится.
  • Если SDP есть, но нет видео — проверьте:
    • Присутствует ли m=video в обоих сообщениях.
    • Совпадают ли кодеки (например, оба поддерживают H.264).
    • Совпадают ли profile-level-id и packetization-mode — даже один из этих параметров может нарушить совместимость.

2. Проверьте IP-адреса в c=​

  • Убедитесь, что указан публичный, а не приватный адрес.
  • Если стоит 192.168.x.x, 10.x.x.x или 172.16.x.x — вероятна проблема с NAT.

3. Проверьте коды ответов​

КодЗначениеВозможная проблема
100 TryingЗапрос принятНорма
180 RingingВызываемый получает вызовНорма
200 OKВызов принятУспех
404 Not FoundАбонент не найденОшибка в SIP-URI
488 Not Acceptable HereНет общих кодековНесовместимость устройств
487 Request TerminatedВызов сброшенПользователь отменил

🔧 Совет: используйте Wireshark для анализа SIP-трафика. Фильтр sip покажет все сообщения, а rtp — медиапотоки. Проверьте, идёт ли RTP после ACK.

Заключение​

Установление SIP-видеозвонка — это чётко структурированный процесс, включающий:

  • Сигнальные сообщения (INVITE, 180 Ringing, 200 OK, ACK).
  • Описание медиапараметров через SDP.
  • Согласование кодеков и адресов.
  • Прямую передачу медиа по RTP/RTCP.

Понимание этой последовательности позволяет:

  • Проектировать системы видеосвязи.
  • Интегрировать SIP с другими протоколами (RTSP, WebRTC, ONVIF).
  • Диагностировать и устранять проблемы с подключением, звуком, видео.

🎯 Инженер должен видеть за абстракциями: каждый INVITE — это не просто сообщение, а объявление возможностей. Каждый 200 OK — согласие на конкретные условия. А отсутствие медиа после успешной сигнализации — почти всегда проблема в SDP или NAT.