A Session Initiation Protocol (SIP) Response Code for Rejected Calls
Extracted elements (29)
608 is distinct from 607 (Unwanted) because 607 indicates a human user rejected the call, while 608 indicates a machine or algorithm did so. In some jurisdictions this distinction is legally significant, and downstream analytics engines must be able to weight these differently rather than treating an algorithmic rejection as a human rejection.
jCard (RFC 7095) is used rather than vCard (RFC 6350) for the remediation contact because jCard is JSON-encoded and can be integrity-protected via JSON Web Signature (JWS), following the same pattern as STIR (RFC 8224). Signing is essential to prevent malicious intermediaries from inserting phishing contact information.
Legacy non-SIP callers (e.g., PSTN callers via a media gateway) cannot process 608 response codes or Call-Info headers. The first SIP network element that conforms with this specification (e.g., an SBC) takes responsibility for inserting sip.608 and playing an audio or text announcement conveying the remediation contact information to the legacy caller.
SIP proxies that do not understand sip.608 will pass 'Feature-Caps: *;+sip.608' header fields unmodified per Section 16.6 of RFC 3261, allowing them to participate transparently in a network offering 608 services without upgrade.
A network element that inserts the sip.608 feature capability MUST be able to convey at minimum how to contact the operator of the intermediary that rejected the call, and MUST forward the 608 response code as the final response to the INVITE even if it has played an announcement.
A UAC conforming to this specification MUST include the sip.608 feature-capability indicator in the Feature-Caps header field of the INVITE request.
An intermediary MAY issue the 608 response code in a failure response for an INVITE, MESSAGE, SUBSCRIBE, or other out-of-dialog SIP request to indicate that an intermediary rejected the offered communication as unwanted by the user.
For legacy interoperation, the network element conveying the announcement MUST use the 183 Session Progress response to establish the media session. The UAC MUST include support for 100rel (RFC 3262) in its INVITE, the network element MUST Require 100rel in the 183, and the UAC MUST issue a PRACK to which the network element MUST respond 200 OK PRACK.
If an intermediary encodes per-call information in the URI returned in a 608 response, it MUST use a non-deterministic URI reference mechanism and MUST be prepared to return dummy responses to URI requests referencing calls that do not exist, to prevent attackers from gleaning call metadata by guessing URIs.
If an intermediary issues a 608 code and there are no indicators the calling party will use the contents of the Call-Info header field for malicious purposes, the intermediary MUST include a Call-Info header field in the response.
If there is a Call-Info header field in a 608 response, it MUST have the 'purpose' parameter set to 'jwscard', and its value MUST refer to a valid JSON Web Signature (JWS) encoding of a jCard object.
Implementations MUST NOT insert line breaks into the base64url encodings of the JOSE header or JWT, and UACs MUST be prepared to receive arbitrarily long octet streams from the URI referenced by the Call-Info header field.
Implementations MUST support ES256 as defined in JSON Web Algorithms (JWA, RFC 7518) and MAY support other registered signature algorithms.
The jcard claim MUST include at least one of the URL, EMAIL, TEL, or ADR properties so that the calling UAC can contact the intermediary to appeal an erroneous block.
The JOSE header of the JWS MUST include the typ, alg, and x5u parameters. The typ parameter MUST have the value 'vcard+json', and x5u MUST be a URI that resolves to the public key certificate corresponding to the signing key.
The JWT payload MUST contain an 'iat' (issued at) claim set to the date and time of the issuance of the 608 response, and MUST contain a 'jcard' claim whose value is a JSON array conforming to the jCard data format (RFC 7095).
Upon receiving a 608 response, the UAC MUST check the 'iat' claim in the JWT and MUST reject jCards with an expired 'iat'. A reasonable expiry window is on the order of one minute to account for clock drift and audio announcement delays.
608 (Rejected) is a new SIP 6xx response code indicating that an intermediary (not the end user) rejected a call attempt. As a 6xx response, it signals to the caller that future attempts to the same UAS will likely fail.
The sip.608 feature-capability indicator is inserted in the Feature-Caps header field of an INVITE request to signal that the inserting entity will be responsible for conveying information from a 608 SIP response (specifically the Call-Info referenced content) to the caller, including legacy devices.
This document registers SIP response code 608 with description 'Rejected' in the 'Response Codes' subregistry of the 'Session Initiation Protocol (SIP) Parameters' registry defined in RFC 3261.
This document registers the JWT claim name 'jcard' with claim description 'jCard data' in the 'JSON Web Token Claims' subregistry created by RFC 7519. The syntax is defined in Section 3.2.2.
This document registers the predefined value 'jwscard' for the 'purpose' header field parameter of the Call-Info header field in the 'Header Field Parameters and Parameter Values' subregistry of the SIP Parameters registry.
This document registers the SIP feature-capability indicator 'sip.608' in the 'SIP Feature-Capability Indicator Registration Tree' registry defined in RFC 6809, indicating the inserting entity will convey 608 Call-Info content to the caller.
A 608-aware gateway that plays an audio announcement can be used as an amplification attack vector: an attacker crafts a small INVITE with an SDP pointing to a victim device, causing the gateway to send a large audio file to the victim. Mitigation is to only play media in response to STIR-validated INVITEs and/or perform ICE connectivity checks (RFC 8445).
A malicious actor could spoof 608 responses with a victim's contact address to many UACs simultaneously, causing a denial-of-service flood against the victim. The JWS signature allows UACs to verify the blocking intermediary's identity before contacting the redress address, guarding against this spoofing attack.
A malicious intermediary could insert a jCard with phishing contact information (e.g., a TEL or URL pointing to a social-engineering operation). JWS signing of the jCard provides integrity protection and cryptographic traceability to the signing entity, allowing UACs to validate the source before contacting the redress address.
Providing a Call-Info redress address in a 608 response to a truly malicious caller gives them a vector to attack the intermediary operator. Intermediary operators SHOULD only include Call-Info for INVITE requests that pass STIR (RFC 8224) validation to reduce the risk of arming malicious callers.
The Call-Info header field in a 608 response carries a URI pointing to a JWS-encoded jCard. It uses a 'purpose' parameter value of 'jwscard'. The JWS structure is: base64url(JOSE header) || '.' || base64url(JWT payload) || '.' || base64url(signature), with no line breaks.
The JWT payload contains two claims: 'iat' (integer Unix timestamp of 608 issuance) and 'jcard' (a JSON array in jCard format, RFC 7095, including at least one of URL, EMAIL, TEL, or ADR properties for remediation contact).