summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3601.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3601.txt')
-rw-r--r--doc/rfc/rfc3601.txt563
1 files changed, 563 insertions, 0 deletions
diff --git a/doc/rfc/rfc3601.txt b/doc/rfc/rfc3601.txt
new file mode 100644
index 0000000..61432dc
--- /dev/null
+++ b/doc/rfc/rfc3601.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Network Working Group C. Allocchio
+Request for Comments: 3601 GARR-Italy
+Category: Standards Track September 2003
+
+
+ Text String Notation for Dial Sequences and
+ Global Switched Telephone Network (GSTN) / E.164 Addresses
+
+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 (2003). All Rights Reserved.
+
+Abstract
+
+ This memo describes the full set of notations needed to represent a
+ text string in a Dial Sequence. A Dial Sequence is normally composed
+ of Dual Tone Multi Frequency (DTMF) elements, plus separators and
+ additional "actions" (such as "wait for dialtone", "pause for N
+ secs", etc.) which could be needed to successfully establish the
+ connection with the target service: this includes the cases where
+ subaddresses or DTMF menu navigation apply.
+
+1. Introduction
+
+ Since the very first devices interacting with GSTN services appeared,
+ a need for a unique text string representation of commonly called
+ telephone numbers, and more generally DTMF sequences and actions, was
+ foreseen.
+
+ This memo describes the full text string representation method. This
+ specification was explicitly created to provide an easy, unique and
+ complete reference which MUST be used by all other specifications
+ needing a text string representation for a Dial Sequence.
+
+ The specification was collected directly from Dial Sequence
+ definitions which are already described in existing Standard Track
+ specifications (such as [6] [7] [8] [9]), and is fully synchronized
+ with them. Full compatibility is thus assured, and as a consequence,
+ this specification results in a compendium of existing definitions.
+
+
+
+
+Allocchio Standards Track [Page 1]
+
+RFC 3601 Dial Sequences and GSTN / E.164 Addresses September 2003
+
+
+ This notation is a fully compatible compendium of existing notations,
+ and should be used in all specifications needing a text string
+ representation of a Dial Sequence.
+
+ Although the commonly called "telephone numbers" are normally used to
+ generate a Dial Sequence when establishing a connection, the full
+ abstract E.164 addresses [2], i.e., the universal addressing on the
+ Global Switched Telephone Network (GSTN), have further elements which
+ cannot be dialled. Thus abstract E.164 addresses cannot be fully
+ converted into a Dial Sequence or fully represented using this
+ notation.
+
+1.1. Terminology and Syntax conventions
+
+ In this document the formal definitions are described using ABNF
+ syntax, as defined in [3]. This memo also uses some of the "CORE
+ DEFINITIONS" defined in "APPENDIX A - CORE" of that 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, RFC 2119 [4].
+
+ The following terms are also defined in this document:
+
+ Dial Sequence:
+ a series of DTMF elements and human or device "actions";
+
+ phone-string:
+ a text representation of a Dial Sequence;
+
+ GSTN address: a commonly called "telephone number" on the GSTN,
+ i.e., a diallable subset of an E.164 abstract address or any
+ private numbering schema diallable address;
+
+ gstn-phone:
+ a text representation of a GSTN address;
+
+ subaddr-string:
+ a text representation of a GSTN subaddress (which includes ISDN
+ subaddresses [2] and T.33 subaddresses [5]);
+
+ post-dial:
+ a text representation of a post dialling sequence.
+
+
+
+
+
+
+
+
+Allocchio Standards Track [Page 2]
+
+RFC 3601 Dial Sequences and GSTN / E.164 Addresses September 2003
+
+
+2. The "Dial Sequence" definition
+
+ The possible elements composing a Dial Sequence can vary from a
+ minimum number, up to a really large and complex collection: in fact,
+ the sequences already needed to dial a gstn-phone, which is a subset
+ of the generic Dial Sequence, well represents this variety and
+ complexity of cases.
+
+ In particular, a Dial Sequence is composed by:
+
+ - "DTMF elements": normally available as "keys" on numeric keypads
+ of dialling devices;
+
+ - "actions": normally performed by the agent (human or device)
+ composing the Dial Sequence;
+
+ - "separators": used only to improve human readability of a Dial
+ Sequence.
+
+2.1. The "phone-string" definition
+
+ The text representation of the Dial Sequence elements is defined in
+ the phone-string specification:
+
+ phone-string = 1*( DTMF / pause / tonewait / written-sep )
+
+ DTMF = ( DIGIT / "#" / "*" / "A" / "B" / "C" / "D" )
+ ; special DTMF codes like "*", "#", "A", "B",
+ ; "C", "D" are defined in [1].
+ ; Important Note: these elements only apply for
+ ; alphabetic strings used in DTMF operations.
+ ; They are NOT applicable for the alphabetic
+ ; characters that are mapped to digits on phone
+ ; keypads in some countries.
+
+ pause = "p"
+
+ tonewait = "w"
+
+ written-sep = ( "-" / "." )
+
+ Note:
+ DTMF are the "DTMF elements", pause and tonewait are the "actions"
+ and written-sep are the "separators".
+
+ The "pause" and "tonewait" elements interpretation of the phone-
+ string depends on the specific devices and implementation using the
+ specification. Thus their exact meaning is not mandated in this
+
+
+
+Allocchio Standards Track [Page 3]
+
+RFC 3601 Dial Sequences and GSTN / E.164 Addresses September 2003
+
+
+ document. The next section provides some examples drawn from common
+ practice. Both "pause" and "tonewait" are case insensitive.
+
+ Implementation of "pause" and "tonewait":
+
+ - one instance of a "pause" SHOULD be interpreted as a pause of
+ one second between the preceding and succeeding dial string
+ elements;
+
+ - a "tonewait" SHOULD be interpreted as a pause that will last
+ until the calling party hears a dial tone or another indication
+ that more dial string characters may be processed. An off-hook
+ indication MAY also be interpreted as this kind of indication
+ (meaning that the audio channel has been opened to the
+ receiving party);
+
+ - because these characters are not a part of the GSTN subscriber
+ address (telephone number) per se, any dial string characters
+ that succeed either a "pause" or "tonewait" SHOULD be sent
+ using DTMF signalling.
+
+ The use of written-sep elements is allowed in order to improve human
+ readability of the phone-string. The written-sep are elements which
+ can be placed between dial elements, such as digits etc. Any
+ occurrences of written-sep elements in a phone-string MUST NOT result
+ in any action. Conformant implementations MAY drop or insert
+ written-sep into the phone-string they handle.
+
+ The phone-string definition is used in the following sections to
+ explicitly describe the encoding of some specific subcases where it
+ applies.
+
+3. The "gstn-phone" definition
+
+ In order to access a GSTN address, a human or a device must perform a
+ Dial Sequence. Thus, a GSTN address can be represented using the
+ phone-string elements. In particular, diallable E.164 numeric
+ addresses [2] represent a limited subset of all possible GSTN
+ addresses, while the complete complex case needs a full encoding
+ schema, as it also includes a local or private addressing schema.
+
+ In order to describe this distinction and provide anyhow a complete
+ encoding schema, the following definition of "gstn-phone" is
+ provided:
+
+ gstn-phone = ( global-phone / local-phone )
+
+
+
+
+
+Allocchio Standards Track [Page 4]
+
+RFC 3601 Dial Sequences and GSTN / E.164 Addresses September 2003
+
+
+3.1. The "global-phone" definition
+
+ The purpose of the global-phone element is to represent diallable
+ E.164 numeric addresses. As such, it uses a subset of a phone-string
+ definition only.
+
+ The syntax for a global-phone element is as follows:
+
+ global-phone = "+" 1*( DIGIT / written-sep )
+
+ Any other dialling schemes MUST NOT use the leading "+" defined here.
+ The "+" sign is strictly reserved for the standard "global-phone"
+ syntax, and, even if not specifically part of the phone-string
+ definition, it is needed to uniquely label a global-phone.
+
+3.2. The "local-phone" definition
+
+ The local-phone element is intended to represent the set of possible
+ cases where the global-phone numbering schema does not apply. Given
+ the different and complex conventions currently being used in the
+ GSTN system, the local-phone definition supports a large number of
+ elements.
+
+ The detailed syntax for local-phone elements is as follows:
+
+ local-phone = [ exit-code ] dial-number
+
+ local-phone =/ exit-code [ dial-number ]
+
+ exit-code = phone-string
+ ; this will include elements such as the digit to
+ ; access outside line, the long distance carrier
+ ; access code, the access password to the service,
+ ; etc...
+
+ dial-number = phone-string
+ ; this is in many cases composed of different elements
+ ; such as the local phone number, the area code
+ ; (if needed), the international country code
+ ; (if needed), etc...
+
+ Notes:
+ The "+" character is reserved for use in a global-phone and MUST
+ NOT be used in a local-phone string;
+
+ Please note that a local-phone string MUST NOT be a null string,
+ i.e., at least an exit-code, or a dial-number or both MUST be
+ present.
+
+
+
+Allocchio Standards Track [Page 5]
+
+RFC 3601 Dial Sequences and GSTN / E.164 Addresses September 2003
+
+
+4. The "subaddr-string" definition
+
+ In GSTN service, there are cases where a subaddress is required to
+ specify the final destination. To specify these subaddresses, a Dial
+ Sequence is also used, and thus the "subaddr-string" can be encoded
+ as:
+
+ subaddr-string = phone-string
+
+ Note:
+ Within actual uses of subaddresses, some specific services can
+ limit the possible set of phone-string elements allowed. In
+ particular, there are ISDN subaddresses [2] [8], which restrict
+ the phone-string elements to 1*( DIGIT / written-sep ) and service
+ specific subaddresses, like the fax service T.33 subaddress [5]
+ [7], which restrict phone-string elements to 1*( DIGIT ).
+
+5. The "post-dial" definition
+
+ In some cases, after the connection with the destination GSTN device
+ has been established, a further dialling sequence is required to
+ access further services. A typical example is an automated menu-
+ driven service using DTMF sequences. These cases may be represented
+ using the "post-dial" definition below:
+
+ post-dial = phone-string
+
+6. Examples
+
+ In order to clarify the specification we present, here are a limited
+ set of examples. Please note that all the examples are for
+ illustration purposes only.
+
+ A GSTN address in Italy, dialled from U.S.A., using local-phone,
+ without written-sep:
+
+ 01139040226338
+
+ A GSTN address in Germany, using global-phone and written-sep ".":
+
+ +49.81.7856345
+
+ A GSTN address in U.S.A. using global-phone and written-sep "-":
+
+ +1-202-455-7622
+
+
+
+
+
+
+Allocchio Standards Track [Page 6]
+
+RFC 3601 Dial Sequences and GSTN / E.164 Addresses September 2003
+
+
+ A post-dial sequence, pausing, dialling 1, waiting for dial tone,
+ dialling 7005393, waiting again for dial tone and dialling 373; note
+ the use of four "p" elements (pppp) to specify a longer initial
+ pause:
+
+ pppp1w7005393w373
+
+ A Dial Sequence in Italy (long distance call), using local-phone,
+ with exit-code "9", long distance access "0", area code "40", pause
+ "p" and written-sep ".":
+
+ 9p040p22.63.38
+
+ A Dial Sequence using exit-code "0", a wait for dial tone, local-
+ phone for an International "800" toll-free number dialled from
+ Belgium (international prefix "00"), and a post-dial sequence to
+ access a voice mailbox with userID "334422" and Personal
+ Identification Number (PIN) code "1234":
+
+ 0w00800-39380023pp334422p1234
+
+7. Conclusions
+
+ This proposal creates a full standard text encoding for Dial
+ Sequences, including GSTN and diallable E.164 addresses, and thus
+ provides a unique common representation method both for standard
+ protocols and applications.
+
+ Some definitions, like these corresponding to an alias of the generic
+ phone-string element, are somewhat a theoretical distinction; however
+ they are useful to provide a more subtle distinction, allowing other
+ specifications to be more exact in a consistent way.
+
+ The proposal is consistent with existing standard specifications.
+
+8. Security Considerations
+
+ This document specifies a means to represent Dial Sequences, which
+ could include GSTN addresses and private codes sequences, like
+ Personal Identification Numbers, to access special services. As
+ these text strings could be transmitted without encoding inside
+ protocols or applications services, this could allow unauthorized
+ people to gain access to these codes. Users SHOULD be provided
+ methods to prevent this disclosure, like code encryption, or
+ masquerading techniques: out-of-band communication of authorization
+ information or use of encrypted data in special fields are the
+ available non-standard techniques.
+
+
+
+
+Allocchio Standards Track [Page 7]
+
+RFC 3601 Dial Sequences and GSTN / E.164 Addresses September 2003
+
+
+9. Collected ABNF Syntax
+
+ In this section we provide a summary of ABNF specifications.
+
+ phone-string = 1*( DTMF / pause / tonewait / written-sep )
+
+ DTMF = ( DIGIT / "#" / "*" / "A" / "B" / "C" / "D" )
+
+ written-sep = ( "-" / "." )
+
+ pause = "p"
+
+ tonewait = "w"
+
+ gstn-phone = ( global-phone / local-phone )
+
+ global-phone = "+" 1*( DIGIT / written-sep )
+
+ local-phone = [ exit-code ] dial-number
+
+ local-phone =/ exit-code [ dial-number ]
+
+ exit-code = phone-string
+
+ dial-number = phone-string
+
+ subaddr-string = phone-string
+
+ post-dial = phone-string
+
+10. References
+
+10.1. Normative References
+
+ [1] ETSI I-ETS 300,380 - Universal Personal Telecommunication (UPT):
+ Access Devices Dual Tone Multi Frequency (DTMF) sender for
+ acoustical coupling to the microphone of a handset telephone
+ (March 1995).
+
+ [2] ITU E.164 - The International Public Telecommunication Numbering
+ Plan E.164/I.331 (May 1997).
+
+ [3] Crocker, D. Ed. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 2234, November 1997.
+
+ [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+
+
+
+Allocchio Standards Track [Page 8]
+
+RFC 3601 Dial Sequences and GSTN / E.164 Addresses September 2003
+
+
+ [5] ITU T.33 - Facsimile routing utilizing the subaddress;
+ recommendation T.33 (July, 1996).
+
+10.2. Informative References
+
+ [6] Allocchio, C., "Minimal GSTN address format in Internet Mail",
+ RFC 3191, October 2001.
+
+ [7] Allocchio, C., "Minimal FAX address format in Internet Mail", RFC
+ 3192, October 2001.
+
+ [8] Allocchio, C., "GSTN Address Element Extensions in E-mail
+ Services", RFC 2846, June 2000.
+
+ [9] Vaha-Sipila, A., "URLs for Telephone Calls", RFC 2806, April
+ 2000.
+
+11. Author's Address
+
+ Claudio Allocchio
+ GARR
+ c/o Sincrotrone Trieste
+ SS 14 Km 163.5 Basovizza
+ I 34012 Trieste
+ Italy
+
+ Phone: +39 040 3758523
+ Fax: +39 040 3758565
+ X.400: C=it;A=garr;P=garr;S=Allocchio;G=Claudio;
+ EMail: Claudio.Allocchio@garr.it
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Allocchio Standards Track [Page 9]
+
+RFC 3601 Dial Sequences and GSTN / E.164 Addresses September 2003
+
+
+12. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2003). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assignees.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS 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.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Allocchio Standards Track [Page 10]
+