Что такое протокол SIP: простое объяснение для понимания IP-телефонии

SIP (Session Initiation Protocol) — это сигнальный протокол для установления, изменения и завершения мультимедиа-сессий в IP-сетях. Простыми словами: SIP отвечает за «звонок» — поиск абонента, согласование параметров связи и разрыв соединения, но не за передачу самого голоса или видео. За медиапотоки отвечает отдельный протокол — обычно RTP.

Главный ориентир: если вы настраиваете IP-телефонию, софтфон, АТС (Asterisk, FreeSWITCH, 3CX) или соединяете шлюзы — вы столкнётесь именно с SIP. Понимание его логики позволяет быстро диагностировать, почему звонок не проходит, нет звука в одну сторону или регистрация уходит в таймаут.

Суть протокола: что делает SIP и чего не делает

SIP работает на прикладном уровне модели OSI (уровень 7). Он текстовый, похож на HTTP по структуре: запросы и ответы, заголовки, коды состояния. Это делает его читаемым в дампе трафика (Wireshark, tcpdump) без спец-декодеров.

• Что делает SIP: находит абонента (через регистрацию и прокси), согласовывает кодеки и параметры медиа (через SDP в теле сообщений), устанавливает сессию, управляет удержанием, переводом, конференциями, завершает вызов.
• Чего не делает: не кодирует звук/видео, не доставляет медиапакеты, не гарантирует QoS, не шифрует медиа (это задача SRTP), не маршрутизирует пакеты в сети (это IP/TCP/UDP).

Разделение сигналинга и медиа — ключевая архитектурная особенность. SIP-серверы (прокси, регистраторы) видят только сигнальный трафик. Медиа часто идёт напрямую между конечными точками (peer-to-peer) или через медиа-реле (RTPEngine, медиа-прокси), если NAT/фаерволы мешают прямому пути.

Основные роли и элементы архитектуры

В терминологии RFC 3261 участники делятся на клиентские и серверные роли. Одно устройство может выполнять несколько ролей одновременно.

Клиентские роли (User Agent)

• UAC (User Agent Client) — инициатор запроса: тот, кто звонит, регистрируется, отправляет OPTIONS.
• UAS (User Agent Server) — получатель запроса: отвечает на вызов, подтверждает регистрацию.

Физический SIP-телефон или софтфон — это User Agent (UA), который по очереди выступает как UAC и UAS.

Серверные роли

• Registrar — принимает REGISTER-запросы, связывает адрес записи (AOR, например sip:ivan@example.com) с текущим IP/портом контакта. Хранит привязку в базе (location service).
• Proxy Server (прокси) — маршрутизирует запросы дальше: stateful (хранит состояние транзакции) или stateless (просто пересылает). Может быть forked — рассылать INVITE нескольким контактам одновременно (параллельный вызов на телефон и софтфон).
• Redirect Server — не проксирует запрос, а отвечает 3xx с новым адресом, куда клиент должен обратиться сам.
• Back-to-Back User Agent (B2BUA) — разрывает сигнальный путь на две ноги: входящая и исходящая. Полный контроль над вызовом, запись, биллинг, манипуляция SDP. Asterisk, FreeSWITCH, 3CX работают как B2BUA.
• STUN/TURN/ICE серверы — не SIP-серверы, но критичны для прохождения NAT: помогают UA узнать внешний IP/порт и пробить пробросы для RTP.

Ключевые методы (запросы) и коды ответов

SIP-методы пишутся заглавными буквами. На практике вы встретите в 90% случаев эти шесть:

Метод	Назначение	Типичный сценарий
REGISTER	Регистрация UA у регистратора	Телефон «заходит» в сеть, сообщает свой IP/порт
INVITE	Инициирование сессии (вызов)	Нажатие кнопки вызова, в теле — SDP с кодеками
ACK	Подтверждение получения финального ответа на INVITE	Трехрукопожатие: INVITE → 200 OK → ACK
BYE	Завершение сессии	Повесили трубку
CANCEL	Отмена неотвеченного INVITE	Перезвонили до ответа
OPTIONS	Проверка доступности/возможностей	Keep-alive, мониторинг транка

