# Схема вызова SIP: от INVITE до BYE

> Базовый вызов SIP — это трёхстороннее рукопожатие INVITE/200/ACK, за которым следуют медиа и BYE. Вызывающий отправляет INVITE (с предложением SDP); вызываемый отвечает 100 Trying, 180 Ringing, затем 200 OK (с ответом SDP); вызывающий отправляет ACK; текут медиа RTP; и любая сторона завершает вызов BYE, на который отвечают 200 OK.

- Канонический URL: https://www.broadnet.me/ru/reference/sip-call-flow
- Язык: ru
- Последнее обновление: 2026-07-18
- Издатель: BroadNet (https://www.broadnet.me)

Полный вызов SIP шаг за шагом: INVITE с предложением SDP, 100 Trying, 180 Ringing, 200 OK с ответом SDP, трёхстороннее ACK, медиа RTP и завершение BYE/200 OK — плюс как CANCEL прерывает звонящий вызов.

## Установление вызова

Вызов начинается с того, что UAC вызывающего отправляет INVITE к вызываемому, неся предложение SDP, описывающее нужные ему медиа. По мере прохождения запроса через прокси каждый может вернуть 100 Trying, чтобы остановить повторные передачи. Когда телефон вызываемого начинает звонить, обратно течёт 180 Ringing — это и порождает гудки. Если нужны ранние медиа (сетевые объявления, гудки от дальней сети), 183 Session Progress с SDP может открыть медиатракт до ответа.

## Ответ и трёхстороннее рукопожатие

Когда вызываемый отвечает, его UAS возвращает 200 OK, несущий ответ SDP, завершающий согласование медиа. Вызывающий подтверждает ACK — третьей ветвью рукопожатия INVITE — и диалог теперь полностью установлен, идентифицированный Call-ID плюс обоими тегами. Трёхсторонний обмен INVITE/200/ACK, а не простой запрос/ответ, делает установление вызова SIP надёжным даже поверх ненадёжного UDP.

*Полный вызов SIP*

```text
Alice (UAC)                         Bob (UAS)
   │  INVITE (SDP offer)   ─────────▶ │
   │ ◀───────── 100 Trying           │
   │ ◀───────── 180 Ringing          │   (Bob's phone rings)
   │ ◀───────── 200 OK (SDP answer)  │   (Bob answers)
   │  ACK                  ─────────▶ │
   │ ◀═══════ RTP media (both ways) ═▶ │   (the conversation)
   │  BYE                  ─────────▶ │   (Alice hangs up)
   │ ◀───────── 200 OK               │
```

## Медиа и изменения по ходу вызова

Как только ACK завершает установление, медиа RTP текут напрямую между конечными точками (или через медиарелей) на портах, согласованных SDP, независимо от тракта сигнализации. Изменения по ходу вызова делаются re-INVITE или UPDATE, несущими новый SDP — так выполняются удержание (a=sendonly), возобновление (a=sendrecv), пересогласование кодека и добавление видео, всё внутри существующего диалога без разрыва вызова.

## Завершение вызова — BYE

Любая сторона завершает установленный вызов отправкой BYE, что другая подтверждает 200 OK; диалог затем закрывается, и медиа останавливаются. BYE — это внутридиалоговый запрос, поэтому он несёт установленные Call-ID, тег From, тег To и следующий CSeq. Поскольку это обычная транзакция, потерянный BYE повторно передаётся до подтверждения, так что обе стороны сходятся на завершении вызова.

## Прерывание вызова в процессе — CANCEL

Если вызывающий сдаётся до ответа вызываемого — вызов ещё звонит — UAC отправляет CANCEL, а не BYE, потому что окончательный ответ ещё не пришёл. Вызываемый прекращает звонить и возвращает 487 Request Terminated на исходный INVITE, что вызывающий подтверждает ACK. CANCEL допустим только в этом окне до ответа; как только получен 200 OK, вызов установлен, и завершать его нужно BYE.

*Завершение против прерывания вызова*

| Ситуация | Метод | Результат |
|---|---|---|
| Звонок принят, теперь положите трубку | BYE | 200 OK; диалог закрыт |
| Ещё идёт вызов, вызывающий абонент отказывается | CANCEL | 487 Request Terminated в ответ на INVITE |
| Вызываемый абонент отклоняет вызов во время посылки вызова | (ответ) 486/603 | Busy Here / Decline; вызывающий отправляет ACK |

## Частые вопросы

### Какова базовая схема вызова SIP?

INVITE (с предложением SDP) → 100 Trying → 180 Ringing → 200 OK (с ответом SDP) → ACK, затем текут медиа RTP, и вызов завершается BYE → 200 OK. Трёхстороннее рукопожатие INVITE/200/ACK устанавливает диалог; BYE его разрывает.

### Почему SIP использует трёхстороннее рукопожатие для INVITE?

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

### Как поставить вызов SIP на удержание?

Отправьте re-INVITE (или UPDATE) внутри установленного диалога, несущий новый SDP, задающий направление медиа a=sendonly (и a=sendrecv для возобновления). Диалог и вызов остаются; меняется только направление медиа, так же доставляется и музыка на удержании.

### Когда отправлять CANCEL вместо BYE?

Отправляйте CANCEL, когда вызов ещё звонит и окончательный ответ не пришёл — он прерывает ожидающий INVITE и даёт 487. Отправляйте BYE только после того, как вызов установлен (получен 200 OK). Использование неверного оставляет стороны рассинхронизированными.

### Идут ли медиа тем же путём, что и сообщения SIP?

Обычно нет. Сигнализация SIP может проходить через несколько прокси, но медиа RTP текут на отдельно согласованных портах, обычно напрямую между конечными точками или через выделенный медиарелей или SBC — поэтому сигнализация может пройти, тогда как медиа (звук) независимо не проходят.

## Источники

- [IETF RFC 3261 — SIP (call flows)](https://datatracker.ietf.org/doc/html/rfc3261)
- [IETF RFC 3665 — SIP Basic Call Flow Examples](https://datatracker.ietf.org/doc/html/rfc3665)

## См. также

- [Методы и запросы SIP](https://www.broadnet.me/ru/reference/sip-methods-and-requests)
- [Коды ответов SIP](https://www.broadnet.me/ru/reference/sip-response-codes)
- [SDP: Session Description Protocol](https://www.broadnet.me/ru/reference/sdp-session-description-protocol)
- [RTP и SRTP медиа](https://www.broadnet.me/ru/reference/rtp-and-srtp-media)
- [Программируемый голос (продукт)](https://www.broadnet.me/ru/products/voice)