← Карта
01

Основы телефонии

Фундаментальные протоколы и концепции, на которых строится любая современная телефонная система. Понимание этих основ — ключ ко всему остальному.

Что такое VoIP

Voice over IP — голос поверх интернет-протокола

VoIP (Voice over Internet Protocol) — это технология передачи голоса через IP-сети (интернет, локальная сеть) вместо традиционных телефонных линий. Голос оцифровывается, сжимается кодеком и отправляется в виде IP-пакетов — точно так же, как веб-страницы или электронная почта.

Традиционная телефония (PSTN)

Выделенный канал на всё время разговора (circuit-switching). Один провод — один звонок. Дорогая инфраструктура, ограниченные возможности, фиксированная маршрутизация.

VoIP-телефония

Голос передаётся пакетами через общую IP-сеть (packet-switching). Один канал — тысячи звонков. Дешёвая инфраструктура, гибкая маршрутизация, интеграция с ПО.

Почему VoIP победил?

Стоимость: междугородние и международные звонки почти бесплатны. Гибкость: можно звонить с телефона, компьютера, браузера. Интеграция: CRM, аналитика, запись, IVR — всё через API. Масштабирование: добавление линий не требует нового оборудования.

Ключевой принцип VoIP

В VoIP есть чёткое разделение сигнализации и медиа. Сигнализация (SIP) — это «кто кому звонит, принять/отклонить». Медиа (RTP) — это сам голос. Они передаются по разным каналам и могут идти разными путями.

Протокол SIP

SIP — Session Initiation Protocol

SIP — протокол сигнализации. Он отвечает только за установку, изменение и завершение сеансов связи. SIP не передаёт голос — для этого используется RTP. SIP похож на HTTP: текстовый, читаемый, с заголовками и методами. Стандартные порты: 5060 (UDP/TCP) и 5061 (TLS).

Полный диалог SIP-вызова между двумя телефонами через АТС (PBX):

Телефон A                    PBX (АТС)                   Телефон B
    │                           │                           │
    │  ──── INVITE ────>       │                           │
    │                           │  ──── INVITE ────>       │
    │                           │                           │
    │                           │  <── 100 Trying ───       │
    │  <── 100 Trying ───       │                           │
    │                           │                           │
    │                           │  <── 180 Ringing ──       │
    │  <── 180 Ringing ──       │                           │
    │                           │                           │
    │                           │  <──── 200 OK ─────       │
    │  <──── 200 OK ─────       │                           │
    │                           │                           │
    │  ────── ACK ──────>       │  ────── ACK ──────>       │
    │                           │                           │
    │  ═══════════════════ RTP (голос) ═══════════════════   │
    │                           │                           │
    │  ────── BYE ──────>       │  ────── BYE ──────>       │
    │                           │                           │
    │                           │  <──── 200 OK ─────       │
    │  <──── 200 OK ─────       │                           │
    │                           │                           │
Рис. 1 — Полный SIP-диалог: установка, медиа-сессия и завершение вызова
1
INVITE — инициация звонка. Содержит SDP с параметрами медиа (кодеки, IP, порт).
2
100 Trying — сервер принял запрос и обрабатывает (временный ответ).
3
180 Ringing — телефон получателя звонит (вызывающий слышит гудки).
4
200 OK — получатель поднял трубку. Содержит ответный SDP.
5
ACK — подтверждение. После него начинается RTP-поток (голос).
6
BYE — завершение вызова. Ответ 200 OK подтверждает разрыв.

Анатомия SIP INVITE-сообщения — ключевые заголовки:

SIP INVITE — пример сообщения
INVITE sip:1002@192.168.1.10 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.20:5060;branch=z9hG4bK776 From: "Иван Иванов" <sip:1001@192.168.1.10>;tag=49583 To: <sip:1002@192.168.1.10> Call-ID: a84b4c76e66710@192.168.1.20 CSeq: 314159 INVITE Contact: <sip:1001@192.168.1.20:5060> Content-Type: application/sdp Max-Forwards: 70 Content-Length: 142 ; ─── SDP-тело (Session Description Protocol) ─── v=0 o=- 2890844526 2890844526 IN IP4 192.168.1.20 s=SIP Call c=IN IP4 192.168.1.20 t=0 0 m=audio 49170 RTP/AVP 0 8 101 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000
Ключевые заголовки

From / To — кто звонит и кому
Via — маршрут прохождения запроса
Contact — прямой адрес для ответа
Call-ID — уникальный идентификатор звонка
CSeq — порядковый номер транзакции

SDP-тело

SDP (Session Description Protocol) передаётся внутри SIP-сообщений и описывает медиа-параметры:
— IP-адрес и порт для RTP
— Список поддерживаемых кодеков
— Тип медиа (аудио, видео)
Обе стороны обмениваются SDP для согласования параметров (offer/answer).

Протокол RTP

RTP — Real-time Transport Protocol

