RFC 3939

Calling Line Identification for Voice Mail Messages

📅 published December 2004, from ietf

RFC 3939: Calling Line Identification for Voice Mail Messages 💖

Okay bestie, so this is RFC 3939 🎀, Calling Line Identification for Voice Mail Messages. It's from the Network Working Group (Request for Comments: 3939) and was written by G. Parsons and J. Maruszak at Nortel Networks in December 2004. It's a Standards Track doc, so it's a real Internet standards protocol, not just an idea someone had 🦋 ✨. Hold onto those facts, because the rest of the doc builds on them 💅.

Status of This Memo

Okay so this part is the legal-ish bit 🙈. The doc specifies an Internet standards track protocol for the Internet community, and it wants people to talk about it and suggest improvements 🫶. For the official standardization state and status of this protocol, you go check the current edition of the "Internet Official Protocol Standards" (STD 1) 📚. And the best part: distribution of this memo is unlimited 🌈.

Copyright (C) The Internet Society (2004). 💜

Abstract

Here's the big idea 🔥. This doc describes a way to identify the calling party who started a stored voice mail message, and it does it by putting the info in the message headers 💌. Two new header fields are defined for this: Caller_ID and Called_Name 🎀. Caller_id holds enough info for the recipient to call back or reply to the sender, and Caller-name tells you the name of the person who sent the message 🧚.

Table of Contents

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
2.  Conventions Used in this Document. . . . . . . . . . . . . . .  3
3.  Calling Line Identification Field. . . . . . . . . . . . . . .  3
    3.1.  Internal Call. . . . . . . . . . . . . . . . . . . . . .  4
    3.2.  External Call. . . . . . . . . . . . . . . . . . . . . .  4
    3.3.  Numbering Plan . . . . . . . . . . . . . . . . . . . . .  4
    3.4.  Date Header. . . . . . . . . . . . . . . . . . . . . . .  5
4.  Caller Name Field. . . . . . . . . . . . . . . . . . . . . . .  5
5.  Formal Syntax. . . . . . . . . . . . . . . . . . . . . . . . .  6
    5.1.  Calling Line Identification Syntax . . . . . . . . . . .  6
    5.2.  Caller Name Syntax . . . . . . . . . . . . . . . . . . .  6
    5.3.  Examples . . . . . . . . . . . . . . . . . . . . . . . .  6
6.  Other Considerations . . . . . . . . . . . . . . . . . . . . .  6
7.  Security Considerations. . . . . . . . . . . . . . . . . . . .  7
8.  IANA Considerations. . . . . . . . . . . . . . . . . . . . . .  7
9.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  8
    9.1.  Normative References . . . . . . . . . . . . . . . . . .  8
    9.2.  Informative References . . . . . . . . . . . . . . . . .  8
10. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . .  9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 11

1. Introduction ✨

So the problem is this 🙈. We need a way to figure out who originated a voice mail message, and it has to live outside the "FROM" header info 💅. The caller's phone number and name are usually available from the phone network, but there's no obvious header field to stash them in for an Internet Mail message 😭.

This info is meant for when the VPIM message format is used to store "Call Answer" voice messages in an Internet Mail message store 📬. Basically, the caller leaves a voice message because the recipient couldn't pick up 📞. That means there's no RFC 2822 address known for the originator 🥺.

[VPIMV2R2] suggests putting the originating number in as an Internet address, using the first method shown below. There are a few other ways to store this info, but they all mess with the "From" field 🌸. For example:

1. From: "416 555 1234" <non-mail-user@host>
2. From: "John Doe" <4165551234@host>
3. From:  unknown:;

Here's the tea ☕. Since any of these is a forced translation, it would be way more useful to store the calling party's name and number exactly as the telephone system presented them to the called party, with no manipulation 💖. That way the caller's info can show up for the recipient the same way it would on a phone 📱, and it still leaves room to figure out an Internet address for the originator later (if one exists) 🦋. Also, there's no requirement to store meta-data (e.g., type of number, presentation restricted), since the called party never sees that stuff and voice mail systems usually can't get it anyway 🙅‍♀️. The goal is to store whatever info is available from an analog (non-ISDN) phone (e.g., per [T1.401] in North America) 📞.

