Как устроен SIP‑звонок от начала до конца

SIP (Session Initiation Protocol) отвечает только за установление, изменение и завершение мультимедийных сессий. Сама голосовая или видеоданные передаются отдельным протоколом – обычно RTP. Чтобы понять, как происходит звонок, достаточно рассмотреть последовательность SIP‑сообщений и связанный с ними обмен данными о медиа.

Основные участники SIP‑сессии

В типичной схеме задействованы следующие элементы:

• User Agent (UA) – конечное устройство (софтфон, IP‑телефон, шлюз), которое инициирует или принимает вызов.
• Proxy server – промежуточный сервер, который пересылает запросы и ответы, может выполнять аутентификацию, маршрутизацию и логирование.
• Registrar – сервер регистрации, где UA привязывает свой адрес (AOR) к текущему IP‑адресу и порту.
• Redirect server – возвращает клиенту альтернативные адреса, куда следует отправить запрос.

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

Этапы установления вызова

Рассмотрим типичный сценарий outgoing‑вызова от UA‑A к UA‑B через прокси.

1. INVITE – UA‑A отправляет запрос INVITE с идентификатором вызывающего (From), вызываемого (To) и данными о поддерживаемых медиа (SDP‑тело). Запрос обычно направляется на порт 5060 (UDP или TCP) прокси или напрямую к UA‑B, если тот известен.
2. 100 Trying – прокси (или UA‑B) сразу отвечает provisoire‑ответом 100 Trying, подтверждая получение запроса и начало обработки.
3. 180 Ringing – когда UA‑B начинает вызов (например, начинает звонить), он шлет provisional‑ответ 180 Ringing. На этом этапе вызывающий может прослушать гудок.
4. 200 OK – после того как вызываемый снимает трубку, UA‑B отправляет финальный ответ 200 OK, содержащий своё SDP‑описание выбранных кодеков и медиа‑портов.
5. ACK – UA‑A подтверждает получение 200 OK запросом ACK. После этого считается, что сессия установлена и можно начинать обмен медиа.

Каждое из этих сообщений передаётся по SIP‑трафику. Если на каком‑то этапе получается ошибка (например, 404 Not Found, 486 Busy Here, 500 Server Internal Error), вызов прерывается и вызывающий получает соответствующий код.

Обмен описанием сеанса (SDP)

SDP (Session Description Protocol) помещается в тело INVITE и 200 OK. Он содержит:

• Версию протокола (v=0).
• Идентификатор сеанса и временные параметры (o=, s=, t=).
• Информацию о медиа‑полосах: тип (audio/video), транспортный протокол (обычно RTP/AVP), формат кодека и номера портов, куда будет отправляться медиа‑трафик.
• Дополнительные атрибуты, такие как направление (sendrecv, sendonly, recvonly, inactive) и параметры кодека (например, payload type, частота дискретизации).

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

Передача медиа: RTP и RTCP

После подтверждения ACK начинается реальный обмен голосовыми или видеоданными:

• RTP (Real‑time Transport Protocol) доставляет пакеты с медиа. Каждый пакет содержит последовательный номер, временную метку и идентификатор синхронизации (SSRC), что позволяет получателю восстановить порядок и компенсировать джиттер.
• RTCP (RTP Control Protocol) периодически посылает пакеты с информацией о качестве приёма/передачи (потери, задержка, jitter). Эти данные используются для адаптивного изменения битрейта или кодека.

Порты для RTP обычно выбираются из диапазона, указанного в конфиденции PBX или софтфона (например, 10000‑20000 UDP). Они отличаются от сигнального порта 5060.

Удержание, перевод и другие модификации сессии

Во время активного звонка можно менять его параметры без полного разрыва:

• Hold/Unhold – сторона отправляет ре‑INVITE с SDP, где направление медиа установлено в inactive или sendonly, что ставит вызов на удержание.
• Blind Transfer – вызывающий отправляет REFER на целевой номер; прокси или UA‑B инициирует новый INVITE к третьей стороне, после чего оригинальный вызов завершается BYE.
• Call Forward – при получении INVITE сервер может вернуть 3xx Redirect с новым адресом, либо сам инициировать новый вызов параллельно (forking).

Завершение вызова

Для корректного окончания сессии используется запрос BYE:

1. Кто‑то из участников (обычно тот, кто завершил разговор) посылает BYE в диалог.
2. Получатель отвечает 200 OK, подтверждая получение BYE.
3. После этого SIP‑диалог считается завершённым, а RTP‑потоки останавливаются.

Если одна из сторон просто разрывает соединение без BYE (например, из‑за сбоя сети), другая сторона обнаружит отсутствие RTCP‑пакетов и через таймаут сочтёт вызов потерянным.

Типичные ситуации, при которых вызывается отклонение

Сервер может вернуть следующие классы ответов:

• 4xx – клиентские ошибки: 401 Unauthorized (требуется аутентификация), 403 Forbidden (вызов запрещён), 404 Not Found (номер не существует), 486 Busy Here (абонент занят).
• 5xx – серверные ошибки: 500 Server Internal Error (внутренняя проблема сервера), 503 Service Undavailable (сервис временно недоступен), 504 Server Time‑out (нет ответа от следующего хопа).
• 6xx – глобальные ошибки: 600 Busy Everywhere (абонент недоступен везде), 603 Decline (вызов отклонён абонентом), 604 Does Not Exist Anywhere (номер не существует в сети).

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

Практический совет: что проверять при настройке SIP

Если вы настраиваете новое оборудование или troubleshoot существующее соединение, обратите внимание на следующие пункты:

• Сигнальный порт и транспорт (UDP/TCP/TLS). Убедитесь, что оба конца используют одинаковый протокол и что порт открыт в firewall.
• Аутентификация: проверьте логин/пароль и realm, особенно если используется SIP‑Digest.
• Совместимость кодеков: сравните списки кодеков в SDP‑телах обеих сторон; отсутствие общего кодека приведёт к отсутствию медиа даже при успешном сигнале.
• NAT и проброс портов: если одна из сторон находится за NAT, проверьте, включена ли поддержка STUN, ICE или простое пробросание RTP‑портов.
• Логирование: включите вывод SIP‑сообщений на уровне debug; это позволит увидеть, на каком именно этапе происходит сбой (INVITE не доходит, нет 200 OK, отсутствует ACK и т.д.).

Частые ошибки и как их избежать

Ниже перечислены типичные проблемы, с которыми сталкиваются администраторы, и способы их исправления:

• Односторонняя тишина – медиа идёт только в одну direction. Проверьте symmetric RTP и настройки NAT: часто одна сторона отправляет пакеты на правильный порт, но получает их на другой из‑за неправильного проброса.
• Эхо или задержка – может быть вызвано неправильной настройкой жёсткого буферизации в конечном устройстве или отсутствием эхоподавления. Убедитесь, что включено аппаратное или программное эхоподавление и что размер jitter‑buffer соответствует задержке сети.
• Потеря пакетов – указывает на перегрузку канала или плохое качество Wi‑Fi. Измерьте потери через RTCP‑статистику и при необходимости переключитесь на более надёжный канал или приоритизируйте SIP/RTP трафик.
• Сбой регистрации – устройство не может зарегистрироваться у registrar. Проверьте правильность учётных данных, доступность порта 5060 и отсутствие блокировки со стороны провайдера.
• Завершение вызова без BYE – иногда устройство просто закрывает сокет. Это приводит к «висящим» диалогам на стороне сервера. Настройте таймауты сессии (session-expires) и включите keep‑alive (OPTIONS или NOTIFY) для обнаружения разрыва.

FAQ

• Нужен ли прокси для звонка внутри одной локальной сети?
• Нет. Если оба UA знают IP‑адреса друг друга, они могут обмениваться INVITE/ACK напрямую, минуя прокси и registrar.
• Можно ли использовать TCP вместо UDP для SIP?
• Да. SIP поддерживает UDP, TCP и TLS. TCP выбирают, когда требуется гарантированная доставка сигнальных пакетов (например, через надёжный канал или при ограничениях firewall).
• Что делать, если слышен только гудок, но нет голоса?
• Скорее всего, не проходит RTP‑трафик. Проверьте, открыты ли UDP‑порты, указанные в SDP, на обеих сторонах, и отсутствует ли фильтрация по типу трафика в маршрутизаторе или firewall.
• Нужен ли отдельный сервер для медиа, или медиа идёт напрямую между UA?
• В базовой схеме медиа передаётся напрямую между UA (peer‑to‑peer). Некоторые системы используют медиа‑прокси (например, для записи или преодоления строгого NAT), но это уже расширение базового SIP.
• Как проверить, какой кодек действительно используется?
• В большинстве софтфонов и IP‑телефонов есть меню отчёта о звонке, где показываются выбранный payload type и средняя задержка/потери. Также можно посмотреть дамп RTP‑трафика в Wireshark и увидеть тип полезной нагрузки.

Понимание последовательности SIP‑сообщений и связанного с ними обмена SDP помогает не только настроить оборудование, но и быстро находить причины проблем со звонками. Главное – помнить, что SIP отвечает только за сигнализацию, а качество голоса зависит от корректной передачи RTP‑пакетов и согласования кодеков.