Кратко

  • Диагностический loopback возвращает полученный тестовый сигнал и поэтому является явным исключением из запрета на исходные медиа без согласия; он не разрешает захват помещения.
  • Answer-Mode и Priv-Answer-Mode передают просьбу, а не команду. Привилегированный вариант вызывает более строгую проверку, а два вида require не обходят локальную политику.
  • Если автоматически принятый входной диалог позже меняется на исходный или двусторонний, UAS обязан получить явное согласие пользователя и проверять состояние на протяжении диалога.

Один и тот же пакетный путь мог означать разные источники

В тесте endpoint принимает сигнал и возвращает его испытательной службе. Полезным объектом является сам тестовый поток. Микрофон пользователя не нужен. Поэтому RFC 5373 позволяет отличить такой loopback от обычного исходящего аудио.

Если реализация хранит лишь media_out=true, различие исчезает. Нужны источник семплов, назначение, SDP-направление, режим loopback и связь с тестовой транзакцией. Поток от генератора теста не доказывает разрешение на поток от микрофона.

Минимальная политика запрещает UAS устанавливать исходные или двусторонние медиа, полученные от устройства пользователя, без явного принятия. Для входного автоматического воспроизведения также требуется известная и уполномоченная личность; иначе остаются спам, шум, расходы и разряд батареи.

Auto не отменял решение принимающей стороны

Answer-Mode: Auto просит UAS принять INVITE без ожидания кнопки. UAS всё равно проверяет аутентифицированную личность, локальную авторизацию, предпочтения и риск конкретной модальности. Он может обработать вызов вручную или отклонить.

Auto;require запрещает ручную замену: если политика не выбрала автоматический режим, вызов отклоняется. Параметр оценивается после политики и не заставляет устройство действовать.

Require: answermode требует понимания расширения, а не автоответа. REGISTER и Accept-Contact помогают выбрать объявивший поддержку contact, но не являются квитанцией конкретной авторизации.

Priv не переносил полномочие в заголовке

RFC сравнивает Priv-Answer-Mode с sudo. Он запрашивает обращение к привилегированной таблице, обычно более строгой и закрытой по умолчанию. Префикс не утверждает, что отправитель уже имеет право.

Одна личность может послать обычную просьбу сейчас и срочную позже. Автоматическое повышение всех её вызовов стирает намерение. Если присутствуют оба поля, UAS сначала проверяет Priv и при отказе обрабатывает обычное поле. Этот путь должен быть записан.

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

Согласие должно было пережить re-INVITE

Диалог может начаться как входной: громкоговоритель принимает речь, микрофон закрыт. Затем re-INVITE или UPDATE предлагает sendrecv. Поля answering mode не определены для запросов внутри диалога, но защита обязана отслеживать состояние.

Без нового события явного согласия UAS не должен начать отправлять локальный звук. Первоначальная авторизация была ограничена направлением и целью. Считать её пожизненным свойством диалога значит превратить безопасный вход в возможность прослушивания.

Fork создавал несколько физических последствий

Параллельная развилка может доставить INVITE нескольким устройствам. Несколько UAS автоматически отвечают 200; SIP сохраняет первый диалог и посылает BYE остальным. Проигравший терминал мог успеть воспроизвести медиа.

RFC поэтому не рекомендует auto-answer при параллельном forking. Нужно хранить contact, branch, время 200, начало медиа и BYE каждого устройства. Итоговый единственный диалог не доказывает единственного действия.

Ответ мог не раскрывать режим

UAS может сообщить в 200 Manual или Auto. Но Manual способен раскрыть присутствие человека, поэтому рекомендуемый режим по умолчанию — отсутствие поля.

Отсутствие остаётся неизвестностью. Нельзя превращать его в Auto, Manual или отсутствие поддержки. Даже явное Auto означает лишь отсутствие определённого UI-взаимодействия, а не отсутствие человека, слышимость или понимание.

Прокси действовал только по внешнему соглашению

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

Иначе значение на входе UAS ошибочно принимается одновременно за намерение вызывающего и разрешение владельца устройства.

Граница доказательства

Полная запись связывает начальный INVITE, личность и аутентификацию, обычную или привилегированную просьбу, оба require, выбранный contact и все branches, решение политики, ответ и раскрытие, направление каждой версии SDP, источник медиа, согласие пользователя и реальные исходящие пакеты. Человеческий результат остаётся отдельно.

Так loopback сохраняет своё узкое назначение, а микрофон не наследует право от похожего транспортного потока.