Кратко

  • В RFC 3960 ответ 180 Ringing означал, что вызываемую сторону оповещают; он не подтверждал доставку тонального сигнала или объявления.
  • Клиент мог создавать местный гудок при отсутствии пакетов, переключаться на пришедший поток и отдельно оценивать согласование, аутентификацию, воспроизведение и итог звонка.

Звонящий слышал обычный гудок, хотя ни один такой звук не проходил по сети. Его аппарат получил лишь сообщение о том, что другой конец оповещается, и сам заполнил тишину. Позже мог прийти поток с объявлением или особым тоном, и источник звука менялся. Для человека ожидание было непрерывным; для доказательной цепочки — нет.

RFC 3960 описала в 2004 году ранние медиа — звук или видео между начальным INVITE и окончательным ответом. Это могли быть гудок, сообщение очереди, отказ или интерактивный запрос. Главным было не описание мелодии, а отказ считать продвижение сигнализации доказательством потока.

Пример политики содержит три шага. До 180 Ringing POTS-подобный клиент не создаёт местный гудок. После 180, пока пакетов нет, создаёт. Когда пакеты появляются, воспроизводит их и прекращает местный тон. 180 говорит, что вызываемого оповещают; UAS должен сообщить это независимо от состояния ранней медиасессии.

Одной сигнализации недостаточно. Простой сервер мог посылать ранние медиа без надёжных предварительных ответов. Другой мог вернуть SDP answer в надёжном предварительном ответе только ради предусловий, ещё не собираясь передавать звук. RFC 3262 сделала ответы надёжными через RSeq, RAck и PRACK, но не превратила квитанцию управления в квитанцию RTP. RFC 3312 связывала продвижение с ресурсами, а не с фактом слышимого аудио.

Маршруты также расходились. SIP шёл через сервисные прокси, медиа — по пути с меньшей задержкой. Пакеты могли обогнать описывающий их ответ. Бывал и обратный порядок: 180 уже пришёл, а медиасвязь ещё создавалась. Один индикатор ранних медиа не устранял обе гонки. RFC 3960 предложила наблюдаемое правило: дать местную обратную связь и уступить реально пришедшему потоку.

Даже пакет не был конечным доказательством. Внутри могла быть тишина или комфортный шум. RFC 3711 дала SRTP аутентификацию, целостность, защиту от повторов и шифрование. Однако криптографический приём не доказывал декодирование, работу динамика или человеческое понимание. 180, согласованный адрес, первый пакет и первый полезный аутентифицированный звук требовали разных записей.

RFC 3264 определила offer/answer, а RFC 3261 — несущие их сообщения. Согласование параметров подтверждало совместимость, не трафик. Клиент должен был уметь воспроизводить до 200 OK, иначе при опережении медиа терялись первые слова.

Разветвление умножало варианты. Один INVITE создавал несколько ранних диалогов и потоков. Одновременное аудио путало пользователя, а полоса вынуждала выбирать. В шлюзовой модели клиент выбирал ветвь и заглушал остальные. Позднее 2xx могла вернуть именно заглушенная ветвь. Разблокировка вызывала обрезание начала. Поток, услышанный первым, не определял окончательную сессию.

Модель сервера приложений разделяла ранние и обычные медиа. RFC 3959 определила disposition и option tag early-session. Раннее предложение можно было отклонить или заглушить, не разрушая будущую обычную сессию. Разделение улучшало контроль, но не доказывало доставку и не выбирало само нужный поток.

Alert-Info тоже не назначал момент. Он указывал альтернативный тон, если клиент уже решил генерировать его локально, но не давал команду начать.

Раздел безопасности показал цену ошибки. Адрес SDP не аутентифицировал владельца. Злоумышленник мог узнать или угадать порт, а вредное предложение — направить большой поток жертве. Документ обсуждал защиту описаний, аутентификацию медиа и проверку готовности принимать перед большой передачей. Была и тарифная мотивация: если ранние медиа бесплатны, недобросовестный агент мог вести двусторонний обмен без 200 OK. Полный запрет при этом сломал бы законные IVR, собирающие ввод до ответа.

Исторический вывод RFC 3960 состоит в сохранении различий. Удалённое оповещение, местный гудок, пришедший поток и услышанный человеком звук можно соединить в удобный опыт, но нельзя выдавать друг за друга.

Запись RFC Editor и поиск опечаток закрепляют источник. Контекст дают RFC 3261, RFC 3262, RFC 3264, RFC 3959, RFC 3312 и RFC 3711.