Кратко

  • PRACK подтверждает конкретный надёжный временный ответ. Ответ 2xx на PRACK не является окончательным 2xx на исходный INVITE.
  • RSeq и RAck связывают подтверждение с диалогом, CSeq, методом и порядком; даже завершённый до ответа offer/answer не доказывает доставку медиа или принятие вызова.

Когда сообщения о ходе вызова было недостаточно

RFC 3261 допускает несколько ответов 1xx до окончательного исхода INVITE. Ответы 101–199 сообщают о ходе обработки и могут создать ранний диалог. О принятии говорит окончательный 2xx; другие финальные классы отклоняют или перенаправляют. Однако базовый SIP не доставлял временные ответы надёжно.

При стыковке с телефонной сетью такая потеря могла убрать описание сессии, состояние раннего диалога или важное объявление. Это ещё не итог вызова, но уже информация, от которой зависит следующий обмен.

RFC 3262 добавил 100rel и метод PRACK. Если INVITE сообщает Supported: 100rel, UAS может надёжно отправить временный ответ, кроме 100. Если INVITE требует Require: 100rel, UAS обязан выполнить требование либо отвергнуть расширение. 100 Trying исключён: это поузловой ответ, тогда как новый механизм действует между концами.

Из чего складывается точное совпадение

Надёжный 1xx содержит Require: 100rel и RSeq. Первое число выбирается в заданном диапазоне, а пространство нумерации относится к одной транзакции. Одинаковые RSeq в разных INVITE не обозначают одно сообщение.

UAS повторяет ответ с экспоненциальной задержкой, начиная с T1. Повторы прекращает только совпавший PRACK в том же диалоге. Его RAck копирует RSeq, номер CSeq и метод подтверждаемого ответа. Тем самым квитанция адресуется конкретному временному состоянию, а не вызову вообще.

При совпадении UAS отвечает на PRACK кодом 2xx и удаляет 1xx из списка неподтверждённых. Если совпадения нет, возвращается 481. К какому запросу относится ответ — принципиально: этот 2xx завершает PRACK, но не принимает INVITE.

PRACK похож на ACK по назначению, однако является обычным внутридиалоговым запросом не-INVITE. У него своя поузловая транзакционная надёжность, CSeq и ответ. Благодаря этому можно достоверно получить промежуточный факт, не наделяя его полномочиями финального решения.

Последовательность без накопительного подтверждения

PRACK не подтверждает сразу все предыдущие ответы. Для ограничения перегрузки RFC рекомендует один неподтверждённый надёжный 1xx и запрещает посылать второй до подтверждения первого. Затем RSeq увеличивается ровно на единицу и не зацикливается.

Получатель распознаёт повтор по ID диалога, CSeq и RSeq и отбрасывает копию. Если пришёл более поздний RSeq, минуя ожидаемый, его нельзя обрабатывать или подтверждать; допускается сохранить его до заполнения пробела. Надёжность включает порядок, а не только факт появления пакета.

Если соответствующий PRACK не приходит 64*T1, UAS следует отклонить исходный запрос ответом 5xx. Механизм убирает молчаливую потерю, но добавляет таймеры, список ожидания, маршрутизацию диалога и состояние последовательности. Стандарт не доказывает, насколько правильно это реализовано в действующих сетях.

Параметры сессии уже есть, окончательного согласия ещё нет

PRACK может нести тело. Если INVITE содержал offer, надёжный временный ответ может принести answer. Если offer в INVITE не было, его может дать временный ответ, а PRACK обязан принести answer. Сам PRACK может содержать новый offer, ответ на который находится в его 2xx.

Поэтому параметры сессии способны установиться до финального ответа. Это не означает принятия INVITE. Если неподтверждённый надёжный 1xx содержал описание сессии, UAS должен задержать окончательный 2xx для INVITE до получения PRACK. Ограничение защищает offer/answer, а не передаёт квитанции право принять вызов.

RFC 6337 уточняет: поддержка 100rel обоими агентами не делает каждый временный ответ надёжным. Если INVITE содержал offer, первый SDP в надёжном неошибочном ответе является настоящим answer; более ранний SDP в ненадёжном 1xx — лишь предварительный вариант.

RFC 3311 разрешает UPDATE менять параметры в раннем и подтверждённом диалоге. Но INVITE, PRACK и UPDATE не сливаются: у каждого остаются собственные запрос, последовательность и результат.

Ранний звук не подтверждает сигнализацию

RFC 3960 рассматривает гудки, объявления и другие ранние медиа до окончательного ответа. Сигнализация SIP и медиа связаны слабо, могут идти разными путями и наблюдаться в разное время.

PRACK не доказывает, что RTP дошёл, объявление было услышано или абонент ответил. Слышимое объявление, в свою очередь, не доказывает совпадения RSeq и RAck. Наблюдения полезно сопоставлять, но нельзя подменять одно другим.

Реестр IANA перечисляет PRACK, RAck, RSeq и 100rel со ссылкой на RFC 3262. Это свидетельство официального назначения, а не внедрения или соответствия. Совпадение чисел также не удостоверяет отправителя: внедрённый злоумышленником PRACK способен преждевременно прекратить повторы, поэтому запрос следует аутентифицировать как любой другой.

Источники