Дополнительные методы: REINVITE/UPDATE (смена параметров медиа — удержание, добавление видео), REFER (перевод вызова), NOTIFY/SUBSCRIBE (события — BLF, MWI), INFO (DTMF в сигнальном канале), PRACK (надежные предварительные ответы 1xx).

Классы кодов ответа (как в HTTP)

• 1xx Provisional — процесс идет: 100 Trying (прокси получил), 180 Ringing (звонит), 183 Session Progress (ранняя медиа, например IVR).
• 2xx Success — успех: 200 OK (вызов принят, регистрация прошла).
• 3xx Redirection — попробуй другой адрес: 302 Moved Temporarily.
• 4xx Client Error — ошибка запроса: 401/407 Unauthorized/Proxy Auth Required (нужен пароль), 404 Not Found, 486 Busy Here, 487 Request Terminated (после CANCEL).
• 5xx Server Error — ошибка сервера: 503 Service Unavailable.
• 6xx Global Failure — глобальный отказ: 603 Decline.

Как выглядит вызов: пошаговый разбор

Классический сценарий: Алиса звонит Бобу. Оба зарегистрированы на одном домене.

1. Регистрация (заранее): Алиса → REGISTER → Registrar → 200 OK (контакт сохранён). Тоже Боб.
2. INVITE: Алиса (UAC) → INVITE (с SDP: мои кодеки, IP/порт для RTP) → Proxy → Боб (UAS).
3. 100 Trying: Прокси подтверждает получение INVITE.
4. 180 Ringing: Боб звонит, отправляет 180.
5. 200 OK: Боб снимает трубку, шлёт 200 OK со своим SDP (кодеки, его IP/порт для RTP).
6. ACK: Алиса подтверждает 200 OK. Сессия установлена.
7. RTP: Медиа идут напрямую Алиса ↔ Боб (или через медиа-реле) по портам из SDP.
8. BYE: Кто-то кладёт трубку → BYE → 200 OK. Сессия закрыта.

Важно: ACK на 200 OK отправляется инициатором INVITE напрямую (end-to-end), минуя прокси, если Record-Route не заставляет иначе. Это частое место потери ACK при неверном NAT/фаерволе.

SDP — описание медиа внутри SIP

Session Description Protocol (RFC 4566) не является частью SIP, но неразрывно с ним связан. SDP передаётся в теле INVITE, 200 OK, REINVITE. Содержит:

• c= — IP-адрес для приёма медиа (connection address).
• m= — медиа-линия: тип (audio/video), порт, профиль (RTP/AVP), список форматов (payload types).
• a=rtpmap — маппинг payload type → название кодека/частота/каналы (например, a=rtpmap:0 PCMU/8000/1 — G.711 μ-law).
• a=sendrecv/sendonly/recvonly/inactive — направление медиа (удержание = sendonly/inactive).
• a=crypto — параметры SRTP (если используется SDES).
• a=ice-ufrag/pwd, a=candidate — параметры ICE для прохождения NAT.

Согласование кодеков: пересечение списков в предложении и ответе. Если пересечения нет — 488 Not Acceptable Here. Порядок кодеков в SDP — приоритет.

Транспорт: UDP, TCP, TLS, WebSocket

SIP не привязан к одному транспорту. Порт по умолчанию: 5060 (UDP/TCP), 5061 (TLS).

• UDP — исторически основной, низкая задержка, но нет гарантии доставки, фрагментация больших пакетов (MTU), проблемы с NAT. Требует механизмов ретранасляций (таймеры T1/T2).
• TCP — надежная доставка, нет фрагментации, удобен для больших сообщений (много ICE-кандидатов, длинные сертификаты), лучше проходит NAT. Нагрузка на сервер выше (состояния соединений).
• TLS (SIPS) — шифрование сигналинга. Обязателен для безопасности, часто требуется провайдерами/корпоративными политиками. Порт 5061. Требует валидных сертификатов (Let’s Encrypt работает, но CN/SAN должен совпадать с доменом SIP).
• WebSocket (WSS) — для WebRTC-клиентов в браузере. SIP over WebSocket (RFC 7118). Порт обычно 8089/443.

