[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 RFC 3601

Network Working                                            C. Allocchio
Group                                                        GARR-Italy
INTERNET-DRAFT                                              August 2002
                                                 Expires: February 2003
                                      File: draft-allocchio-gstn-04.txt



    Text string notation for Dial Sequences and GSTN / E.164 addresses


Status of this Memo

   This document is an Internet Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time.  It is inappropriate to use Internet-Drafts as
   reference material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
        http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
        http://www.ietf.org/shadow.html.

Copyright Notice

   Copyright (C) The Internet Society (2001).  All Rights Reserved.


Abstract

   This memo describes the full set of notations needed to represent
   in a text string a Dial Sequence. A Dial Sequence is normally
   composed by Dual Tone Multi Frequency (DTMF) elements [1] plus
   separators and the 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. Global Switched Telephone Numbers (GSTN) / E.164 addresses
   (commonly called "telephone numbers") [2] are a subset of a Dial
   Sequence, and thus use the same set of notations.

   This notation is a fully compatible compendium of existing notations,
   and MUST be used in all specifications needing a text string
   representation of a Dial Sequence (including GSTN / E.164 addresses).

1. Introduction

   Since the very first devices interacting with GSTN services appeared,
   a need for a unique text string representation of telephone numbers,
   and more generally DTMF sequences and actions, was forseen.

   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 specification
   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 [3] [4] [5] [6]) and is fully synchronized
   with them. Full compatibility is thus assured, even if in some cases
   (like in [6]) the used token names and ABNF definitions may look
   different at first glance. As a consequence, this specification results
   in a compendium of existing definitions, and is not an alternate
   solution for text string representation of a Dial Sequence.

1.1 Terminology and Syntax conventions

   In this document the formal definitions are described using ABNF
   syntax, as defined into [7]. This memo also uses some of the "CORE
   DEFINITIONS" defined in "APPENDIX A - CORE" of that document. The
   exact meaning of the capitalised words

      "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
      "SHOULD NOT", "RECOMMENDED",  "MAY", "OPTIONAL"

   is defined in reference [8].

   In this document the following terms are also defined:

     Dial Sequence:
        a series of DTMF elements and human or device "actions";

     phone-string:
        a text representation of a Dial Sequence;

     gstn-phone:
        a text representation of a GSTN address (which includes
        the E.164 addresses);

     subaddr-string:
       a text representation of a GSTN subaddress (which includes
       ISDN subaddresses [2] and T.33 subaddresses [9]);

     post-dial:
       a text representation of a post dialling sequence.


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, already the sequences needed to dial a GSTN address, 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 elelments": 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 readibility of a Dial
     Sequence.


2.1 The "phone-string" definition

   The text representation of the Dial Sequence elements is defined
   into 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 is the "separators".

   The "pause" and "tonewait" elements interpretation in phone-string
   depends on the specific devices and implementation using the
   specification. Thus their exact meaning is not mandated in this
   document. The next section gives anyhow some specification drown
   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
       element;
     - 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 readibility of phone-string. The written-sep are elements
   which can be placed between dial elements such as digits etc.
   Any occurences 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 also a GSTN address can be represented using
   the phone-string elements. In particual, standard E.164 numeric
   addresses [2] represent a limited subset of all possible GSTN
   addresses, while the complete complex case needs a full encoding
   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 )


3.1 The "global-phone" definition

   The purpose of global-phone element is to represent standard E.164
   numeric addresses. As such it uses a subset of phone-string
   definition, only.

   The syntax for 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 phone-string definition,
   is needed to label uniquely 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 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 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.

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] [5], which restrict the
      phone-string elements to 1*( DIGIT / written-sep ) and service
      specific subaddresses, like the fax service T.33 subaddress [9]
      [4] 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 "post-dial" definition below:

      post-dial = phone-string


6. Examples

   In order to clarify the specification we present here a limited set
   of examples. Please note that all the examples are for illustration
   purpouses, only.

   A GSTN address in Italy, dialled from U.S.A., using local-phone,
   without written-sep:

      01139040226338

   A GSTN address 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

   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 distant 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 Beglium (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 / 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, too.

   The proposal is consistent with existing standard specifications.


8. Security Considerations

   This document specifies a means to represent Dial Sequences, which
   thus 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.


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. Author's Address

   Claudio Allocchio
   INFN-GARR
   c/o Sincrotrone Trieste
   SS 14 Km 163.5 Basovizza
   I 34012 Trieste
   Italy

   RFC2822: Claudio.Allocchio@garr.it
   X.400:   C=it;A=garr;P=garr;S=Allocchio;G=Claudio;
   Phone:   +39 040 3758523
   Fax:     +39 040 3758565


11. 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]  Allocchio, C., "Minimal GSTN address format in Internet Mail",
        RFC 3191, October 2001

   [4]  Allocchio, C., "Minimal FAX address format in Internet Mail",
        RFC 3192, October 2001

   [5]  Allocchio, C. "GSTN address element extensions in e-mail
        services", RFC 2846, June 2000.

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

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

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

   [9]  ITU T.33 - Facsimile routing utilizing the subaddress;
        recommendation T.33 (July, 1996)



12.  Full Copyright Statement

   Copyright (C) The Internet Society (2001).  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 assigns.

   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.


Html markup produced by rfcmarkup 1.111, available from https://tools.ietf.org/tools/rfcmarkup/