Now [RFC2076] lists "phone" as an Internet message header that would hold the originating party's telephone number, but it's marked "non-standard", which means using it isn't generally recommended 😬. It also has no defined format, so it's basically unparsable 💀. And there's no similar entry for the originator's name 😭.

So the proposal is to add two new message header fields for this info: the Calling Line Identification ("Caller-ID") and the Caller Name ("Caller-Name") 🎀✨.

2. Conventions Used in this Document 🧚

Here's the rulebook 📖. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, [RFC2119] 💅.

3. Calling Line Identification Field 📞

The Calling Line Identification header ("Caller-ID") holds enough info for the recipient's voice mail system to call back or reply to the sender of the message 🫶. The number in this header is supplied by the telephone system 📱. The exact format depends on the type of call, meaning whether it's internal or external 🔥.

Note that for both options, the number field MUST contain only the digits of the number, and it MUST be representable using the American Standard Code for Information Interchange [ASCII] character set 🙌. It doesn't include any separating character (e.g., "-") 🙅‍♀️.

It's expected that the default case, which is probably the most common one, won't have any numbering plan semantic associated with the number 💅. But if it is known, an optional "NumberingPlan" parameter MAY be used to indicate the semantic ✨.

3.1. Internal Call 🏢

For an internal call (e.g., between two extensions within the same company), it's enough to relay only the extension of the calling party, based on the company dialing plan 🎀.

That said, the enterprise phone system may support longer numbers too 🌈.

3.2. External Call 🌍

For an international call, the calling party's number must be the full international number as described in [E.164], which means Country Code (CC), National Destination Code (NDC), and Subscriber Number (SN) 🌏. Other info, like prefixes or symbols (e.g., "+"), MUST NOT be included 🚫. [E.164] allows for numbers of up to 15 digits 🔢.

For a call within North America, it's also suggested that 15 digits per [T1.625] be supported 💖. However, some service providers may only support 10 digits, as described in [T1.401] and [GR-31-CORE] 😩. It's desirable that an international number not get truncated to 10 digits if it has more than that 🙏. But it's recognized that limitations of various systems will cause this to happen anyway 💀.

Implementors of this specification should be aware that some phone systems are known to truncate international numbers, even though that behavior is undesirable 👀.

Note that the other defined fields available to non-analog systems (e.g., subaddress, redirecting number), as well as the meta-data, are not intended to be stored in this header 🙅‍♀️.

3.3. Numbering Plan 🔢

In this baseline case (i.e., analog lines), no numbering plan info is known or implied 📞. But if a numbering plan is known, an optional "NumberingPlan" parameter MAY be used to indicate the semantic 🎀. Only three semantics are defined: "unknown", "local", and "e164" 💅.

"unknown" is the default if no numbering plan semantic is known, and it's also the default if the parameter is absent 🤷‍♀️. "local" only has meaning within the domain of the voice mail system that stored the message, meaning the voice mail system knows the number belongs to a local numbering plan 🏠. "e164" means the number is as described in [E.164] 🌐.

And "x-" may be used to indicate enterprise or service specific dialing plans 🧚.

3.4. Date Header 📅

The date and time may be included by the telephone system along with the calling party's telephone number, per [T1.401] ⏰. This MAY be used, since there's already an existing "Date" Internet header to hold this info 🙌. Whether this time or the local system time gets recorded in the "Date" header is a local implementation decision 🫶.

4. Caller Name Field 💌

The name of the person sending the message is also important 💖. Info about whether the call is internal or external may be included if it's available 🏢🌍. This info may not be available on international calls 🌏.

The exact format for this field is typically a service provider option, per [T1.641] 🎀. The caller's name can be sent in one of several character sets, depending on the service provider signaling transport (e.g., ISDN-UP, SCCP, TCAP) 📡. These include:

  1. International Reference Alphabet (IRA), formerly know as International Alphabet No.5 or IA5 [T.50]
  2. Latin Alphabet No. 1 [8859-1]
  3. American National Standard Code for Information Interchange [ASCII]
  4. Character Sets for the International Teletex Service [T.61]

Of these, the IRA and T.61 character sets have a bunch of options that help specify national and application oriented versions 🌈. If the parties don't agree to use these options, then the 7-bit character set is assumed, where the graphical characters of IRA, T.61, and ASCII are coded exactly the same 🔤. Also, the 7-bit graphical characters of [8859-1] are the same as in [ASCII] ✨.