Практический совет: для стационарных телефонов и шлюзов в управляемой сети — UDP/TCP нормально. Для софтфонов на мобильных, в публичных Wi-Fi, за CGNAT — лучше TLS или WSS. Многие современные АТС (FreeSWITCH, Kamailio, Asterisk с PJSIP) слушают сразу несколько транспортов.

NAT и SIP: главная боль практической настройки

SIP в теле SDP прописывает IP/порт для медиа. Если UA за NAT, он пишет свой частный IP (192.168.x.x, 10.x.x.x). Удаленная сторона не может на него ответить — односторонний звук или полная тишина.

Инструменты решения

• STUN (Session Traversal Utilities for NAT) — UA узнаёт свой публичный IP/порт, подставляет в SDP (RFC 5389). Работает для cone NAT.
• TURN (Traversal Using Relays around NAT) — реле для медиа, если STUN не помог (symmetric NAT). Требует ресурсов сервера.
• ICE (Interactive Connectivity Establishment) — фреймворк, собирающий кандидаты (host, srflx, relay), проверяющий пары, выбирающий лучший путь (RFC 8445). Обязателен для WebRTC, используется в современных SIP-клиентах.
• SIP ALG (Application Layer Gateway) на роутере — часто ломает SIP, переписывая заголовки/порт некорректно. Рекомендация: отключить SIP ALG на всех маршрутизаторах на пути.
• Симметричный RTP / RTP лatching — медиа-сервер (B2BUA, RTPEngine) начинает слать RTP на адрес, откуда пришли пакеты от пира, игнорируя SDP. Работает без STUN на стороне клиента.
• Публичный IP на UA / DMZ / проброс портов — радикально, но не всегда возможно.

Порядок проверки при «нет звука в одну сторону»:
1. Посмотреть SDP в INVITE/200 OK — какой IP/порт объявлен.
2. Проверить, доходят ли RTP-пакеты (tcpdump/Wireshark на сервере/клиенте).
3. Убедиться, что фаервол пропускает UDP-диапазон RTP (обычно 10000–20000 или 40000–60000).
4. Проверить настройки NAT в клиенте (STUN сервер, ICE, keep-alive).
5. На сервере — включен ли RTP proxy / media relay, корректен ли external_media_address.

SIP vs H.323 vs WebRTC vs XMPP/Jingle

Протокол	Сфера	Особенности	Где встречается
SIP	VoIP, UC, IMS, операторская телефония	Текстовый, модульный, стандарт де-факто для IP-телефонии	АТС, SIP-транки, IP-телефоны, софтфоны, IMS ядро
H.323	Видеоконференции, старые системы	Бинарный (ASN.1), тяжелый, сложный NAT, устаревает	Старые Polycom/Cisco MCU, легаси видеоконференции
WebRTC	Браузерная реальная связь	Обязательный ICE/DTLS-SRTP, сигналинг не стандартизирован (часто SIP over WS или кастомный JSON)	Веб-виджеты звонков, Jitsi, Meet, кастомные веб-аппы
XMPP + Jingle	IM, чаты, P2P звонки	XML, децентрализован, менее распространен в телефонии	Jabber-клиенты, некоторые мессенджеры

WebRTC не заменяет SIP — они часто работают вместе: WebRTC-клиент в браузере сигналит через SIP over WebSocket к АТС, которая мостит вызов на обычный SIP-транк или PSTN.

Безопасность: что проверить минимум

SIP по умолчанию открыт: пароли в открытом виде (Digest auth), сигналинг в открытом виде, медиа в открытом виде. Векторы атак: перехват вызовов, подделка Caller ID, тарифный мошенничество (toll fraud), DoS регистрациями/INVITE-флудом, перехват медиа.

