Что такое протокол SIP: история, место в архитектуре VoIP, RFC 3261 и сфера применения

В предыдущем курсе вы изучили, как живой человеческий голос превращается в цифровые отсчёты кодеков G.711, AMR или Opus и летит через IP-сеть в пакетах RTP каждые 20 миллисекунд. Но прежде чем первый голосовой пакет RTP покинет телефон, два устройства на разных концах планеты должны найти друг друга, узнать актуальные IP-адреса, проверить, свободен ли вызываемый абонент, договориться об общем аудиокодеке и в конце разговора аккуратно освободить ресурсы. Эту работу выполняет протокол установления сеансов — SIP (Session Initiation Protocol). В этом уроке мы разберём, что такое SIP, почему он победил громоздкие телеком-стандарты прошлого, как разделяются сигнализация и медиапоток и где SIP работает сегодня.

Цель и что нужно знать

После урока вы сможете:

• формулировать назначение протокола SIP и называть пять его базовых задач по стандарту RFC 3261;
• объяснять фундаментальное разделение плоскости сигнализации (SIP + SDP) и плоскости медиаданных (RTP / RTCP);
• прослеживать классическую «трапецию SIP» (почему сигнализация идёт через серверы домена, а голос RTP — напрямую между телефонами);
• сравнивать архитектуру SIP (IETF RFC 2543 / RFC 3261) со старым стеком ITU-T H.323 и перечислять сферы применения SIP.

Что нужно знать заранее: уроки От микрофона до IP-пакетов и обратно (цепочка передачи речи в VoIP), Заголовок RTP и поля пакета (передача медиапотока по UDP), а также уроки курса ipnet про модель TCP/IP, порты UDP/TCP, систему доменных имён DNS и безопасность TLS.

Задача из жизни

Компания перевела офис на IP-телефонию: на столах сотрудников стоят IP-телефоны в локальной сети 192.168.10.0/24, а сигнальный сервер корпоративной АТС размещён в защищённом облачном дата-центре по адресу 198.51.100.10. Администратор безопасности открыл на межсетевом экране доступ от всех телефонов только к IP-адресу облачного сервера 198.51.100.10 на стандартный порт UDP 5060. При тестовом звонке между двумя соседними столами оба телефона бодро звонят, на экранах высвечивается имя коллеги, секундомер разговора идёт — но в трубках стоит абсолютная тишина. Чтобы понять, почему вызов успешно устанавливается, а звука нет, инженеру нужно чётко знать границы ответственности протокола SIP: что именно делает сигнализация, а как и куда после этого идут голосовые пакеты RTP.

Что такое SIP и пять его главных задач

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

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

Согласно базовому стандарту IETF RFC 3261 (раздел 2), протокол SIP решает ровно пять задач установления и управления сеансом:

1. Определение местоположения пользователя (User Location): выяснение текущего IP-адреса и порта конечного устройства, за которым сейчас находится вызываемый абонент (ведь сотрудник мог включить ноутбук дома, в офисе или в командировке).
2. Определение доступности пользователя (User Availability): проверка готовности вызываемого абонента принять участие в разговоре (свободен ли он, занят другой линией или не берёт трубку).
3. Определение возможностей пользователя (User Capabilities): согласование типа медиа (только звук или звук с видео) и выбор общего кодека (G.711, G.722, AMR, Opus) и номеров портов UDP.
4. Установление сеанса (Session Setup): подача вызывного сигнала («звонка») на аппарат вызываемого абонента и закрепление параметров соединения на обеих сторонах.
5. Управление сеансом (Session Management): изменение параметров прямо по ходу разговора (постановка на удержание, включение видео, перевод звонка на другого сотрудника) и штатное завершение вызова (отбой).

Разделение сигнализации и медиа: почему SIP не является «всем VoIP»

