Rejecting Anonymous Requests in the Session Initiation Protocol (SIP)
Extracted elements (15)
Display names make a poor mechanism for indicating anonymity because they are meant for human consumption, not automata; language variations and misspellings can cause an automaton to miss the hint. Nevertheless, RFC 3261 explicitly designated the display name as a way to declare anonymity, so a check on it is included.
The closest existing response code, 403 (Forbidden), does not convey a specific reason for rejection and cannot be interpreted programmatically or by callers speaking different languages. A machine-readable indication enables programmatic handling, UI prompts, and conversion to PSTN error codes in gateways.
A UAC that does not understand or care about the specific semantics of the 433 response will treat it as a 400 (Bad Request) response, in accordance with RFC 3261's response code class rules.
A request SHOULD be considered anonymous when the identity of the originator has been explicitly withheld, including when the From header contains a URI in the anonymous.invalid domain, a display name of 'Anonymous' or 'anonymous', or a Privacy header with value 'id' or 'user'.
A server MAY generate a 433 (Anonymity Disallowed) response when it receives an anonymous request and refuses to fulfill it because the requestor is anonymous.
A UAC receiving a 433 (Anonymity Disallowed) MUST NOT retry the request without anonymity unless it obtains confirmation from the user (via UI or user-defined policy) that retrying without anonymity is desirable.
If a request contains a non-anonymous From header along with Identity and Identity-Info header fields but the certificate could not be obtained, it is not considered anonymous and the 433 response code SHOULD NOT be used.
If the user has confirmed it is desirable, a UAC MAY retry the request without requesting anonymity after receiving a 433 response.
Lack of a network-asserted identity (such as the P-Asserted-Identity header field), in and of itself, SHOULD NOT be considered an indication of anonymity, because there is no way to differentiate removal of a network-asserted identity from a domain that never supported it.
Receipt of a 433 response to a mid-dialog request SHOULD NOT cause the dialog to terminate and SHOULD NOT cause the specific usage of that dialog to terminate.
When an anonymizer function acting as a B2BUA receives a 433 response, it MUST NOT retry the request without anonymization unless explicitly configured by the user to do so, applying the same rules as a UA processing a 433.
The 433 (Anonymity Disallowed) response code indicates that the server refused to fulfill the request because the requestor was anonymous. Its default reason phrase is "Anonymity Disallowed".
IANA registered response code 433 with default reason phrase "Anonymity Disallowed" in the SIP response code registry per the procedures of RFC 3261.
Sending a 433 response reveals information about the called party — specifically that they do not accept anonymous calls. If this information is sensitive, a UAS SHOULD reject the request with a 403 (Forbidden) instead.
The 433 response code is likely ineffective at blocking SIP-based spam because a malicious caller can include a From header that is not anonymous but is meaningless and invalid, bypassing anonymity screening without a Privacy header field.