• TLS для сигналинга (SIPS) — обязательно для внешних транков и удаленных сотрудников. Проверяйте сертификаты (CN/SAN = домен SIP).
• SRTP (DTLS-SRTP или SDES) — шифрование медиа. DTLS-SRTP предпочтительнее (ключи согласовываются в медиапотоке, не видно в SIP).
• Дайджест-аутентификация с nonce — не отключайте, не используйте статичные пароли без challenge.
• Ограничение доступа по IP — для транков провайдеров: allowlist их IP/подсетей на фаерволе и в АТС.
• Rate limiting / fail2ban — блокировка IP после N неудачных REGISTER/INVITE за интервал.
• Caller ID validation / STIR/SHAKEN — для исходящих на PSTN: проверка права на номер, подпись PASSporT. В РФ — требования регулятора к идентификации абонента.
• Отключение ненужных методов — если не используете SUBSCRIBE/NOTIFY/REFER — блокируйте на границе.
• Мониторинг CDR и алерты на аномалии — резкий рост исходящих на премиум/международку, короткие нулевые вызовы (scanning).

Типичные ошибки настройки и как их избежать

Симптом	Частая причина	Что проверить/исправить
Регистрация не проходит (401/403/timeout)	Неверный realm, пользователь, пароль; неверный транспорт (UDP vs TCP/TLS); блокировка порта 5060	Сравнить заголовки WWW-Authenticate и Authorization; включить TLS если провайдер требует; проверить фаервол
Звонок проходит, но тишина / односторонний звук	NAT: частный IP в SDP; закрытые RTP-порты; SIP ALG ломает SDP	Включить STUN/ICE/симметричный RTP; открыть RTP-диапазон; выключить SIP ALG на роутере
Вызов сбрасывается через 30–32 секунды	Потеря ACK или 200 OK (не проходит через NAT/файрвол); не настроен Session Timers (RFC 4028)	Проверить Record-Route / Path; включить Session-Expires / Min-SE; проверить keep-alive (OPTIONS/пробелы)
488 Not Acceptable Here	Нет общих кодеков; несовпадение ptime; неверный профиль RTP/AVP vs RTP/SAVP	Согласовать список кодеков на обеих сторонах; привести ptime (обычно 20ms); использовать RTP/SAVP для SRTP
Входящие не проходят, исходящие работают	Registrar не обновляет контакт (expire истёк); NAT-таймаут UDP-маппинга; нет keep-alive	Уменьшить register expire (120–300с); включить SIP keep-alive (OPTIONS/CR-LF/UDP пробелы); проверить NAT timeout
TLS handshake fails	Самоподписанный сертификат; CN/SAN не совпадает с доменом; устаревший TLS 1.0/1.1	Валидный сертификат (Let’s Encrypt / платный); TLS 1.2+; проверка цепочки на клиенте

Практический чек-лист перед запуском SIP-транка или АТС

1. DNS: A/AAAA записи для домена SIP, SRV записи (_sip._udp, _sip._tcp, _sips._tcp) — для балансировки и фейловера.
2. Транспорт: Определить UDP/TCP/TLS/WSS. Открыть порты на фаерволе (5060/5061 + RTP range).
3. Кодеки: Согласовать список с провайдером/контрагентом (приоритет: G.722, Opus, G.711a/μ, G.729). Прописать ptime=20.
4. NAT-стратегия: STUN серверы, ICE, симметричный RTP, медиа-реле. Отключить SIP ALG.
5. Аутентификация: Digest с challenge. Сложные пароли. Для транков — IP-allowlist + digest.
6. Шифрование: TLS 1.2+ для сигналинга, DTLS-SRTP для медиа. Сертификаты валидные.
7. Нумерация/Caller ID: Формат E.164 (+7XXXXXXXXXX). Правила нормализации входящих/исходящих. STIR/SHAKEN если требуется.
8. Резервирование: Два и более прокси/регистратора (SRV priority/weight). Гео-распределение.
9. Мониторинг: OPTIONS keep-alive к пирам, алерты на 5xx/408/timeout, CDR-аналитика, логи SIP (ngrep/homer/sngrep).
10. Тестовые вызовы: Внутренний, входящий, исходящий, удержание, перевод, конференция, DTMF (RFC 2833 / SIP INFO), факс (T.38 / passthrough).

