RFC 3601

RFC 3601 Rewrite 💖 (Part 1 of 2)

Title block, bestie: This is RFC 3601, Text String Notation for Dial Sequences and Global Switched Telephone Network (GSTN) / E.164 Addresses 📞. It was written by C. Allocchio from GARR-Italy, it's on the Standards Track 🔥, and it's dated September 2003 🎀. It doesn't obsolete or update anything, since the title block lists neither. It came out of the Network Working Group 🦋.

Status of This Memo

This document is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 💅. For the standardisation state and status of this protocol, check the current edition of "Internet Official Protocol Standards" (STD 1) 📚. Distribution of this memo is unlimited 🌈.

Copyright Notice

Copyright (C) The Internet Society (2003). All Rights Reserved 🔒.

Abstract

Okay so this memo covers the full set of notations you need to write a text string for a Dial Sequence 📱✨. A Dial Sequence is mostly made of Dual Tone Multi Frequency (DTMF) elements 🎹, plus separators and extra "actions" like "wait for dialtone" or "pause for N secs" ⏸️. You need those to actually get connected to the target service 💖. And yes, that includes cases with subaddresses or DTMF menu navigation 🧚.

1. Introduction ✨

Ever since the very first devices talked to GSTN services, people needed one unique text string way to write down commonly dialled telephone numbers, and DTMF sequences and actions in general 📞🌸.

This memo describes the full text string representation method 💅. It was made to be an easy, unique and complete reference, and all other specifications that need a text string representation for a Dial Sequence MUST use it 🫶.

It was built from the Dial Sequence definitions that already live in existing Standard Track specifications (like [6] [7] [8] [9]), and it's fully synced with them 🔄. So full compatibility is locked in, and this spec is basically a compendium of what already exists 👑.

This notation is a fully compatible compendium of existing notations, and should be used in all specifications that need a text string representation of a Dial Sequence 💜.

Now, "telephone numbers" are usually what generate a Dial Sequence when you set up a connection 📲. But full abstract E.164 addresses [2], which is the universal addressing on the Global Switched Telephone Network (GSTN), have extra elements you can't dial 😭. So abstract E.164 addresses can't be fully turned into a Dial Sequence or fully represented with this notation 🙈.

1.1. Terminology and Syntax conventions

The formal definitions in this document are written in ABNF syntax, as defined in [3] 📐. It also uses some of the "CORE DEFINITIONS" from "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] 🔥.

Here are the terms this document also defines 💅:

• 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, which is 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 (this includes ISDN subaddresses [2] and T.33 subaddresses [5]) 🧚.
• post-dial: a text representation of a post dialling sequence ✨.

2. The "Dial Sequence" definition 🌈

Dial Sequences can go from super simple to a really huge, complex mix 🤯. The sequences you already need to dial a gstn-phone are a subset of the generic Dial Sequence, and they show off how wild this variety is 💀.

So a Dial Sequence is made up of:

• "DTMF elements": normally the "keys" on the numeric keypads of dialling devices 🎹.
• "actions": normally performed by the agent (human or device) composing the Dial Sequence 🦋.
• "separators": only there to make a Dial Sequence easier for humans to read 👀.

2.1. The "phone-string" definition 💜

The text representation of Dial Sequence elements is defined in the phone-string spec 🫶:

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" 💅.

How "pause" and "tonewait" get interpreted in a phone-string depends on the specific devices and implementation using the spec 🤷‍♀️. So their exact meaning isn't mandated in this document 🙅‍♀️. The next section gives some examples from common practice ✨. Both "pause" and "tonewait" are case insensitive 💖.

Here's how to implement "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 lasts 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 the audio channel has been opened to the receiving party) 📞.
• Because these characters aren't part of the GSTN subscriber address (telephone number) per se, any dial string characters that come after either a "pause" or a "tonewait" SHOULD be sent using DTMF signalling 🎹.

Written-sep elements are allowed so the phone-string is easier for humans to read 👓. They can sit between dial elements, like digits and so on 🌸. Any 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 gets used in the following sections to spell out the encoding of some specific subcases where it applies 💜.

3. The "gstn-phone" definition 📞

To reach a GSTN address, a human or a device has to perform a Dial Sequence 📲. So a GSTN address can be represented using phone-string elements ✨. Diallable E.164 numeric addresses [2] are a limited subset of all possible GSTN addresses 🌈. The complete, complicated case needs a full encoding schema, since it also covers a local or private addressing schema 🔐.

To describe this difference and still provide a complete encoding schema, the "gstn-phone" definition looks like this 🎀:

gstn-phone = ( global-phone / local-phone )

3.1. The "global-phone" definition 🌍

The global-phone element exists to represent diallable E.164 numeric addresses 📞. So it only uses a subset of the phone-string definition 💅.

The syntax for a global-phone element goes like this 🦋:

global-phone = "+" 1*( DIGIT / written-sep )

Any other dialling scheme MUST NOT use the leading "+" defined here 🚫. The "+" sign is strictly reserved for the standard "global-phone" syntax, and even though it isn't technically part of the phone-string definition, it's needed to uniquely label a global-phone 👑.

3.2. The "local-phone" definition 🏠

The local-phone element is meant for all the cases where the global-phone numbering schema doesn't apply 🗺️. The GSTN system uses lots of different and complicated conventions, so the local-phone definition supports a big range of elements 🍓.

Here's the detailed syntax for local-phone elements 💖:

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. At least an exit-code, or a dial-number, or both, MUST be present 🫶.

4. The "subaddr-string" definition 🧚

Sometimes a GSTN service needs a subaddress to pin down the final destination 🎯. To specify these subaddresses, a Dial Sequence is used too, so a "subaddr-string" can be encoded like this 💜:

subaddr-string = phone-string

Note 💅: within actual subaddress uses, some specific services can limit which phone-string elements are allowed ✨. In particular, ISDN subaddresses [2] [8] restrict phone-string elements to 1*( DIGIT / written-sep ). Service-specific subaddresses, like the fax service T.33 subaddress [5] [7], restrict phone-string elements to 1*( DIGIT ) 📠.

5. The "post-dial" definition 🎀

Sometimes, once the connection to the destination GSTN device is up, you need another dialling sequence to reach more services 📞. A classic example is an automated menu-driven service that uses DTMF sequences 🎹. These cases can be represented with the "post-dial" definition below 🌸:

post-dial = phone-string

6. Examples ✨

Okay, examples time, bestie 🎀 Quick heads up: these are only for illustration, so don't treat them as the one true way to do things. 🌸

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

01139040226338

A GSTN address in Germany, using global-phone and written-sep "." 🇩🇪

+49.81.7856345

A GSTN address in the U.S.A., using global-phone and written-sep "-" 🇺🇸

+1-202-455-7622

A post-dial sequence where you pause, dial 1, wait for dial tone, dial 7005393, wait again for dial tone, and then dial 373. Notice the four "p" elements (pppp) that make the initial pause longer 🦋

pppp1w7005393w373

A Dial Sequence in Italy for a 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, and local-phone for an International "800" toll-free number dialled from Belgium (international prefix "00"). It also has a post-dial sequence to reach a voice mailbox with userID "334422" and Personal Identification Number (PIN) code "1234" 💜

0w00800-39380023pp334422p1234

7. Conclusions 💅

Okay, so this proposal creates a full standard text encoding for Dial Sequences, including GSTN and diallable E.164 addresses 📱 That means it gives us one unique, shared way to represent them for standard protocols and applications, and that is honestly iconic 👑

Some definitions, like the ones for an alias of the generic phone-string element, are kind of a theoretical distinction, ngl 🙈 Still, they give us a more subtle difference, so other specifications can be more exact in a consistent way. Very precise, very aesthetic 🧚

The proposal is consistent with existing standard specifications. Literally no clashing 🫶

8. Security Considerations 🔒

Okay, this section is serious, so read it carefully 🚨

This document specifies a way to represent Dial Sequences. Those could include GSTN addresses and private code sequences, like Personal Identification Numbers, used to access special services 🔑 Because these text strings could be sent without encoding inside protocols or application services, unauthorized people might be able to get hold of those codes 😭

Users SHOULD be provided with methods to prevent this disclosure, like code encryption or masquerading techniques. The available non-standard techniques are out-of-band communication of authorization information, or using encrypted data in special fields 🛡️

9. Collected ABNF Syntax 🧩

Here's a quick summary of the ABNF specifications, all in one place so it's easy to scan 💖

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.

[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

12. Full Copyright Statement ⚖️

Copyright (C) The Internet Society (2003). All Rights Reserved. 🌈

This document and translations of it may be copied and shared with others. Derivative works that comment on or explain it, or help with implementing it, may be prepared, copied, published, and distributed, in whole or in part, without any restriction, as long as 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. The exceptions are when it's needed for developing Internet standards, in which case the copyright procedures in the Internet Standards process must be followed, or when it's needed 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. Forever and ever 💜

This document and the information in it 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. Thank you to them for keeping the lights on 🫶✨