Note that for delivery to customer equipment in North America, the calling name MUST be presented in ASCII, per [T1.401] 🇺🇸. So for the caller name header defined in this document, characters are represented with ASCII characters 💅. But if a name comes in that can't be represented in 7-bit ASCII, it MAY be stored using its native character set, as defined in [RFC2047] 🌸.

In telephone networks, the length of the name field MUST NOT exceed 50 characters, as defined in [T1.641] 🙅‍♀️. Service providers may choose to limit this further to 15 characters for delivery to customer equipment, e.g., [T1.401] and [GR-1188-CORE] 😮‍💨.

5. Formal Syntax 🧬

Both Calling Line Identification and Caller Name follow the syntax specification using the augmented Backus-Naur Form (BNF) as described in [RFC2234] 💖. While the semantics of these headers are defined in sections 4 and 5, the syntax uses the 'unstructured' token defined in [RFC2822] ✨:

unstructured = *([FWS] utext) [FWS]

5.1. Calling Line Identification Syntax 🎀

"Caller-ID" ":" 1*DIGIT [ "," "NumberingPlan="
( "unknown" / "local" / "e164" / ietf-token / x-token ) ] CRLF

  ietf-token := <An extension token defined by a
                 standards-track RFC and registered
                 with IANA.>

  x-token := <The two characters "X-" or "x-" followed, with
              no intervening white space, by any token>

5.2. Caller Name Syntax 💌

"Caller-Name" ":" unstructured CRLF

5.3. Examples 🦋

To: +19725551212@vm1.example.com
Caller-ID: 6137684087
Caller-Name: Derrick Dunne

To: 6137637582@example.com
Caller-ID: 6139416900
Caller-Name: Jean Chretien

6. Other Considerations ✨

6.1. Compatibility with Other Internet Phone Numbers

okay so these headers are all about recording the phone number exactly as the analog phone system hands it over with an incoming call, no changes, no guessing 📞💖 if enough meaning is known (or can be figured out), that can go in the NumberingPlan field 🧚 which may later help turn it into a number you can actually dial. just to be clear, this doc does NOT define dialable phone numbers. those live in other specs, like the GSTN address [RFC3191] or the telephone URL [RFC2806] 🎀

6.2. Usage

there are a few ways this can go sideways 😭 the first one we already brought up in section 3.2: an international number getting chopped down to 10 digits. like, an Irish number of the form "353 91 73 3307" could get truncated to "53 91 73 3307" when it lands in North America, and then it reads as "539 917 3307", which looks totally North American 💀 so the person getting the message has the wrong info to call back, and the poor North American callee might be lowkey annoyed 🙈

the second scenario is when a Call Answer message gets forwarded and an internal extension ends up going to an external recipient 🦋 that's two problems at once: the recipient gets a wrong phone number, AND the company's dialing plan could get exposed. no thank you 🙅‍♀️

last one is about character options in the Caller Name field. a system overseas might send a message using coding options the receiving system doesn't support, and then the recipient sees an incorrect Caller Name 💅

7. Security Considerations 🔐

okay so unlisted and restricted numbers aren't a concern here 💁‍♀️ these header fields are built to hold what the called party would actually see (like 'Private Name'), not the full details that get swapped between service providers.

BUT. this mechanism lets phone numbers be shown explicitly in the headers of an email message (the kind used to store voice messages) 😳 section 1 covers why that's okay, but the recipient might not even know the info is sitting in the headers unless their client shows it to them. the whole point is that it's informative, the same way it'd look on a phone screen ✨

8. IANA Considerations 📋

this doc sets up an IANA-administered registration space for Caller-ID numbering plans, described in section 5.1 🌸 every registry entry is an identifying token plus a short description. there are three starter entries in this registry:

unknown - The number's semantics are unknown.  This value is the
          default in the absence of this parameter.

local   - The number only has meaning within the domain of the
          sending system identified by the RFC 2822 From field of
          the message.

e164    - The number's semantics are described in [E.164].

the only way to add more entries (ietf-token in section 5.1) to this registry is with a standards-track RFC 🔥 so no sneaking new ones in!

9. References 📚

9.1. Normative References

