Summary

  • RFC 5373 lets an INVITE request manual or automatic answering. The request influences the UAS; it does not overrule authentication, authorization, user preference or media-risk policy.
  • Priv-Answer-Mode requests a stricter privileged-policy lookup rather than asserting privilege. ;require asks for rejection when policy chooses another mode, while Require: answermode requires extension support—not the requested behavior.
  • An automatically accepted inbound-only session must not later acquire outbound or bidirectional media through re-INVITE or UPDATE without explicit user acceptance. Consent is therefore dialog state, not a bit copied from the initial INVITE.

One Require governed comprehension; another governed fallback

RFC 5373 contains two mechanisms whose English names invite overstatement. A SIP Require: answermode header says that the target must support the extension or reject the request. The require parameter attached to Answer-Mode: Auto;require says that if local policy will not select automatic answering, the target should reject instead of falling back to manual handling.

Neither mechanism commands a phone to answer. The first proves protocol comprehension. The second narrows the acceptable outcome after the UAS has made its own policy decision. RFC 5373 says plainly that SIP has no negotiation technique that forces the specified behavior.

A defensible trace therefore retains both layers. The request may show extension support was mandatory and auto-answer was preferred without fallback. The response may show 403, 200, or another SIP result. A successful 200 can additionally report Answer-Mode: Auto, but that report covers only the defined user-interface interaction. It is not a receipt for human attention or intelligible media.

This is a recurring control mistake in automation: a requester confuses the right to constrain its own acceptable outcomes with the right to choose another system's action. ;require lets the caller say “automatic or no session.” It does not let the caller say “automatic regardless of your rules.”

Priv was a request to consult a stricter table

The RFC's most revealing analogy is sudo. Priv-Answer-Mode: Auto resembles asking a system to run a command through an administrative policy. Prefixing the request does not confer authority. The UAS authenticates the requester, checks a distinct and normally stricter authorization policy, and may refuse.

That difference preserves intent. A dispatcher who is authorized for urgent treatment can still make an ordinary request that follows the user's quiet-mode preference. Only the deliberately privileged request asks the endpoint to consult the exceptional policy. Identity alone does not erase the distinction.

If both ordinary and privileged fields arrive, the UAS first tests privileged authorization. An authorized requester receives privileged handling; an unauthorized one falls back to processing the ordinary field. A log that records only the final word Auto loses which policy was invoked, whether the identity passed that policy and whether the ordinary fallback was used.

Authentication also has a historical boundary. RFC 5373 cited SIP Digest, asserted identity in suitable trusted networks and the then-current RFC 4474 Identity mechanism. RFC 4474 was later obsoleted by RFC 8224. The enduring proposition is the need for a suitable identity mechanism and authorization decision, not a claim that one 2008 mechanism is universally deployed today.

Auto described interaction, not consent to every consequence

Answer-Mode: Auto asks the UAS to accept without waiting for the user's affirmative interaction. That is useful for diagnostic loopback, push-to-talk and tightly governed intercom service. It is also why the RFC treats media characteristics as part of authorization.

Inbound media played through a loudspeaker can disturb, deceive, cost money or drain a battery. Outbound media from a microphone or camera can expose a private environment. Bidirectional media combines both risks. An identity allowed to send a talk burst is not automatically entitled to hear the room.

The minimum policy reflects that asymmetry. An unknown or unauthorized caller should not obtain automatic inbound playout. More strongly, a UA must not source outbound or bidirectional media without explicit user acceptance. Diagnostic loopback is the explicit exception because the returned media is the test signal, not an open human microphone.

The RFC's definition of automatic answering is procedural: the UAS did not wait for the specified UI action. It does not prove that the user heard the alert, was present, understood the media, consented to recording, or agreed to any business proposition. Those are different claims with different observers.

The microphone boundary survived the initial 200

An endpoint can safely auto-answer an inbound-only session and later receive a re-INVITE or UPDATE that proposes outbound or bidirectional media. If the implementation treats the initial auto-answer authorization as a permanent dialog grant, the new offer can silently turn a speaker into a listening device.

RFC 5373 prevents that shortcut. The UAS must inspect dialog state and must not transition into UA-sourced outbound media without explicit user acceptance. The original Answer-Mode headers are not defined for mid-dialog requests, but the security obligation follows the media state across them.

This turns consent into a state machine. Store the initial identity and policy decision, negotiated media direction, every later offer/answer change, the user-acceptance event that authorizes a transition, and the device controls actually activated. A database field named auto_answer_authorized is insufficient if it cannot say for which direction, modality, dialog version and time interval the authorization applied.

Forking multiplied actions before one dialog won

SIP can fork one INVITE to several registered contacts. If several auto-answer, more than one UAS can send 200. Normal SIP retains the first accepted dialog and tears down other accepted dialogs with BYE.

That convergence is not proof that only one device acted. A losing branch may have opened a loudspeaker, rendered early or accepted media before teardown arrived. RFC 5373 therefore does not recommend auto-answer in parallel-forking environments.

Contact capability preferences do not remove this risk. A registration can advertise answermode, and Accept-Contact can steer toward supporting targets, but a capability tag is neither a unique physical endpoint nor an authorization receipt. Operators need branch-level evidence: selected contacts, provisional and final responses, timing, media onset and teardown for every fork.

The alternative designs named by the RFC—manual acceptance with early media, or dynamic conferencing—move the control surface. They do not make the evidence disappear. A conference mixer owns admission and flow mediation; early media owns a different boundary between hearing and accepting.

A response could reveal presence, so absence remained unknown

A UAS may place Answer-Mode or Priv-Answer-Mode in the 200 response to describe whether it answered manually or automatically. The information can help a push-to-talk caller decide how to speak. It can also reveal that a real person interacted with the device.

For that reason, response inclusion is optional and the recommended default is omission. Absence cannot be normalized to Manual, Auto, or “unsupported.” It means the answering-mode evidence was not disclosed on that surface.

Even when present, Manual reports the defined interaction, not verified identity of the person at the device. Auto reports absence of that interaction, not unattended operation. A caller may infer context, but the protocol field cannot carry the weight of presence, attention or consent.

Serving proxies could rewrite the request only under delegated authority

Ordinary intermediaries ignore the answering-mode fields. A serving proxy may insert, delete or alter them under local policy only when an explicit external agreement authorizes it to act for the served user. Otherwise the mutation can turn a diagnostic request into a human interruption or weaken a user's chosen boundary.

This exception makes provenance essential. A received field may represent caller intent, authorized proxy policy, or an unauthorized intermediary change. The RFC notes that SIP commonly lacks end-to-end message protection and consequently depends on transitive trust across proxies.

Store the original request where available, every authorized transform, the agreement or policy version, and the final bytes evaluated by the UAS. TLS on one hop proves neither end-to-end origin nor semantic preservation across all hops.

Evidence boundary

A complete answering-mode record should keep:

  1. dialog-forming INVITE identity, authentication method and request bytes;
  2. ordinary versus privileged field, requested value and ;require parameter;
  3. Require and Accept-Contact conditions and the chosen registered contact;
  4. every fork branch and its response/teardown timing;
  5. any authorized serving-proxy mutation and governing agreement;
  6. the UAS policy version and authorization decision;
  7. response status and optional response-side answering-mode disclosure;
  8. negotiated media modality and direction for each dialog version;
  9. explicit user-acceptance evidence for any UA-sourced media transition;
  10. playout, capture, human attention and business outcome as separate observations.

The narrow public statement is then defensible: a particular UAS handled an initial INVITE under a particular answering-mode policy. The record does not pretend that request syntax commanded consent or that a successful SIP dialog proved a human result.