Главный архитектурный принцип SIP, заложенный инженерами IETF, — модульность и строгое разделение плоскости управления (control plane) и плоскости пользователя (user / media plane). Протокол SIP никогда не переносит внутри себя оцифрованный голос или видеокадры. Вместо этого он работает в связке с другими специализированными протоколами:

• SIP (RFC 3261) — сигнальный конверт и правила ведения переговоров: кто звонит, кому звонит, через какие серверы идёт запрос и принят ли вызов. По умолчанию использует порт 5060 (для UDP и TCP) и порт 5061 (для защищённого соединения TLS).
• SDP (Session Description Protocol, RFC 8866) — текстовая «анкета медиапараметров», которая вкладывается внутрь сообщений SIP как тело письма. В анкете SDP устройство пишет свой IP-адрес для голоса, номер порта UDP и список поддерживаемых кодеков (подробно разбирается в разделе 7 курса).
• RTP / RTCP (RFC 3550) и SRTP (RFC 3711) — транспортные протоколы реального времени, которые после завершения переговоров SIP несут сами голосовые пакеты напрямую между устройствами по чётным динамическим портам UDP (обычно из диапазона 10000–20000 или 16384–32767).
• DNS (RFC 3263) — система доменных имён, помогающая телефону или серверу найти сигнальный сервер чужого домена и выбрать протокол транспорта.

Трапеция SIP (SIP Trapezoid)

Благодаря разделению сигнализации и медиа пути их пакетов в сети почти всегда различаются. Эта классическая схема маршрутизации называется трапецией SIP (SIP Trapezoid).

Когда абонент alice@atlanta.com звонит абоненту bob@biloxi.com, телефон Алисы не знает текущего IP-адреса телефона Боба. Поэтому сигнальные сообщения SIP поднимаются по боковой стороне трапеции к серверу домена atlanta.com, пересылаются на сервер biloxi.com и спускаются на телефон Боба (шаги 1 → 2 → 3). Но как только оба телефона обменялись анкетами SDP и узнали реальные IP-адреса друг друга, голосовой поток RTP (шаг 4, нижнее основание трапеции) летит напрямую между телефоном А и телефоном Б, минуя сигнальные серверы! Это разгружает серверы сигнализации от гигабитов аудиопотоков и минимизирует задержку голоса.

Разбор примера: расчёт нагрузки на сигнальный сервер и медиатракт

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

=== Сравнение трафика сигнализации SIP и медиапотока RTP (1 вызов, 120 с) ===
1. Плоскость сигнализации (SIP, порт 5060):
   Число сообщений за весь вызов:   ~6–8 пакетов (установление и отбой)
   Средний размер сообщения SIP:    ~600 байт
   Суммарный объём SIP за 2 минуты: 7 * 600 = 4 200 байт (~4,2 КБ)
   Полоса SIP во время разговора:   0 бит/с (в разговорной фазе SIP молчит!)

2. Плоскость медиаданных (RTP, кодек G.711, ptime = 20 ms):
   Темп пакетов в одну сторону:     50 пакетов/с (100 пакетов/с дуплекс)
   Размер кадра Ethernet с голосом: 218 байт (160 Б звук + 58 Б заголовки)
   Число пакетов RTP за 120 секунд: 100 пак/с * 120 с = 12 000 пакетов
   Суммарный объём RTP за 2 минуты: 12 000 * 218 = 2 616 000 байт (~2,62 МБ)
   Отношение объёма RTP к SIP:      2 616 000 / 4 200 = 622,8x (в 623 раза больше!)

Во время активного двухминутного разговора сигнальный сервер обрабатывает всего около 4,2 КБ данных в момент старта и завершения звонка, тогда как напрямую между телефонами пролетает 2,62 МБ голосовых пакетов RTP.

История создания: от H.323 и RFC 2543 к RFC 3261

