Calling Line Identification for Voice Mail Messages
Extracted elements (23)
Meta-data such as type of number and presentation restriction are intentionally excluded from these headers because this information is not presented to the called party on analog phone systems and is generally not available to voice mail systems.
New Caller-ID and Caller-Name header fields are introduced rather than manipulating the 'From' field because existing approaches (e.g., storing the number as an RFC 2822 address) require forced translation that loses fidelity. The goal is to store the calling party's information exactly as presented by the telephone system.
The Caller-Name field uses ASCII as its base character set because North American delivery to customer equipment requires ASCII per T1.401, and the 7-bit graphical characters of IRA, T.61, ASCII, and ISO 8859-1 are all coded the same way.
The RFC 2076 'phone' header was considered but rejected because it is listed as 'non-standard' and has no defined format, making the information unparsable. There was also no equivalent header for the originator's name.
International systems may encode the Caller-Name field using character set options (IRA, T.61, ISO 8859-1) not available on the receiving system, potentially resulting in an incorrect Caller Name being displayed to the recipient.
Some phone systems are known to truncate international numbers to 10 digits even though this behavior is undesirable. Implementors should be aware of this limitation, which can cause misinterpretation (e.g., an Irish number '353 91 73 3307' truncated to '53 91 73 3307' misread as a North American number).
These headers are intentionally distinct from addressable or dialable phone number formats defined in other documents (GSTN address per RFC 3191, telephone URL per RFC 2806). The Caller-ID field records the raw telephone number; translation to an addressable format is a separate concern.
When a Call Answer message is forwarded externally, an internal extension number may be inadvertently sent to an external recipient, giving wrong callback information and potentially exposing the company's internal dialing plan.
An optional NumberingPlan parameter MAY be used to indicate the semantic of the number in Caller-ID. If no numbering plan semantic is known, 'unknown' is the default.
For an international external call, the calling party's number MUST be the full international number per E.164 (CC + NDC + SN). Other information such as prefixes or the '+' symbol MUST NOT be included.
For delivery to customer equipment in North America, the calling name MUST be presented in ASCII per [T1.401].
If a caller name is received that cannot be represented in 7-bit ASCII, it MAY be stored using its native character set as defined in RFC 2047.
In telephone networks, the length of the Caller-Name field MUST NOT exceed 50 characters as defined in [T1.641]. Service providers may further limit this to 15 characters for delivery to customer equipment.
The date and time from the telephone system MAY be used in the existing Internet 'Date' header field. It is a local implementation decision whether the telephone-provided time or local system time is recorded.
The number field in Caller-ID MUST contain only the digits of the number and MUST be representable using ASCII; it must not include any separating characters such as hyphens.
An optional NumberingPlan parameter MAY be included with the Caller-ID field. Three defined semantics are: 'unknown' (default when absent), 'local' (meaningful only within the sending voice mail system's domain), and 'e164' (ITU-T E.164 international numbering). The 'x-' prefix may indicate enterprise or service-specific plans.
The Caller-ID header field holds sufficient information for the recipient's voice mail system to call back or reply to the sender. It contains the telephone number supplied by the telephone system, with digits only and no separating characters.
The Caller-Name header field stores the name of the person sending the voice mail message as presented by the telephone system. Characters are represented in ASCII, but non-ASCII names MAY be stored using their native character set as defined in RFC 2047.
This document defines an IANA-administered registration space for Caller-ID numbering plans. Initial entries are 'unknown', 'local', and 'e164'. New entries (ietf-token) may only be added via a standards-track RFC.
The mechanism explicitly places phone numbers in email headers used to store voice messages. Recipients may be unaware this information is present unless their client surfaces it. The intent is informational use analogous to caller ID display on a telephone screen.
Unlisted and restricted numbers are not a concern for these headers because the fields are defined to contain only what the called party would see (e.g., 'Private Name'), not the complete details exchanged between service providers.
Caller-ID syntax: '"Caller-ID" ":" 1*DIGIT [ "," "NumberingPlan=" ( "unknown" / "local" / "e164" / ietf-token / x-token ) ] CRLF'. Digits only, with an optional NumberingPlan parameter.
Caller-Name syntax: '"Caller-Name" ":" unstructured CRLF', using the 'unstructured' token from RFC 2822 defined as '*([FWS] utext) [FWS]'.