RTP — протокол, который передаёт сам голос (и видео). В отличие от SIP, RTP работает поверх UDP и отправляет пакеты с аудио-данными 50 раз в секунду (каждые 20 мс). RTP-поток идёт отдельно от SIP — часто напрямую между устройствами, минуя сервер. 

SIP-сигнализация                          RTP-медиа

  Телефон A ──SIP──> PBX ──SIP──> Телефон B     Телефон A ═══RTP═══ Телефон B
  (порт 5060)        (порт 5060)               (порт 10000-20000)

Сигнализация проходит через PBX,         Медиа может идти напрямую
а медиа — напрямую между телефонами       (если PBX не нужен для записи/мониторинга)
Рис. 2 — Разделение сигнализации (SIP) и медиа (RTP)

Структура RTP-пакета:

Структура RTP-заголовка (12 байт)
; Каждый RTP-пакет содержит: ┌──────────────────────────────────────────────────┐ │ V=2 │ P │ X │ CC │ M │ Payload Type (7 бит) │ ; Тип кодека (0=PCMU, 8=PCMA...) ├──────────────────────────────────────────────────┤ │ Sequence Number (16 бит) │ ; Порядковый номер пакета ├──────────────────────────────────────────────────┤ │ Timestamp (32 бит) │ ; Временная метка аудио-семпла ├──────────────────────────────────────────────────┤ │ SSRC (32 бит) │ ; Идентификатор источника ├──────────────────────────────────────────────────┤ │ Payload (аудио-данные) │ ; 160 байт для G.711 @ 20мс └──────────────────────────────────────────────────┘
Ключевые поля

Payload Type — какой кодек используется (определён в SDP при установке).
Sequence Number — порядковый номер для обнаружения потерь пакетов.
Timestamp — когда был записан аудио-семпл (для синхронизации).
SSRC — уникальный идентификатор потока (один на каждого участника).

Джиттер-буфер (Jitter Buffer)

Пакеты приходят с разной задержкой (jitter). Джиттер-буфер накапливает несколько пакетов и выдаёт их с равномерным интервалом. Слишком маленький буфер — потери и щелчки. Слишком большой — заметная задержка голоса. Типичный размер: 20–60 мс. Адаптивный буфер подстраивается автоматически.

RTP и RTCP

Вместе с RTP работает протокол RTCP (RTP Control Protocol) — он передаёт статистику качества: потери пакетов, джиттер, задержку. RTCP используется для мониторинга качества связи, но не для самого голоса.

Кодеки

Кодек (Codec) — алгоритм кодирования и декодирования голоса. Определяет качество звука, требуемую полосу пропускания и вычислительную нагрузку. Выбор кодека — компромисс между качеством и трафиком.

Кодек Битрейт Качество Сжатие Особенности
G.711 (a-law / u-law) 64 kbps Отличное Нет Стандарт для LAN. a-law — Европа, u-law — Северная Америка. Минимальная задержка.
G.722 64 kbps HD Voice Нет Широкополосный (wideband, 16 kHz). Звучит заметно лучше G.711. Поддерживается большинством IP-телефонов.
G.729 8 kbps Хорошее 8:1 Сильное сжатие — идеален для каналов с ограниченной полосой. Лицензируемый (есть бесплатный G.729a).
Opus 6–510 kbps Лучшее Переменное Современный, адаптивный. Используется в WebRTC. Open-source, без лицензий. Лучшее качество на любом битрейте.
iLBC 13.3 / 15.2 kbps Хорошее ~4:1 Устойчив к потерям пакетов (каждый фрейм независим). Хорош для нестабильных сетей.
GSM 13 kbps Среднее ~5:1 Унаследованный кодек мобильных сетей. Используется редко, но иногда встречается в legacy-системах.
Рекомендация

Для внутренней сети (LAN) используйте G.711 или G.722 — максимальное качество, полоса не проблема. Для WebRTC — Opus (он обязателен). Для каналов с ограниченной полосой — G.729. Opus является лучшим универсальным выбором, если оборудование его поддерживает.

DTMF

DTMF — Dual-Tone Multi-Frequency

DTMF — тоновые сигналы, генерируемые при нажатии кнопок на телефоне. Каждая кнопка — это комбинация двух частот (отсюда «dual-tone»). DTMF используется для навигации по голосовым меню (IVR), ввода PIN-кодов, управления конференциями и других интерактивных сценариев.

Три способа передачи DTMF в VoIP:

In-band (в аудиопотоке)

Тоны передаются прямо в RTP-потоке как обычный звук. Проблема: сжимающие кодеки (G.729) искажают тоны, и они не распознаются. Работает только с G.711.

Ненадёжный

RFC 2833 (RTP Events)

Цифры передаются как специальные RTP-пакеты с payload type 101. Не зависит от кодека — работает всегда. Самый распространённый метод.

Рекомендуемый

SIP INFO

Цифра отправляется в SIP-сообщении типа INFO. Используется в некоторых специфичных сценариях (например, при взаимодействии с определёнными шлюзами).

Специальный

Важно для IVR