В середине 1990-х годов первым стандартом IP-телефонии стал пакет спецификаций ITU-T H.323 (1996 год). Он вырос из мира традиционной телефонии ISDN (Q.931): сообщения кодировались сложным бинарным форматом ASN.1 PER, для одного звонка требовалось открывать множество параллельных TCP-соединений (H.225.0, H.245), а сам стандарт насчитывал тысячи страниц и плохо интегрировался с веб-сервисами Интернета.

В том же 1996 году в рабочей группе IETF MMUSIC (Multiparty Multimedia Session Control) Хеннинг Шульцринне (Henning Schulzrinne) и Марк Хэндли (Mark Handley) предложили совершенно иной подход: сделать сигнализацию телефонии такой же простой и текстовой, как веб-протокол HTTP и электронная почта SMTP.

Эволюция стандарта SIP прошла два ключевых рубежа:

• Март 1999 года — RFC 2543: первая официальная спецификация SIP версии 2.0 (SIP/2.0), подготовленная Х. Шульцринне, М. Хэндли, Э. Скулером и Дж. Розенбергом. Протокол мгновенно завоевал популярность у производителей IP-телефонов и операторов.
• Июнь 2002 года — RFC 3261: фундаментально переработанный и уточнённый стандарт (авторы: Дж. Розенберг, Х. Шульцринне, Г. Камарильо, А. Джонсон, Дж. Петерсон, Р. Спаркс, М. Хэндли, Э. Скулер), который полностью заменил (obsoleted) RFC 2543. При этом, чтобы не сломать совместимость с уже выпущенным оборудованием, номер версии протокола в сообщениях оставили прежним — SIP/2.0.

Сегодня SIP применяется повсеместно:

1. Корпоративная телефония (IP-АТС / UC): подключение настольных IP-телефонов, программных софтфонов и видеотерминалов к серверу компании (Asterisk, FreeSWITCH, Cisco CUCM).
2. Межоператорские и клиентские стыки (SIP Trunking): подключение офисных АТС к операторам связи и соединение телефонных операторов между собой вместо устаревших потоков E1 ISDN PRI и ОКС-7 (SS7).
3. Мобильные сети 4G и 5G: консорциум 3GPP выбрал SIP в качестве основного протокола сигнализации мультимедийной подсистемы IMS (изучается в отдельном курсе трека), на базе которой работают звонки VoLTE в сетях 4G, VoWiFi и VoNR в сетях 5G.

Что может сломаться и как это найти

⚠️ Никогда не путайте маршрут сигнализации SIP с маршрутом голосового потока RTP. То, что телефон видит сервер АТС по порту 5060, совершенно не гарантирует, что два телефона в разных подсетях или за NAT смогут обменяться пакетами RTP напрямую!

Практика

1. Предскажите. В компании установлено 50 IP-телефонов в подсети 10.10.1.0/24 и 50 IP-телефонов в филиале 10.10.2.0/24. Оба филиала видят центральный SIP-сервер 10.10.0.10, но маршрутизация напрямую между подсетями 10.10.1.0/24 и 10.10.2.0/24 запрещена списком доступа (ACL). Что произойдёт при звонке из первого филиала во второй (по классической трапеции SIP)?
2. Проверьте. Посмотрите на распределение протоколов, портов и плоскостей в стандартном телефонном вызове VoIP:

=== Стек протоколов в SIP-вызове ===
Уровень / Задача          Протокол и стандарт   Транспорт и порты по умолчанию
------------------------  --------------------  ------------------------------
Поиск сервера домена      DNS (RFC 3263)        UDP / TCP порт 53
Установление сеанса       SIP (RFC 3261)        UDP / TCP порт 5060, TLS 5061
Описание медиапараметров  SDP (RFC 8866)        Внутри тела сообщений SIP
Передача голоса и видео   RTP / SRTP (RFC 3550) UDP чётные порты (10000-20000)
Контроль качества медиа   RTCP (RFC 3550)      UDP нечётный порт (RTP + 1)