[VPIMV2R2]     Vaudreuil, G. and G. Parsons, "Voice Profile for
               Internet Mail - version 2 (VPIMv2)", RFC 3801, June
               2004.

[RFC2047]      Moore, K., "MIME (Multipurpose Internet Mail
               Extensions) Part Three: Message Header Extensions for
               Non-ASCII Text ", RFC 2047, November 1996.

[RFC2822]      Resnick, P., "Internet Message Format", RFC 2822,
               April 2001.

[RFC2234]      Crocker, D. and P. Overell, "Augmented BNF for Syntax
               Specifications: ABNF", RFC 2234, November 1997.

[RFC2119]      Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.

9.2. Informative References

[RFC2076]      Palme, J., "Common Internet Message Headers", RFC
               2076, February 1997.

[E.164]        ITU-T Recommendation E.164 (1997), "The international
               public telecommunication numbering plan"

[T.50]         ITU-T Recommendation T.50 (1992), "International
               Reference Alphabet (IRA)"

[T.61]         CCITT Recommendation T.61 (1988) (Withdrawn),
               "Character Repertoire and Coded Character Sets for the
               International Teletex Service"

[8859-1]       ISO/IEC International Standard 8859-1 (1998),
               Information Technology _ 8-bit single-byte coded
               graphic character sets _ Part 1: Latin Alphabet No. 1

[ASCII]        American National Standards Institute (ANSI), Coded
               Character Set - 7-Bit American National Standard Code
               for Information Interchange, ANSI X3.4, 1986.

[T1.401]       American National Standards Institute (ANSI),
               Telecommunications _ Network-to-Customer Installation
               Interfaces _ Analog Voicegrade Switched Access Lines
               with Calling Number Delivery, Calling Name Delivery,
               or Visual Message-Waiting Indicator Features, ANSI
               T1.6401.03-1998

[T1.625]       American National Standards Institute (ANSI),
               Telecommunications - Integrated Services Digital
               Network (ISDN) _ Calling Line identification
               Presentation and Restriction Supplementary Services,
               ANSI T1.625-1993

[T1.641]       American National Standards Institute (ANSI),
               Telecommunications - Calling Name Identification
               Presentation, ANSI T1.641-1995

[GR-1188-CORE] Telcordia Technologies, "CLASS Feature: Calling Name
               Delivery Generic Requirements", GR-1188-CORE, Issue 2,
               December 2000

[GR-31-CORE]   Telcordia Technologies, "CLASS Feature: Calling Number
               Delivery", GR-31-CORE, Issue 1, June 2000

[RFC3191]      Allocchio, C., "Minimal GSTN address format in
               Internet Mail", RFC 3191, October 2001.

[RFC2806]      Vaha-Sipila, A., "URLs for Telephone Calls", RFC 2806,
               April 2000.

10. Acknowledgments 🫶

the previous authors of this doc were Derrick Dunne and Jason Collins 💜 the current authors want to say a huge thank you to Derrick and Jason for all their contributions, they really set the foundation ✨

Authors' Addresses

Glenn Parsons
Nortel Networks
P.O. Box 3511, Station C
Ottawa, ON K1Y 4H7

Phone: +1-613-763-7582
EMail: gparsons@nortelnetworks.com


Janusz Maruszak

Phone: +1-416-885-0221
EMail: jjmaruszak@sympatico.ca

Copyright (C) The Internet Society (2004). 🎀

this document is subject to the rights, licenses and restrictions in BCP 78, and except as set forth there, the authors keep all their rights.

this document and the information in it are provided on an "AS IS" basis, and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property 🧠

the IETF takes no position on the validity or scope of any Intellectual Property Rights or other rights that might be claimed to apply to the technology in this document, or on whether any license under those rights might be available. it also doesn't claim to have done any independent work to find such rights. info on the IETF's procedures for rights in IETF Documents is in BCP 78 and BCP 79 📖

copies of IPR disclosures sent to the IETF Secretariat, any assurances of licenses, and the results of any attempt to get a general license or permission for implementers or users of this spec can be found in the IETF on-line IPR repository at http://www.ietf.org/ipr.

the IETF invites any interested party to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that may cover technology needed to implement this standard. send that info to the IETF at ietf-ipr@ietf.org 💌

Acknowledgement 💖

funding for the RFC Editor function is currently provided by the Internet Society 🌈

📦 where this page comes from