Requesting Answering Modes for the Session Initiation Protocol (SIP)
Extracted elements (23)
Auto-answer is NOT RECOMMENDED in environments with parallel forking because forking can cause multiple UASs to auto-accept simultaneously, exacerbating the multiple-acceptance problem. The document suggests early media or dynamic conferencing as alternatives.
Priv-Answer-Mode is not an assertion of privilege but a request for privileged treatment, modeled after the UNIX 'sudo' pattern. This design allows the same caller to make both ordinary (Answer-Mode) and urgent/privileged (Priv-Answer-Mode) requests, receiving different handling based on which header is used rather than solely on identity.
The specification deliberately excludes 'Alerting Mode' (how the UAS notifies its user of an incoming request) and addresses only 'Answering Mode' (whether user interaction is required before accepting). This distinction was debated in the working group and kept scope narrow to avoid conflating two separate concerns.
Answer-Mode and Priv-Answer-Mode are defined only for initial (dialog-forming) INVITE requests and 200 OK responses to those requests. Usage in ACK, CANCEL, re-INVITE, or any mid-dialog context is explicitly not defined and such headers in other requests are ignored.
A UA supporting Answer-Mode and Priv-Answer-Mode SHOULD indicate support by including the option tag 'answermode' in the Supported header of all requests it sends.
A UAS SHOULD apply a stricter authorization policy to requests with Priv-Answer-Mode than to requests with Answer-Mode. The default policy SHOULD be to refuse Priv-Answer-Mode requests unless the requester is authenticated and specifically authorized.
For a request with Answer-Mode: Auto and the 'require' parameter, the UAS MUST NOT allow manual answer; if it chooses not to accept automatically for any reason, it MUST reject the request, SHOULD use 403 Forbidden, and MAY include reason phrase 'automatic answer forbidden'.
For a request with Answer-Mode: Manual and the 'require' parameter, the UAS MUST defer accepting until the user confirms. If the UAS cannot answer manually, it MUST reject the request, SHOULD respond with 403 Forbidden, and MAY include reason phrase 'manual answer forbidden'.
Implementations MUST ignore unknown answer-mode-value tokens (forward compatibility hook). The specification defines behavior only for 'Manual' and 'Auto' values.
Proxies MUST NOT insert, delete, or alter Answer-Mode or Priv-Answer-Mode header fields unless explicitly authorized by an external agreement between the proxy operator and the user of the UA being served.
UASs supporting this specification SHOULD include appropriately configurable policy mechanisms for deciding whether to include Answer-Mode or Priv-Answer-Mode in responses, and the default configuration SHOULD be to exclude this header from responses (to avoid revealing whether a human is present).
When making an authorization decision for automatic answering, the UAS MUST consider the risk model of the media session and MUST NOT answer without user input where the privacy or security of the user would be compromised.
The Answer-Mode header field is used in SIP INVITE requests to request specific user-interface handling. Its values are 'Manual' (defer acceptance until user confirms) or 'Auto' (accept without user input). It may also appear in 200 OK responses to indicate how the UAS handled the request.
The Priv-Answer-Mode header field operates identically to Answer-Mode but requests privileged/administrative-level treatment, subject to stricter authorization policy at the UAS. It is analogous to 'sudo' in UNIX: it requests escalated privilege rather than asserting it.
The 'require' modifier on Answer-Mode or Priv-Answer-Mode (e.g., 'Answer-Mode: Auto;require') instructs the UAS to reject the call if it cannot or will not answer in the requested mode, rather than answering in an alternate mode. The modifier is evaluated only after the UAS has selected an answering mode.
The SIP option tag 'answermode' indicates support for the Answer-Mode and Priv-Answer-Mode extensions. A supporting UA SHOULD include this in the Supported header of all requests and MAY advertise it via the extensions parameter in Contact headers of REGISTER requests.
When both Answer-Mode and Priv-Answer-Mode are present in a request, the UAS first tests authorization for Priv-Answer-Mode. If authorized, it processes as if only Priv-Answer-Mode was present; otherwise it falls back to processing as if only Answer-Mode was present.
This document registers two new SIP header fields ('Answer-Mode' and 'Priv-Answer-Mode') in the SIP Header Fields registry, two 'require' parameter entries in the SIP Header Field Parameters and Parameter Values registry, and one new SIP option tag ('answermode') in the SIP Option Tags registry.
Potential attacks enabled by automatic answering include turning a phone into a remote listening device ('bug-my-phone'), reverse charge fraud, spam over push-to-talk (SPTT), denial-of-service via battery rundown or 'forced busy', and phishing via session insertion. The security model is completely dependent on transitive trust across SIP proxies since end-to-end message protection is not commonly implemented.
The minimal policy requires that UAs MUST NOT establish a session providing outbound or bidirectional media without explicit user acceptance. This prevents the extension from being used to activate a remote microphone ('bug'). Additionally, if a session was auto-answered with inbound-only media, the UAS MUST NOT transition to outbound/bidirectional media without explicit user acceptance.
UAs implementing these extensions MUST be equipped with and MUST exercise a request-identity mechanism (e.g., SIP Digest Authentication, SIP Identity [RFC4474], or asserted identity [RFC3325]). Failure to verify caller identity either opens the door to a wide range of attacks or requires policy so tight as to make the extensions useless.
UAs SHOULD NOT establish a session providing inbound media without explicit user acceptance where the requesting user is unknown or unauthorized. This is intended to prevent unsolicited media playout ('SPAM broadcast' / 'whoopee-cushion') attacks.
The ABNF syntax defines Answer-Mode and Priv-Answer-Mode as header-name HCOLON answer-mode-value *(SEMI answer-mode-param), where answer-mode-value is 'Manual' / 'Auto' / token and answer-mode-param is 'require' / generic-param. Header field names and values are compared case-insensitively.