Инструменты диагностики, которые стоит иметь под рукой

• sngrep — консольный pcap-просмотрщик SIP с цветовой подсветкой, фильтрами, статистикой. Лучше ngrep для быстрого разбора.
• Wireshark / tshark — полный разбор, экспорт RTP, анализ потоков, графики джиттера/потерь.
• sipgrep / sipcapture (Homer) — централизованный сбор и поиск SIP-логов в продакшене.
• sipsak / sipp — генерация нагрузки, тестирование сценариев, проверка доступности.
• rtpengine / rtpproxy / kamailio + rtpengine — медиа-реле для решения NAT-проблем на сервере.
• openssl s_client -connect host:5061 — проверка TLS-рукопожатия, сертификатов, SNI.

Сценарии выбора: что подходит вашей задаче

• Малый офис (до 50 абонентов), простая АТС: FreePBX / VitalPBX / 3CX (бесплатная лицензия до 10 вызовов) на VPS. Транк у провайдера по TLS+SRTP. Телефоны — автопровижининг (HTTP/TFTP/HTTPS).
• Колл-центр / высокая нагрузка: Kamailio/OpenSIPS как фронтенд (регистрация, маршрутизация, балансировка) + Asterisk/FreeSWITCH как медиа-бэкенд (IVR, запись, очереди). RTPEngine для медиа. Кластеризация, гео-резерв.
• Интеграция в веб-приложение (клик-ту-колл, поддержка в браузере): WebRTC-клиент (SIP.js, JsSIP) + SIP over WSS на Kamailio/Asterisk. ICE/DTLS-SRTP обязательны.
• Связка филиалов (site-to-site): SIP-транк между АТС филиалов через VPN (WireGuard/IPsec) или публичный TLS-транк. Единый план нумерации, DID на каждый филиал.
• Миграция с аналоговой/ISDN АТС: FXO/FXS шлюзы (Grandstream, Yeastar, Patton) + SIP-транк. Постепенная миграция: шлюз как абонент старой АТС, параллельный запуск.

Что делать дальше: конкретные шаги

1. Определите задачу: софтфон для себя, АТС для офиса, транк для колл-центра, веб-виджет.
2. Выберите транспорт: TLS+SRTP по умолчанию для всего, что выходит в интернет.
3. Подготовьте инфраструктуру: VPS/сервер с публичным IP, DNS (A + SRV), валидный сертификат (Let’s Encrypt через certbot с DNS-01 challenge для wildcard).
4. Разверните АТС/прокси: для старта — FreePBX/VitalPBX (GUI), для роста — Kamailio + Asterisk/FreeSWITCH (конфиги).
5. Настройте один SIP-транк у провайдера: исходящие/входящие, кодеки, Caller ID, регистрация.
6. Подключите тестовый телефон/софтфон (Linphone, Zoiper, MicroSIP, PhonerLite). Проверьте регистрацию, исходящий, входящий, звук, удержание, перевод.
7. Включите логирование SIP (ngrep/sngrep) и CDR. Настройте fail2ban на порт 5060/5061.
8. Проведите нагрузочный тест (sipp) если планируете >50 одновременных вызовов.
9. Документируйте план нумерации, IP-схему, пароли (в менеджере паролей), процедуру восстановления.

Материал носит информационный характер. Настройка IP-телефонии затрагивает безопасность коммуникаций, тарификацию и соответствие требованиям регулятора (в РФ — закон о связи, требования к идентификации абонентов, защите персональных данных). При внедрении в продакшене рекомендуется привлечь специалиста по VoIP/сетевой безопасности и проверить актуальные нормативные акты на дату реализации.

SIP — стандарт де-факто для голосовой связи в IP-сетях. Его сила в простоте текстового формата, модульности и широкой экосистеме. Главные подводные камни — NAT, безопасность и согласование кодеков. Понимание сигнального пути (REGISTER → INVITE → 200 OK → ACK → RTP → BYE) и места, где живут медиа (SDP, RTP, ICE), позволяет решать 90% операционных задач без «магии».