3. Объясните. Почему в июне 2002 года авторы нового стандарта RFC 3261 не поменяли строку версии протокола на SIP/3.0, а оставили SIP/2.0, как в RFC 2543?
4. Измените. Рассчитайте, сколько байт голосового трафика RTP (кодек G.711, пакет Ethernet 218 байт каждые 20 мс в каждую сторону) пройдёт через сам сигнальный SIP-прокси за 5 минут разговора, если медиапоток идёт по классической трапеции SIP напрямую между телефонами.
5. Сделайте сами (со звёздочкой ⭐). Оператор связи обслуживает 1 000 одновременных разговоров с кодеком G.711 (дуплексный поток RTP каждого звонка — 174,4 кбит/с на уровне Ethernet). Посчитайте, какую полосу пропускания сэкономит центральный сигнальный узел оператора за счёт того, что он обрабатывает только сигнализацию SIP, а потоки RTP идут в обход него напрямую между граничными медиашлюзами.

Самопроверка

Вопрос 1. Какие пять базовых задач решает протокол SIP согласно разделу 2 стандарта RFC 3261?

Разбор. Протокол SIP отвечает за: 1) определение местоположения пользователя (User Location — поиск актуального IP-адреса устройства); 2) определение доступности (User Availability — готов ли абонент ответить); 3) определение возможностей (User Capabilities — согласование кодеков через SDP); 4) установление сеанса (Session Setup — звонок и фиксация параметров); 5) управление сеансом (Session Management — изменение параметров, перевод и завершение вызова).

Вопрос 2. Какой протокол переносит сами оцифрованные голосовые отсчёты после того, как SIP установил вызов, и какие порты по умолчанию задействованы для SIP?

Разбор.

Сигнализация (Control Plane):
  Протокол: SIP (RFC 3261) с вложенным описанием SDP (RFC 8866)
  Порты по умолчанию: 5060 (UDP и TCP), 5061 (TLS)

Медиатракт (User / Media Plane):
  Протокол: RTP (RFC 3550) или защищённый SRTP (RFC 3711)
  Порты: динамические чётные UDP-порты, согласованные в анкете SDP

Ответы к практике:

=== Ответы к практическим заданиям ===
Пункт 1: Сигнализация SIP пройдёт успешно через сервер 10.10.0.10 (оба телефона
         зазвонят и установят соединение), но при ответе наступит полная тишина,
         так как прямой поток RTP между 10.10.1.0/24 и 10.10.2.0/24 заблокирован ACL.
Пункт 3: Версию SIP/2.0 сохранили для обратной совместимости с миллионами уже
         работавших устройств RFC 2543, добавив новые механизмы через расширения.
Пункт 4: 0 байт! В классической трапеции SIP голосовой поток RTP идёт напрямую
         между конечными телефонами и вообще не заходит на сигнальный SIP-прокси.
Пункт 5: 1 000 вызовов * 174,4 кбит/с = 174 400 кбит/с = 174,4 Мбит/с непрерывного
         медиатрафика не нагружают центральный сигнальный сервер SIP.

Повторение и критерий перехода

Переходите к следующему уроку, если без подсказки можете:

• перечислить пять задач протокола SIP по стандарту RFC 3261;
• чётко разделить роли SIP, SDP и RTP/RTCP и назвать стандартные порты 5060 и 5061;
• нарисовать трапецию SIP и объяснить, почему при успешном звонке в трубке может не быть звука.

Стандарты и источники

• IETF RFC 3261 (June 2002) — SIP: Session Initiation Protocol (§1–§2, Overview of Operation).
• IETF RFC 2543 (March 1999) — SIP: Session Initiation Protocol (историческая первая редакция SIP/2.0).
• IETF RFC 8866 (January 2021) — SDP: Session Description Protocol.
• IETF RFC 3550 (July 2003) — RTP: A Transport Protocol for Real-Time Applications.