diff options
Diffstat (limited to 'doc/rfc/rfc2806.txt')
| -rw-r--r-- | doc/rfc/rfc2806.txt | 1179 |
1 files changed, 1179 insertions, 0 deletions
diff --git a/doc/rfc/rfc2806.txt b/doc/rfc/rfc2806.txt new file mode 100644 index 0000000..bbd1282 --- /dev/null +++ b/doc/rfc/rfc2806.txt @@ -0,0 +1,1179 @@ + + + + + + +Network Working Group A. Vaha-Sipila +Request for Comments: 2806 Nokia +Category: Standards Track April 2000 + + + URLs for Telephone Calls + +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 (2000). All Rights Reserved. + +Abstract + + This document specifies URL (Uniform Resource Locator) schemes "tel", + "fax" and "modem" for specifying the location of a terminal in the + phone network and the connection types (modes of operation) that can + be used to connect to that entity. This specification covers voice + calls (normal phone calls, answering machines and voice messaging + systems), facsimile (telefax) calls and data calls, both for POTS and + digital/mobile subscribers. + +Table of Contents + + 1. Introduction ................................................ 2 + 1.1 New URL schemes ............................................ 2 + 1.2 Formal definitions ......................................... 3 + 1.3 Requirements ............................................... 3 + 2. URL schemes for telephone calls ............................. 3 + 2.1 Applicability .............................................. 3 + 2.2 "tel" URL scheme ........................................... 4 + 2.3 "fax" URL scheme ........................................... 6 + 2.4 "modem" URL scheme ......................................... 6 + 2.5 Parsing telephone, fax and modem URLs ...................... 7 + 2.5.1 Call type ................................................ 7 + 2.5.2 Phone numbers and their scope ............................ 7 + 2.5.3 Separators in phone numbers .............................. 10 + 2.5.4 Converting the number to the local numbering scheme ...... 10 + 2.5.5 Sending post-dial sequence after call setup .............. 10 + 2.5.6 Pauses in dialing and post-dial sequence ................. 11 + 2.5.7 ISDN subaddresses ........................................ 11 + + + +Vaha-Sipila Standards Track [Page 1] + +RFC 2806 URLs for Telephone Calls April 2000 + + + 2.5.8 T.33 subaddresses ........................................ 11 + 2.5.9 Data call parameters ..................................... 12 + 2.5.10 Telephony service provider identification ............... 13 + 2.5.11 Additional parameters ................................... 14 + 2.6 Examples of Use ............................................ 14 + 2.7 Rationale behind the syntax ................................ 15 + 2.7.1 Why distinguish between call types? ..................... 15 + 2.7.2 Why "tel" is "tel"? ..................................... 16 + 2.7.3 Why to use E.164-style numbering? ........................ 16 + 2.7.4 Not everyone has the same equipment as you ............... 17 + 2.7.5 Do not confuse numbers with how they are dialled ......... 17 + 3. Comments on usage ........................................... 17 + 4. References .................................................. 18 + 5. Security Considerations ..................................... 19 + 6. Acknowledgements ............................................ 20 + 7. Author's Address ............................................ 20 + 8. Full Copyright Statement .................................... 21 + +1. Introduction + +1.1 New URL schemes + + This specification defines three new URL schemes: "tel", "fax" and + "modem". They are intended for describing a terminal that can be + contacted using the telephone network. The description includes the + subscriber (telephone) number of the terminal and the necessary + parameters to be able to successfully connect to that terminal. + + The "tel" scheme describes a connection to a terminal that handles + normal voice telephone calls, a voice mailbox or another voice + messaging system or a service that can be operated using DTMF tones. + + The "fax" scheme describes a connection to a terminal that can handle + telefaxes (facsimiles). The name (scheme specifier) for the URL is + "fax" as recommended by [E.123]. + + The "modem" scheme describes a connection to a terminal that can + handle incoming data calls. The term "modem" refers to a device that + does digital-to-analog and analog-to-digital conversions; in addition + to these, a "modem" scheme can describe a fully digital connection. + + The notation for phone numbers is the same which is specified in + [RFC2303] and [RFC2304]. However, the syntax definition is a bit + different due to the fact that this document specifies URLs whereas + [RFC2303] and [RFC2304] specify electronic mail addresses. For + example, "/" (used in URLs to separate parts in a hierarchical URL + [RFC2396]) has been replaced by ";". In addition, this URL scheme has + been synchronized with [RFC2543]. + + + +Vaha-Sipila Standards Track [Page 2] + +RFC 2806 URLs for Telephone Calls April 2000 + + + When these URLs are used, the number of parameters should be kept to + the minimum, unless this would make the context of use unclear. + Having a short URL is especially important if the URL is intended to + be shown to the end user, printed, or otherwise distributed so that + it is visible. + +1.2 Formal definitions + + The ABNF (augmented Backus-Naur form) notation used in formal + definitions follows [RFC2234]. This specification uses elements from + the 'core' definitions (Appendix A of [RFC2234]). Some elements have + been defined in previous RFCs. If this is the case, the RFC in + question has been referenced in comments. + + Note on non-unreserved characters [RFC2396] in URLs: the ABNF in this + document specifies strings of raw, unescaped characters. If those + characters are present in a URL, and are not unreserved [RFC2396], + they MUST be escaped as explained in [RFC2396] prior to using the + URL. In addition, when parsing a URL, it must be noted that some + characters may have been escaped. + + An example: ABNF notation "%x20" means a single octet with a + hexadecimal value of "20" (in US-ASCII, a space character). This must + be escaped in a URL, and it becomes "%20". + + In addition, the ABNF in this document only uses lower case. The URLs + are case-insensitive (except for the <future-extension> parameter, + whose case-sensitivity is application-specific). + +1.3 Requirements + + 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 [RFC2119]. + + Compliant software MUST follow this specification. + +2. URL schemes for telephone calls + +2.1 Applicability + + In this document, "local entity" means software and hardware that can + detect and parse one or more of these URLs and possibly place a call + to a remote entity, or otherwise utilize the contents of the URL. + + These URL schemes are used to direct the local entity to place a call + using the telephone network, or as a method to transfer or store a + phone number plus other relevant data. The network in question may be + + + +Vaha-Sipila Standards Track [Page 3] + +RFC 2806 URLs for Telephone Calls April 2000 + + + a landline or mobile phone network, or a combination of these. If the + phone network differentiates between (for example) voice and data + calls, or if the local entity has several different + telecommunications equipment at its disposal, it is possible to + specify which kind of call (voice/fax/data) is requested. The URL can + also contain information about the capabilities of the remote entity, + so that the connection can be established successfully. + + The "tel", "fax" and "modem" URL schemes defined here do not use the + hierarchical URL syntax; there are no applicable relative URL forms. + The URLs are always case-insensitive, except for the <future- + extension> parameter (see below), whose case-sensitivity is + application specific. Characters in the URL MUST be escaped when + needed as explained in [RFC2396]. + +2.2 "tel" URL scheme + + The URL syntax is formally described as follows. For the basis of + this syntax, see [RFC2303]. + +telephone-url = telephone-scheme ":" + telephone-subscriber +telephone-scheme = "tel" +telephone-subscriber = global-phone-number / local-phone-number +global-phone-number = "+" base-phone-number [isdn-subaddress] + [post-dial] *(area-specifier / + service-provider / future-extension) +base-phone-number = 1*phonedigit +local-phone-number = 1*(phonedigit / dtmf-digit / + pause-character) [isdn-subaddress] + [post-dial] area-specifier + *(area-specifier / service-provider / + future-extension) +isdn-subaddress = ";isub=" 1*phonedigit +post-dial = ";postd=" 1*(phonedigit / + dtmf-digit / pause-character) +area-specifier = ";" phone-context-tag "=" phone-context-ident +phone-context-tag = "phone-context" +phone-context-ident = network-prefix / private-prefix +network-prefix = global-network-prefix / local-network-prefix +global-network-prefix = "+" 1*phonedigit +local-network-prefix = 1*(phonedigit / dtmf-digit / pause-character) +private-prefix = (%x21-22 / %x24-27 / %x2C / %x2F / %x3A / + %x3C-40 / %x45-4F / %x51-56 / %x58-60 / + %x65-6F / %x71-76 / %x78-7E) + *(%x21-3A / %x3C-7E) + ; Characters in URLs must follow escaping rules + ; as explained in [RFC2396] + + + +Vaha-Sipila Standards Track [Page 4] + +RFC 2806 URLs for Telephone Calls April 2000 + + + ; See sections 1.2 and 2.5.2 +service-provider = ";" provider-tag "=" provider-hostname +provider-tag = "tsp" +provider-hostname = domain ; <domain> is defined in [RFC1035] + ; See section 2.5.10 +future-extension = ";" 1*(token-char) ["=" ((1*(token-char) + ["?" 1*(token-char)]) / quoted-string )] + ; See section 2.5.11 and [RFC2543] +token-char = (%x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39 + / %x41-5A / %x5E-7A / %x7C / %x7E) + ; Characters in URLs must follow escaping rules + ; as explained in [RFC2396] + ; See sections 1.2 and 2.5.11 +quoted-string = %x22 *( "\" CHAR / (%x20-21 / %x23-7E + / %x80-FF )) %x22 + ; Characters in URLs must follow escaping rules + ; as explained in [RFC2396] + ; See sections 1.2 and 2.5.11 +phonedigit = DIGIT / visual-separator +visual-separator = "-" / "." / "(" / ")" +pause-character = one-second-pause / wait-for-dial-tone +one-second-pause = "p" +wait-for-dial-tone = "w" +dtmf-digit = "*" / "#" / "A" / "B" / "C" / "D" + + The URL starts with <telephone-scheme>, which tells the local entity + that what follows is a URL that should be parsed as described in this + document. After that, the URL contains the phone number of the remote + entity. Phone numbers can also contain subaddresses, which are used + to identify different remote entities under the same phone number. If + a subaddress is present, it is appended to the phone number after + ";isub=". Phone numbers can also contain a post-dial sequence. This + is what is often used with voice mailboxes and other services that + are controlled by dialing numbers from your phone keypad while the + call is in progress. The <post-dial> sequence describes what and when + the local entity should send to the phone line. + + Phone numbers can be either "global" or "local". Global numbers are + unambiguous everywhere. Local numbers are usable only within a + certain area, which is called "context", see section 2.5.2. + + Local numbers always have an <area-specifier>, which specifies the + context in which the number is usable (the same number may have + different interpretation in different network areas). The context can + be indicated with three different prefixes. A <global-network-prefix> + indicates that the number is valid within a numbering area whose + global numbers start with <global-network-prefix>. Similarly, + <local-network-prefix> means that the number is valid within a + + + +Vaha-Sipila Standards Track [Page 5] + +RFC 2806 URLs for Telephone Calls April 2000 + + + numbering area whose numbers (or dial strings) start with it. A + <private-prefix> is a name of a context. The local entity must have + knowledge of this private context to be able to deduce whether it can + use the number, see section 2.5.2. Additional information about the + phone number's usage can be included by adding the name of the + telephony services provider in <service-provider>, see section + 2.5.10. + + The <future-extension> mechanism makes it possible to add new + parameters to this URL scheme. See section 2.5.11. + + The <private-prefix>, <token-char> and <quoted-string> nonterminals + may seem a bit complex at first, but they simply describe the set of + octets that are legal in those nonterminals. Some octets may have to + be escaped, see [RFC2396]. + +2.3 "fax" URL scheme + + The URL syntax is formally described as follows (the definition + reuses nonterminals from the above definition). For the basis of this + syntax, see [RFC2303] and [RFC2304]. + + fax-url = fax-scheme ":" fax-subscriber + fax-scheme = "fax" + fax-subscriber = fax-global-phone / fax-local-phone + fax-global-phone = "+" base-phone-number [isdn-subaddress] + [t33-subaddress] [post-dial] + *(area-specifier / service-provider / + future-extension) + fax-local-phone = 1*(phonedigit / dtmf-digit / + pause-character) [isdn-subaddress] + [t33-subaddress] [post-dial] + area-specifier + *(area-specifier / service-provider / + future-extension) + t33-subaddress = ";tsub=" 1*phonedigit + + The fax: URL is very similar to the tel: URL. The main difference is + that in addition to ISDN subaddresses, telefaxes also have an another + type of subaddress, see section 2.5.8. + +2.4 "modem" URL scheme + + The URL syntax is formally described as follows (the definition + reuses nonterminals from the above definitions). For the basis of + this syntax, see [RFC2303]. + + + + + +Vaha-Sipila Standards Track [Page 6] + +RFC 2806 URLs for Telephone Calls April 2000 + + + modem-url = modem-scheme ":" remote-host + modem-scheme = "modem" + remote-host = telephone-subscriber *(modem-params + / recommended-params) + modem-params = ";type=" data-capabilities + recommended-params = ";rec=" data-capabilities + data-capabilities = accepted-modem ["?" data-bits parity + stop-bits] + accepted-modem = "V21" / "V22" / "V22b" / + "V23" / "V26t" / "V32" / + "V32b" / "V34" / "V90" / + "V110" / "V120" / "B103" / + "B212" / "X75" / + "vnd." vendor-name "." modem-type + data-bits = "7" / "8" + parity = "n" / "e" / "o" / "m" / "s" + stop-bits = "1" / "2" + vendor-name = 1*(ALPHA / DIGIT / "-" / "+") + modem-type = 1*(ALPHA / DIGIT / "-" / "+") + + The modem: URL scheme is also very similar to both the tel: and fax: + schemes, but it adds the description of the capabilities of the + remote entity. Minimum required compliance is listed in <modem- + params> and recommended compliance is listed in <recommended-params>. + For details, see section 2.5.9. + +2.5 Parsing telephone, fax and modem URLs + +2.5.1 Call type + + The type of call is specified by the scheme specifier. "Tel" means + that a voice call is opened. "Fax" indicates that the call should be + a facsimile (telefax) call. "Modem" means that it should be a data + call. Not all networks differentiate between the types of call; in + this case, the scheme specifier indicates the telecommunications + equipment type to use. + +2.5.2 Phone numbers and their scope + + <telephone-subscriber> and <fax-subscriber> indicate the phone number + to be dialed. The phone number can be written in either international + or local notation. All phone numbers SHOULD always be written in the + international form if there is no good reason to use the local form. + + Not all numbers are valid within all numbering areas. The <area- + specifier> parameter, which is mandatory for local numbers, is used + to indicate the locale within which this number is valid, or to + qualify the phone number so that it may be used unambiguously. The + + + +Vaha-Sipila Standards Track [Page 7] + +RFC 2806 URLs for Telephone Calls April 2000 + + + <area-specifier> can take three forms: <global-network-prefix>, + <local-network-prefix> or <private-prefix>. These are used to + describe the validity area of the phone number either in global + numbering plan, local numbering plan, or in a private numbering plan, + respectively. + + If <area-specifier> is present, the local entity MUST NOT attempt to + call out using the phone number if it cannot originate the call + within the specified locale. If a <local-phone-number> is used, an + <area-specifier> MUST be included as well. + + There can be multiple instances of <area-specifier>. In this case, + the number is valid in all of the given numbering areas. + + The global prefix form is intended to act as the outermost context + for a phone number, so it will start with a "+", followed by some + part of an E.164 number. It also specifies the region in which the + phone number is valid. For example, if <global-network-prefix> is + "+358", the given number is valid only within Finland (country code + 358) - even if it is a <global-phone-number>. + + The local prefix form is intended to act as an intermediate context + in those situations where the outermost context for a phone number is + given by another means. One example of use is where the local entity + is known to originate calls only within the North American Number + Plan Area, so an "outermost" phone context can be assumed. The local + context could, for example, be used to indicate the area code within + which an associated phone number is situated. Thus "tel:456- + 7890;phone-context=213" would suffice to deliver a call to the + telephone number "+1-213-456-7890". Note that the version including + the <phone-context> implies further that the call can only be + originated within the "area code 213" region. + + The <private-prefix> form is intended for use in those situations + where the context cannot be expressed with a start of a global phone + number or a dialing string. The <private-prefix> is actually a name + of a private context. The creator of the URL and the local entity + have been configured to recognize this name, and as such they can + interpret the number and know how they can utilize the number. For + example, a private network numbering plan may be indicated by the + name "X-COMPANY-NET", but the private dialling plan from the locales + of the sender of the telephony URL and the local entity are + different. The syntax of these tokens will be left for future + specification. The ABNF above specifies the accepted characters that + can be a part of <private-prefix>. + + + + + + +Vaha-Sipila Standards Track [Page 8] + +RFC 2806 URLs for Telephone Calls April 2000 + + + Unless the sender is absolutely sure that they share the same private + network access digit string with the local entity, then they MUST NOT + use a dialling plan number (a local phone number, or one qualified by + a local context), as the result may be incorrect. Instead, they + SHOULD use a global number, or if that is not possible, a private + context as the last resort. If the local entity does not support + dialling into the private network indicated by that context, then the + request MUST be rejected. If it does, then it will use the access + digit string appropriate for its locale. + + Note that the use of <area-specifier> is orthogonal to use of the + telephony service provider parameter (see 2.5.10); it qualifies the + phone number, whilst the <service-provider> parameter indicates the + carrier to be used for the call attempt. + + For example, a large company may have private network + interconnections between its sites, as well as connections to the + Global Switched Telephone Network. A phone number may be given in + "public network" form, but with a <service-provider> indicating that + the call should be carried over the corporate network. + + Conversely, it would be possible to represent a phone number in + private network form, with a private context to indicate this, but + indicate a public telephony service provider. This would request that + the user agent convert the private network number plan address into a + form that can be carried using the selected service provider. + + Any telephone number MUST contain at least one <phonedigit> or + <dtmf-digit>, that is, subscriber numbers consisting only of pause + characters are not allowed. + + International numbers MUST begin with the "+" character. Local + numbers MUST NOT contain that character. International numbers MUST + be written with the country (CC) and national (NSN) numbers as + specified in [E.123] and [E.164]. International numbers have the + property of being totally unambiguous everywhere in the world if the + local entity is properly configured. + + Local numbers MAY be used if the number only works from inside a + certain geographical area or a network. Note that some numbers may + work from several networks but not from the whole world - these + SHOULD be written in international form, with a set of <area- + specifier> tags and optional <service-provider> parameters. URLs + containing local phone numbers should only appear in an environment + where all local entities can get the call successfully set up by + passing the number to the dialing entity "as is". An example could be + a company intranet, where all local entities are located under a the + same private telephone exchange. If local phone numbers are used, + + + +Vaha-Sipila Standards Track [Page 9] + +RFC 2806 URLs for Telephone Calls April 2000 + + + the document in which they are present SHOULD contain an indication + of the context in which they are intended to be used, and an + appropriate <area-specifier> SHOULD be present in the URL. + + In some regions, it is popular to write phone numbers using + alphabetic characters which correspond to certain numbers on the + telephone keypad. Letters in <dtmf-digit> characters do not have + anything to do with this, nor is this method supported by these URL + schemes. + + It should also be noted that implementations MUST NOT assume that + telephone numbers have a maximum, minimum or fixed length, or that + they would always begin with a certain number. Implementors are + encouraged to familiarize themselves with the international + standards. + +2.5.3 Separators in phone numbers + + All <visual-separator> characters MUST be ignored by the local entity + when using the URL. These characters are present only to aid + readability: they MUST NOT have any other meaning. Note that although + [E.123] recommends the use of space (SP) characters as the separators + in printed telephone numbers, spaces MUST NOT be used in phone + numbers in URLs as the space character cannot be used in URLs without + escaping it. + +2.5.4 Converting the number to the local numbering scheme + + After the telephone number has been extracted, it can be converted to + the local dialing convention. (For example, the "+" character might + be replaced by the international call prefix, or the international + and trunk prefixes might be removed to place a local call.) Numbers + that have been specified using <local-phone> or <fax-local-phone> + MUST be used by the local entity "as is", without any conversions, + unless the local entity decides to utilize the information in an + optional <service-provider> parameter. + +2.5.5 Sending post-dial sequence after call setup + + The number may contain a <post-dial> sequence, which MUST be dialled + using Dual Tone Multifrequency (DTMF) in-band signalling or pulse + dialing after the call setup is complete. If the user agent does not + support DTMF or pulse dialing after the call has been set up, <post- + dial> MUST be ignored. In that case, the user SHOULD be notified. + + + + + + + +Vaha-Sipila Standards Track [Page 10] + +RFC 2806 URLs for Telephone Calls April 2000 + + +2.5.6 Pauses in dialing and post-dial sequence + + A local phone number or a post-dial sequence may contain <pause- + character> characters which indicate a pause while dialing ("p"), or + a wait for dial tone ("w"). + + Local entities MAY support this method of dialing, and the final + interpretation of these characters is left to the local entity. It + is RECOMMENDED that the length of each pause is about one second. + + If it is not supported, local entities MUST ignore everything in the + dial string after the first <pause-character> and the user SHOULD be + notified. The user or the local entity MAY opt not to place a call if + this feature is not supported and these characters are present in the + URL. + + Any <dtmf-digit> characters and all dial string characters after the + first <pause-character> or <dtmf-digit> SHOULD be sent to line using + DTMF (Dual Tone Multifrequency) in-band signaling, even if dialing is + done using direct network signaling (a digital subscriber loop or a + mobile phone). If the local infrastructure does not support DTMF + codes, the local entity MAY opt to use pulse dialing. However, it + should be noted that certain services which are controlled using DTMF + tones cannot be controlled with pulse dialing. If pulse dialing is + used, the user SHOULD be notified. + +2.5.7 ISDN subaddresses + + A phone number MAY also contain an <isdn-subaddress> which indicates + an ISDN subaddress. The local entity SHOULD support ISDN + subaddresses. These addresses are sent to the network by using a + method available to the local entity (typically, ISDN subscribers + send the address with the call setup signalling). If ISDN + subaddressing is not supported by the caller, <isdn-subaddress> MUST + be ignored and the user SHOULD be notified. The user or the local + entity MAY opt not to place a call if this feature is not supported. + +2.5.8 T.33 subaddresses + + A fax number MAY also contain a <t33-subaddress>, which indicates the + start of a T.33 subaddress [T.33]. Local entities SHOULD support + this. Otherwise <t33-subaddress> MUST be ignored and the user SHOULD + be notified. The user or the local entity MAY opt not to place a call + if this feature is not supported. + + + + + + + +Vaha-Sipila Standards Track [Page 11] + +RFC 2806 URLs for Telephone Calls April 2000 + + +2.5.9 Data call parameters + + <modem-params> indicate the minimum compliance required from the + local entity to be able to connect to the remote entity. The minimum + compliance is defined as being equal to or a superset of the + capabilities of the listed modem type. There can be several <modem- + param> parameters, in which case compliance to any one of them will + be accepted. <recommended-params> indicates the recommended + compliance required from the local entity. This is typically the + fastest and/or the most reliable modem type supported by the modem + pool. The local entity can use this information to select the best + number from a group of modem URLs. There can be several recommended + modem types, which are equally desirable from the modem pool's point + of view. <recommended-params> MAY NOT conflict with <modem-params>. + If they do, the local entity MUST ignore the <recommended-params>. + + The local entity MUST call out using compatible hardware, or request + that the network provides such a service. + + For example, if the local entity only has access to a V.22bis modem + and the URL indicates that the minimum acceptable connection is + V.32bis, the local entity MUST NOT try to connect to the remote host + since V.22bis is a subset of V.32bis. However, if the URL lists V.32 + as the minimum acceptable connection, the local entity can use + V.32bis to create a connection since V.32bis is a superset of V.32. + + This feature is present because modem pools often have separate + numbers for slow modems and fast modems, or have different numbers + for analog and ISDN connections, or may use proprietary modems that + are incompatible with standards. It is somewhat analogous to the + connection type specifier (typecode) in FTP URLs [RFC1738]: it + provides the local entity with information that can not be deduced + from the scheme specifier, but is helpful for successful operation. + + This also means that the number of data and stop bits and parity MUST + be set according to the information given in the URL, or to default + values given in this document, if the information is not present. + + The capability tokens are listed below. If capabilities suggest that + it is impossible to create a connection, the connection MUST NOT be + created. + + If new modem types are standardized by ITU-T, this list can be + extended with those capability tokens. Tokens are formed by taking + the number of the standard and joining together the first letter (for + example, "V"), number (for example, 22) and the first letter of the + postfix (for example "bis" would become "b"). + + + + +Vaha-Sipila Standards Track [Page 12] + +RFC 2806 URLs for Telephone Calls April 2000 + + + Proprietary modem types MUST be specified using the 'vendor naming + tree', which takes the form "vnd.x.y", in which "x" is the name of + the entity from which the specifications for the modem type can be + acquired and "y" is the type or model of the modem. Vendor names MUST + share the same name space with vendor names used in MIME types + [RFC2048]. Submitting the modem types to ietf-types list for review + is strongly recommended. + + New capabilities MUST always be documented in an RFC, and they MUST + refer to this document or a newer version of it. The documentation + SHOULD also list the existing modem types with which the newly + defined modem type is compatible with. + + Capability Explanation + + V21 ITU-T V.21 + V22 ITU-T V.22 + V22b ITU-T V.22bis + V23 ITU-T V.23 + V26t ITU-T V.26ter + V32 ITU-T V.32 + V32b ITU-T V.32bis + V34 ITU-T V.34 + V90 ITU-T V.90 + V110 ITU-T V.110 + V120 ITU-T V.120 + X75 ITU-T X.75 + B103 Bell 103 + B212 Bell 212 + Data bits: "8" or "7" The number of data bits. If not + specified, defaults to "8". + Parity: "n", "e", "o", Parity. None, even, odd, mark or + "m", "s" space parity, respectively. If + not specified, defaults to "n". + Stop bits: "1" or "2" The number of stop bits. If not + specified, defaults to "1". + +2.5.10 Telephony service provider identification + + It is possible to indicate the identity of the telephony service + provider for the given phone number. <service-provider> MAY be used + by the user-agent to place the call using this network, to enhance + the user interface, for billing estimates or to otherwise optimize + its functionality. It MAY also be ignored by the user-agent. + <service-provider> consists of a fully qualified Internet domain name + of the telephony service provider, for example + ";tsp=terrifictelecom.com". The syntax of the domain name follows + Internet domain name rules and is defined in [RFC1035]. + + + +Vaha-Sipila Standards Track [Page 13] + +RFC 2806 URLs for Telephone Calls April 2000 + + +2.5.11 Additional parameters + + In addition to T.33 and ISDN subaddresses, modem types and area + specifiers, future extensions to this URL scheme may add other + additional parameters (<future-extension> in the BNF) to these URLs. + These parameters are added to the URL after a semicolon (";"). + Implementations MUST be prepared to handle additional and/or unknown + parameters gracefully. Implementations MUST NOT use the URL if it + contains unknown parameters, as they may be vital for the correct + interpretation of the URL. Instead, the implementation SHOULD report + an error. + + For example, <future-extension> can be used to store application- + specific additional data about the phone number, its intended use, or + any conversions that have been applied to the number. Whenever a + <future-extension> is used in an open environment, its syntax and + usage MUST be properly documented in an RFC. + + <future-extension> nonterminal a rephrased version of, and compatible + with the <other-param> as defined in [RFC2543] (which actually + borrows BNF from an earlier version of this specification). + +2.6 Examples of Use + + tel:+358-555-1234567 + + This URL points to a phone number in Finland capable of receiving + voice calls. The hyphens are included to make the number more human- + readable: country and area codes have been separated from the + subscriber number. + + fax:+358.555.1234567 + + The above URL describes a phone number which can receive fax calls. + It uses dots instead of hyphens as separators, but they have no + effect on the functionality. + + modem:+3585551234567;type=v32b?7e1;type=v110 + + This phone number belongs to an entity which is able to receive data + calls. The local entity may opt to use either a ITU-T V.32bis modem + (or a faster one, which is compatible with V.32bis), using settings + of 7 data bits, even parity and one stop bit, or an ISDN connection + using ITU-T V.110 protocol. + + + + + + + +Vaha-Sipila Standards Track [Page 14] + +RFC 2806 URLs for Telephone Calls April 2000 + + + tel:+358-555-1234567;postd=pp22 + + The above URL instructs the local entity to place a voice call to + +358-555-1234567, then wait for an implementation-dependent time (for + example, two seconds) and emit two DTMF dialing tones "2" on the line + (for example, to choose a particular extension number, or to invoke a + particular service). + + tel:0w003585551234567;phone-context=+3585551234 + + This URL places a voice call to the given number. The number format + is intended for local use: the first zero opens an outside line, the + "w" character waits for a second dial tone, and the number already + has the international access code appended to it ("00"). This kind of + phone number MUST NOT be used in an environment where all users of + this URL might not be able to successfully dial out by using this + number directly. However, this might be appropriate for pages in a + company intranet. The <area-specifier> which is present hints that + the number is usable only in an environment where the local entity's + phone number starts with the given string (perhaps singling out a + company-wide block of telephone numbers). + + tel:+1234567890;phone-context=+1234;vnd.company.option=foo + + The URL describes a phone number which, even if it is written in its + international form, is only usable within the numbering area where + phone numbers start with +1234. There is also a proprietary extension + "vnd.company.option", which has the value "foo". The meaning of this + extension is application-specific. Note that the order of these + parameters (phone-context and vnd.company.option) is irrelevant. + +2.7 Rationale behind the syntax + +2.7.1 Why distinguish between call types? + + URLs locate resources, which in this case is some telecommunications + equipment at a given phone number. However, it is not necessarily + enough to know the subscriber number in order to successfully + communicate with that equipment. Digital phone networks distinguish + between voice, fax and data calls (and possibly other types of calls, + not discussed in this specification). To be able to successfully + connect to, say, a fax machine, the caller may have to specify that a + fax call is being made. Otherwise the call might be routed to the + voice number of the subscriber. In this sense, the call type is an + integral part of the 'location' of the target resource. + + + + + + +Vaha-Sipila Standards Track [Page 15] + +RFC 2806 URLs for Telephone Calls April 2000 + + + The reason to have the call type in the scheme specifier is to make + the URL simple to remember and use. Making it a parameter, much like + the way modem parameters are handled now, will substantially reduce + the human readability of this URL. + +2.7.2 Why "tel" is "tel"? + + There has been discussion on whether the scheme name "tel" is + appropriate. To summarize, these are the points made against the + other proposals. + + callto URL schemes locate a resource and do not specify + an action to be taken. + telephone Too long. Also, "tel" considered to be a more + international form. + phone Was countered on the basis that "tel" is more + internationally acceptable. + +2.7.3 Why to use E.164-style numbering? + + E.164 refers to international telephone numbers, and the string of + digits after the country code is usually a national matter. In any + case, phone numbers are usually written as a simple string of numbers + everywhere. Because of this, the syntax in this specification is + intuitively clear to most people. This is the usual way to write + phone numbers in business cards, advertisements, telephone books and + so on. + + It should be noted that phone numbers may have 'hierarchical' + characteristics, so that one could build a 'forest' of phone numbers + with country codes as roots, area codes as branches and subscriber + numbers as leaves. However, this is not always the case. Not all + areas have area codes; some areas may have different area codes + depending on how one wants to route the call; some numbers must + always be dialled "as is", without prepending area or country codes + (notably emergency numbers); and area codes can and do change. + + Usually, if something has a hierarchical structure, the URL syntax + should reflect that fact. These URLs are an exception. + + Also, when writing the phone number in the form described in this + specification, the writer does not need to know which part of the + number is the country code and which part is the area code. If a + hierarchical URL would be used (with a "/" character separating the + parts of the phone numbers), the writer of the URL would have to know + which parts are which. + + + + + +Vaha-Sipila Standards Track [Page 16] + +RFC 2806 URLs for Telephone Calls April 2000 + + + Finally, when phone numbers are written in the international form as + specified here, they are unambiguous and can always be converted to + the local dialing convention, given that the user agent has the + knowledge of the local country and area codes. + +2.7.4 Not everyone has the same equipment as you + + There are several ways for the subscriber to dial a phone number: + + - By pulse dialing. Typically old telephone exchanges. Usually this + dialing method has only to be used to set up the call; after + connecting to the remote entity, <post-dial> can be sent to the + line using DTMF, because it will typically be processed by the + remote entity, not the telephone network. + + - By DTMF. These are the 'beeps' that you hear when you dial on + most phones. + + - By direct network signalling. ISDN subscribers and mobile phone + users usually have this. There is no dial tone (or if there is, it + is generated locally by the equipment), and the number of the + called party is communicated to the telephone network using some + network signalling method. After setting up the call, <post-dial> + sequences are usually sent using DTMF codes. + +2.7.5 Do not confuse numbers with how they are dialled + + As an example, +123456789 will be dialled in many countries as + 00123456789, where the leading "00" is a prefix for international + calls. However, if a URL contains a local phone number 00123456789, + the user-agent MUST NOT assume that this number is equal to a global + phone number +123456789. If a user-agent received a telephony URL + with a local number in it, it MUST make sure that it knows the + context in which the local phone number is to be processed, or else + the number MUST NOT be used. Equally, anyone sending a telephony URL + MUST take into consideration that the recipient may have insufficient + information about the phone number's context. + +3. Comments on usage + + These are examples of the recommended usage of this URL in HTML + documents. + + First of all, the number SHOULD be visible to the end user, if it is + conceivable that the user might not have a local entity which is able + to use these URLs. + + Telephone: <a href="tel:+3585551234567">+358-555-1234567</a> + + + +Vaha-Sipila Standards Track [Page 17] + +RFC 2806 URLs for Telephone Calls April 2000 + + + Second, on a public HTML page, the telephone number in the URL SHOULD + always be in the international form, even if the text of the link + uses some local format. + + Telephone: <a href="tel:+3585551234567">(0555) 1234567</a> + + or even + + For more info, call <a href="tel:+15554383785965">1-555-IETF-RULZ- + OK</a>. + + Moreover, if the number is a <local-phone-number>, and the scope of + the number is not clear from the context in which the URL is + displayed, a human-readable explanation SHOULD be included. + + For customer service, dial <a href="tel:1234;phone- + context=+358555">1234</a> (only from Terrific Telecom mobile + phones). + +4. References + + [RFC1035] Mockapetris, P., "Domain Names - Implementation and + Specification", STD 13, RFC 1035, November 1987. + + [RFC1738] Berners-Lee, T., et al., "Uniform Resource Locators (URL)", + RFC 1738, December 1994. + + [RFC1866] Berners-Lee, T. and D. Connolly, "Hypertext Markup Language + - 2.0", RFC 1866, November 1995. + + [RFC2048] Freed, N., Klensin, J. and J. Postel, "Multipurpose + Internet Mail Extensions (MIME) Part Four: Registration + Procedures", RFC 2048, November 1996. + + [RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2234] Crocker, D. and P. Overall, "Augmented BNF for Syntax + Specifications: ABNF", RFC 2234, November 1997. + + [RFC2303] Allocchio, C., "Minimal PSTN Address Format in Internet + Mail", RFC 2303, March 1998. + + [RFC2304] Allocchio, C., "Minimal FAX Address Format in Internet + Mail", RFC 2304, March 1998. + + + + + + +Vaha-Sipila Standards Track [Page 18] + +RFC 2806 URLs for Telephone Calls April 2000 + + + [RFC2396] Berners-Lee, T., R. Fielding and L. Manister, "Uniform + Resource Identifiers (URI): Generic Syntax", RFC 2396, + August 1998. + + [RFC2543] Handley, M., Schulzrinne, H., Schooler, E. and J. + Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, + March 1999. + + [E.123] ITU-T Recommendation E.123: Telephone Network and ISDN + Operation, Numbering, Routing and Mobile Service: Notation + for National and International Telephone Numbers. 1993. + + [E.164] ITU-T Recommendation E.164/I.331 (05/97): The International + Public Telecommunication Numbering Plan. 1997. + + [T.33] ITU-T Recommendation T.33: Facsimile Routing Utilizing the + Subaddress. 1996. + +5. Security Considerations + + It should be noted that the local entity SHOULD NOT call out without + the knowledge of the user because of associated risks, which include + + - call costs (including long calls, long distance calls, + international calls and premium rate calls, or calls which do not + terminate due to <post-dial> sequences that have been left out by + the local entity) + + - wrong numbers inserted on web pages by malicious users, or sent via + e-mail, perhaps in direct advertising + + - making the user's phone line unavailable (off-hook) for a malicious + purpose + + - opening a data call to a remote host, thus possibly opening a back + door to the user's computer + + - revealing the user's (possibly unlisted) phone number to the remote + host in the caller identification data, and correlating the local + entity's phone number with other information such as the e-mail or + IP address + + - using the same local number in different contexts, in which the + number may have a different meaning + + All of these risks MUST be taken into consideration when designing + the local entity. + + + + +Vaha-Sipila Standards Track [Page 19] + +RFC 2806 URLs for Telephone Calls April 2000 + + + The local entity SHOULD have some mechanism that the user can use to + filter out unwanted numbers. The local entity SHOULD NOT use rapid + redialing of the number if it is busy to avoid the congestion of the + (signaling) network. Also, the local entity SHOULD detect if the + number is unavailable or if the call is terminated before the dialing + string has been completely processed (for example, the call is + terminated while waiting for user input) and not try to call again, + unless instructed by the user. + +6. Acknowledgements + + Writing this specification would not have been possible without + extensive support from many people. + + Contributors include numerous people from IETF FAX, PINT, URI and + URLREG mailing lists, as well as from World Wide Web Consortium and + several companies, plus several individuals. Thanks to all people who + offered criticism, corrections and feedback. + + All phone numbers and company names used in the examples of this + specification are fictional. Any similarities to real entities are + coincidental. + +7. Author's Address + + Antti Vaha-Sipila + (quoted-printable: Antti V=E4h=E4-Sipil=E4) + Nokia Mobile Phones + P. O. Box 68 + FIN-33721 Tampere + Finland + + EMail: avs@iki.fi + antti.vaha-sipila@nokia.com + + + + + + + + + + + + + + + + + +Vaha-Sipila Standards Track [Page 20] + +RFC 2806 URLs for Telephone Calls April 2000 + + +8. Full Copyright Statement + + Copyright (C) The Internet Society (2000). 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. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Vaha-Sipila Standards Track [Page 21] + |