GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc3601

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:
  1. "DTMF elements": normally available as "keys" on numeric keypads

of dialling devices;

  1. "actions": normally performed by the agent (human or device)

composing the Dial Sequence;

  1. "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":
  1. one instance of a "pause" SHOULD be interpreted as a pause of

one second between the preceding and succeeding dial string

       elements;
  1. 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);
  1. 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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc3601.txt · Last modified: 2003/09/04 17:46 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki