summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3939.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3939.txt')
-rw-r--r--doc/rfc/rfc3939.txt619
1 files changed, 619 insertions, 0 deletions
diff --git a/doc/rfc/rfc3939.txt b/doc/rfc/rfc3939.txt
new file mode 100644
index 0000000..ff04931
--- /dev/null
+++ b/doc/rfc/rfc3939.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Network Working Group G. Parsons
+Request for Comments: 3939 J. Maruszak
+Category: Standards Track Nortel Networks
+ December 2004
+
+
+ Calling Line Identification for Voice Mail Messages
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2004).
+
+Abstract
+
+ This document describes a method for identifying the originating
+ calling party in the headers of a stored voice mail message. Two new
+ header fields are defined for this purpose: Caller_ID and
+ Called_Name. Caller_id is used to store sufficient information for
+ the recipient to callback, or reply to, the sender of the message.
+ Caller-name provides the name of the person sending the message.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Parsons & Maruszak Standards Track [Page 1]
+
+RFC 3939 Calling Line Identification December 2004
+
+
+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
+
+ There is currently a need for a mechanism to identify the originating
+ party of a voice mail message, outside of the "FROM" header
+ information. The telephone number and name of the caller are
+ typically available from the telephone network, but there is no
+ obvious header field to store this in an Internet Mail message.
+
+ This information is intended for use when the VPIM message format is
+ used for storing "Call Answer" voice messages in an Internet Mail
+ message store, i.e., the calling party leaves a voice message for the
+ recipient, who was unable to answer the call. The implication is
+ that there is no RFC 2822 address known for the originator.
+
+ [VPIMV2R2] suggests the originating number be included as an Internet
+ address, using the first method shown below. There are several other
+ ways to store this information, but they all involve some
+ manipulation of the "From" field. For example:
+
+ 1. From: "416 555 1234" <non-mail-user@host>
+ 2. From: "John Doe" <4165551234@host>
+ 3. From: unknown:;
+
+
+
+
+
+Parsons & Maruszak Standards Track [Page 2]
+
+RFC 3939 Calling Line Identification December 2004
+
+
+ Since any of these is a forced translation, it would be useful to
+ store the calling party's name and number as presented by the
+ telephone system to the called party without manipulation. This
+ would allow the calling party's information to be displayed to the
+ recipient (similar to it appearing on the telephone) and also allow
+ future determination of an Internet address for the originator (if
+ one exists). Note that there is no requirement to store meta-data
+ (e.g., type of number, presentation restricted), as this information
+ is not presented to the called party and is generally not available
+ to voice mail systems. The intent is to store the available
+ information to an analog (non-ISDN) phone (e.g., per [T1.401] in
+ North America).
+
+ [RFC2076] currently lists "phone" as an Internet message header which
+ would hold the originating party's telephone number, but it is listed
+ as "non-standard", i.e., usage of this header is not generally
+ recommended. It also has no defined format, making the information
+ unparsable. There is no similar entry for the originator's name.
+
+ It is proposed that two new message header fields be included to hold
+ this information, namely the Calling Line Identification ("Caller-
+ ID") and Caller Name ("Caller-Name").
+
+2. Conventions Used in this Document
+
+ 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 sufficient
+ information for the recipient's voice mail system to call back, or
+ reply to, the sender of the message. The number that is contained in
+ this header is supplied by the telephone system. The exact format of
+ the data received depends on the type of call, that is -- internal or
+ external call.
+
+ Note that for both options, the number field MUST contain only the
+ digits of the number and MUST be representable using the American
+ Standard Code for Information Interchange [ASCII] character set; it
+ does not include any separating character (e.g., "-").
+
+ It is expected that default, likely to be the most common case, will
+ not have any numbering plan semantic associated with the number.
+ However, in the case that it is known, an optional "NumberingPlan"
+ parameter MAY be used to indicate the semantic.
+
+
+
+
+Parsons & Maruszak Standards Track [Page 3]
+
+RFC 3939 Calling Line Identification December 2004
+
+
+3.1. Internal Call
+
+ For an internal call (e.g., between two extensions within the same
+ company), it is sufficient to relay only the extension of the calling
+ party, based on the company dialing plan.
+
+ However, the support of longer numbers may be supported by the
+ enterprise phone system.
+
+3.2. External Call
+
+ For an international call, the calling party's number must be the
+ full international number as described in [E.164], i.e., Country Code
+ (CC), National Destination Code (NDC), and Subscriber Number (SN).
+ Other information, such as 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 is 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]. Though
+ it is desirable that an international number not be truncated to 10
+ digits if it contains more, it is recognized that limitations of
+ various systems will cause this to happen.
+
+ Implementors of this specification should be aware that some phone
+ systems are known to truncate international numbers, even though this
+ 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
+ information is known or implied. However, in the case that 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 the default if the parameter is
+ absent). "local" has meaning only within the domain of the voice
+ mail system that stored the message (i.e., the voice mail system
+ knows that the number belongs to a local numbering plan). "e164"
+ indicates that the number is as described in [E.164]. "x-" may be
+ used to indicate enterprise or service specific dialing plans.
+
+
+
+
+
+
+Parsons & Maruszak Standards Track [Page 4]
+
+RFC 3939 Calling Line Identification December 2004
+
+
+3.4. Date Header
+
+ The date and time may be included by the telephone system with the
+ calling party's telephone number per [T1.401]. This MAY be used, as
+ there is an existing "Date" Internet header to hold this information.
+ It is a local implementation decision whether this time or the local
+ system time will be recorded in the "Date" header.
+
+4. Caller Name Field
+
+ The name of the person sending the message is also important.
+ Information about whether the call is internal or external may be
+ included if it is available. This information may not be available
+ on international calls.
+
+ Further, the exact format for this field is typically a service
+ provider option per [T1.641]. It is possible for the caller's name
+ to 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 contain a number of options
+ that help specify national and application oriented versions. If
+ there is no agreement between parties to use these options, then the
+ 7-bit character set in which the graphical characters of IRA, T.61,
+ and ASCII are coded exactly the same, will be assumed. Further, 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].
+
+ As a result, for the caller name header defined in this document,
+ characters are represented with ASCII characters. However, if a name
+ is received that cannot 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]. However, service providers
+ may choose to further limit this to 15 characters for delivery to
+ customer equipment, e.g., [T1.401] and [GR-1188-CORE].
+
+
+
+
+Parsons & Maruszak Standards Track [Page 5]
+
+RFC 3939 Calling Line Identification December 2004
+
+
+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
+
+ The intent of these headers are to record telephone number that is
+ sent by the analog phone system with an incoming call without
+ alteration or interpretation. If sufficient semantic is known or can
+ be inferred, this may be included in the NumberingPlan field. This
+ may allow it to be later translated into an addressable phone number.
+ Addressable or dialable phone numbers (which this document does not
+ define) are defined in other documents, such as GSTN address
+ [RFC3191] or telephone URL [RFC2806].
+
+
+
+Parsons & Maruszak Standards Track [Page 6]
+
+RFC 3939 Calling Line Identification December 2004
+
+
+6.2. Usage
+
+ There are a few scenarios of how this mechanism may fail that must be
+ considered. The first is mentioned in section 3.2 - the truncation
+ of an international number to 10 digits. This could result in a
+ misinterpretation of the resulting number. For instance, an
+ international number (e.g., from Ireland) of the form "353 91 73
+ 3307" could be truncated to "53 91 73 3307" if received in North
+ America, and interpreted as "539 917 3307" - a seemingly "North
+ American" style number. Thus, the recipient is left with incorrect
+ information to reply to the message, possibly with an annoyed callee
+ at the North American number.
+
+ The second scenario is the possibility of sending an internal
+ extension to an external recipient when a Call Answer message is
+ forwarded. This poses two problems, the recipient is given the wrong
+ phone number, and the company's dialing plan could be exposed.
+
+ The final concern deals with exercising character options that are
+ available in coding the Calling Name field. An international system
+ may send a message with coding options that are not available on the
+ receiving system, thus giving the recipient an incorrect Caller Name.
+
+7. Security Considerations
+
+ Note that unlisted and restricted numbers are not a concern as these
+ header fields are defined to contain what the called party would see
+ (e.g., 'Private Name'), as opposed to the complete details exchanged
+ between service providers.
+
+ However, it must also be noted that this mechanism allows the
+ explicit indication of phone numbers in the headers of an email
+ message (used to store voice messages). While the rationale for this
+ is reviewed in section 1, the recipient of this message may not be
+ aware that this information is contained in the headers unless the
+ user's client presents the information. Its use is intended to be
+ informative as it is when it appears on a telephone screen.
+
+8. IANA Considerations
+
+ This document defines an IANA-administered registration space for
+ Caller-ID numbering plans in section 5.1. Each registry entry
+ consists of an identifying token and a short textual description of
+ the entry. There are three initial entries in this registry:
+
+ unknown - The number's semantics are unknown. This value is the
+ default in the absence of this parameter.
+
+
+
+
+Parsons & Maruszak Standards Track [Page 7]
+
+RFC 3939 Calling Line Identification December 2004
+
+
+ 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 additional entries (ietf-token in section 5.1) to
+ this registry is with a standards-track RFC.
+
+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"
+
+
+
+
+
+
+
+Parsons & Maruszak Standards Track [Page 8]
+
+RFC 3939 Calling Line Identification December 2004
+
+
+ [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 versions of this document were Derrick Dunne
+ and Jason Collins. The current authors would like to thank Derrick
+ and Jason for their contributions.
+
+
+
+
+
+
+
+
+Parsons & Maruszak Standards Track [Page 9]
+
+RFC 3939 Calling Line Identification December 2004
+
+
+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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Parsons & Maruszak Standards Track [Page 10]
+
+RFC 3939 Calling Line Identification December 2004
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2004).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein 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 regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the IETF's procedures with respect to rights in IETF Documents can
+ be found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from 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 or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at ietf-
+ ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+Parsons & Maruszak Standards Track [Page 11]
+