Если ваши голосовые меню не реагируют на нажатия — почти всегда проблема в режиме DTMF. Убедитесь, что и сервер, и телефон используют один и тот же метод (обычно RFC 2833).

NAT и телефония

Почему NAT — главная головная боль VoIP

NAT (Network Address Translation) заменяет приватные IP-адреса на публичный при выходе в интернет. Проблема: SIP-сообщения содержат приватный IP телефона («отправляй голос на 192.168.1.100:10000»), который недоступен извне. Результат — одностороннее аудио или полное его отсутствие. 

Проблема NAT в VoIP:

Телефон A                 NAT/Роутер              SIP-сервер
192.168.1.100             203.0.113.50             198.51.100.10
     │                        │                        │
     │  SIP INVITE            │                        │
     │  Contact: 192.168.1.100 │                        │
     │  SDP: audio 192.168.1.100:10000                  │
     │ ──────────────────────>│                        │
     │                        │  SIP INVITE            │
     │                        │  Contact: 192.168.1.100 <── Приватный IP!
     │                        │ ──────────────────────>│
     │                        │                        │
     │                        │    RTP → 192.168.1.100 │
     │                        │        НЕДОСТУПЕН!      │
     │                        │    ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗  │
Рис. 3 — Приватный IP-адрес в SDP недоступен из интернета — голос не проходит

Решения проблемы NAT:

STUN Основной

Session Traversal Utilities for NAT. Телефон спрашивает STUN-сервер: «какой у меня публичный IP и порт?» — и подставляет их в SDP. Работает с большинством NAT. Не работает с symmetric NAT.

TURN Запасной

Traversal Using Relays around NAT. Весь медиа-трафик проходит через TURN-сервер (relay). Работает всегда, но увеличивает задержку и нагрузку на сервер. Используется когда STUN не помогает.

ICE Комплексный

Interactive Connectivity Establishment. Собирает все возможные «кандидаты» (прямой IP, STUN, TURN) и проверяет каждый путь. Выбирает лучший рабочий вариант. Стандарт для WebRTC.

SIP ALG Избегайте

Application Layer Gateway. Функция роутера, которая «умно» переписывает SIP-пакеты. На практике почти всегда ломает SIP. Рекомендация: отключить SIP ALG на роутере.

Практический совет

Если звонок устанавливается (вы слышите гудки), но после ответа нет голоса — в 90% случаев это проблема NAT. Проверьте: STUN настроен? SIP ALG отключён? Порты RTP (10000–20000) проброшены?

WebRTC

WebRTC — звонки прямо из браузера

WebRTC (Web Real-Time Communication) — стандарт, встроенный во все современные браузеры (Chrome, Firefox, Safari, Edge), позволяющий передавать голос, видео и данные без плагинов. Для VoIP это означает: пользователь открывает веб-страницу и сразу может звонить.

Технологический стек WebRTC:

Медиа и безопасность

Opus — обязательный аудио-кодек (лучшее качество)
DTLS-SRTP — шифрование медиа (обязательно, нельзя отключить)
ICE + STUN + TURN — решение NAT-проблем
SDP — описание медиа-сессии (offer/answer)

Подключение к SIP-миру

Способ 1: SIP over WebSocket
Библиотека SIP.js или JsSIP в браузере отправляет SIP-сообщения через WebSocket (WSS). Сервер (FreeSWITCH) принимает их как обычные SIP.

Способ 2: Verto Protocol
Собственный протокол FreeSWITCH поверх WebSocket (JSON-RPC). Проще, чем SIP, но привязан к FreeSWITCH.

Браузер (WebRTC)          FreeSWITCH            SIP-телефон

┌─────────────┐       ┌──────────────┐       ┌───────────┐
│  SIP.js     │       │ mod_verto    │       │           │
│  (JavaScript│──WSS──│ mod_sofia    │──SIP──│ IP Phone  │
│  WebRTC API)│       │              │       │           │
└─────────────┘       └──────────────┘       └───────────┘
       │                     │                     │
       └─────── DTLS-SRTP (шифрованный RTP) ───────┘
                      или через сервер
Рис. 4 — Подключение WebRTC-браузера к SIP-инфраструктуре через FreeSWITCH
WebRTC = будущее телефонии

WebRTC делает телефонию доступной любому пользователю с браузером — без установки ПО, без настроек сети, с обязательным шифрованием. Идеально для контакт-центров, CRM-интеграций и клиентских порталов.

Минимальный пример подключения SIP.js к FreeSWITCH
JavaScript — SIP.js UserAgent
const ua = new SIP.UserAgent({ uri: SIP.UserAgent.makeURI("sip:1001@pbx.example.com"), transportOptions: { server: "wss://pbx.example.com:7443" }, authorizationUsername: "1001", authorizationPassword: "secret" }); // Подключение и регистрация await ua.start(); const registerer = new SIP.Registerer(ua); await registerer.register(); // Исходящий звонок const inviter = new SIP.Inviter(ua, SIP.UserAgent.makeURI("sip:1002@pbx.example.com") ); await inviter.invite();