As per Relevance of the word national, we have this rfc below:
Network Working Group A. Vaha-
Request for Comments: 2806
Category: Standards Track April 2000
URLs for Telephone
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
This document specifies URL (Uniform Resource Locator) schemes "tel",
"fax" and "modem" for specifying the location of a terminal in
phone network and the connection types (modes of operation) that
be used to connect to that entity. This specification covers
calls (normal phone calls, answering machines and voice
systems), facsimile (telefax) calls and data calls, both for POTS
digital/mobile subscribers
Table of
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.
1.1 New URL
This specification defines three new URL schemes: "tel", "fax"
"modem". They are intended for describing a terminal that can
contacted using the telephone network. The description includes
subscriber (telephone) number of the terminal and the
parameters to be able to successfully connect to that terminal
The "tel" scheme describes a connection to a terminal that
normal voice telephone calls, a voice mailbox or another
messaging system or a service that can be operated using DTMF tones
The "fax" scheme describes a connection to a terminal that can
telefaxes (facsimiles). The name (scheme specifier) for the URL
"fax" as recommended by [E.123].
The "modem" scheme describes a connection to a terminal that
handle incoming data calls. The term "modem" refers to a device
does digital-to-analog and analog-to-digital conversions; in
to these, a "modem" scheme can describe a fully digital connection
The notation for phone numbers is the same which is specified
[RFC2303] and [RFC2304]. However, the syntax definition is a
different due to the fact that this document specifies URLs
[RFC2303] and [RFC2304] specify electronic mail addresses.
example, "/" (used in URLs to separate parts in a hierarchical
[RFC2396]) has been replaced by ";". In addition, this URL scheme
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
the minimum, unless this would make the context of use unclear
Having a short URL is especially important if the URL is intended
be shown to the end user, printed, or otherwise distributed so
it is visible
1.2 Formal
The ABNF (augmented Backus-Naur form) notation used in
definitions follows [RFC2234]. This specification uses elements
the 'core' definitions (Appendix A of [RFC2234]). Some elements
been defined in previous RFCs. If this is the case, the RFC
question has been referenced in comments
Note on non-unreserved characters [RFC2396] in URLs: the ABNF in
document specifies strings of raw, unescaped characters. If
characters are present in a URL, and are not unreserved [RFC2396],
they MUST be escaped as explained in [RFC2396] prior to using
URL. In addition, when parsing a URL, it must be noted that
characters may have been escaped
An example: ABNF notation "%x20" means a single octet with
hexadecimal value of "20" (in US-ASCII, a space character). This
be escaped in a URL, and it becomes "%20".
In addition, the ABNF in this document only uses lower case. The
are case-insensitive (except for the extension> parameter
whose case-sensitivity is application-specific).
1.3
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
document are to be interpreted as described in [RFC2119].
Compliant software MUST follow this specification
2. URL schemes for telephone
2.1
In this document, "local entity" means software and hardware that
detect and parse one or more of these URLs and possibly place a
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
using the telephone network, or as a method to transfer or store
phone number plus other relevant data. The network in question may
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
phone network differentiates between (for example) voice and
calls, or if the local entity has several
telecommunications equipment at its disposal, it is possible
specify which kind of call (voice/fax/data) is requested. The URL
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
hierarchical URL syntax; there are no applicable relative URL forms
The URLs are always case-insensitive, except for the
extension> parameter (see below), whose case-sensitivity
application specific. Characters in the URL MUST be escaped
needed as explained in [RFC2396].
2.2 "tel" URL
The URL syntax is formally described as follows. For the basis
this syntax, see [RFC2303].
telephone-url = telephone-scheme ":"
telephone-
telephone-scheme = "tel
telephone-subscriber = global-phone-number / local-phone-
global-phone-number = "+" base-phone-number [isdn-subaddress
[post-dial] *(area-specifier /
service-provider / future-extension
base-phone-number = 1*
local-phone-number = 1*(phonedigit / dtmf-digit /
pause-character) [isdn-subaddress
[post-dial] area-
*(area-specifier / service-provider /
future-extension
isdn-subaddress = ";isub=" 1*
post-dial = ";postd=" 1*(phonedigit /
dtmf-digit / pause-character
area-specifier = ";" phone-context-tag "=" phone-context-
phone-context-tag = "phone-context
phone-context-ident = network-prefix / private-
network-prefix = global-network-prefix / local-network-
global-network-prefix = "+" 1*
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
; 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-
provider-tag = "tsp
provider-hostname = 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
; as explained in [RFC2396]
; See sections 1.2 and 2.5.11
quoted-string = %x22 *( "\" CHAR / (%x20-21 / %x23-7
/ %x80-FF )) %x22
; Characters in URLs must follow escaping
; as explained in [RFC2396]
; See sections 1.2 and 2.5.11
phonedigit = DIGIT / visual-
visual-separator = "-" / "." / "(" / ")"
pause-character = one-second-pause / wait-for-dial-
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
that what follows is a URL that should be parsed as described in
document. After that, the URL contains the phone number of the
entity. Phone numbers can also contain subaddresses, which are
to identify different remote entities under the same phone number.
a subaddress is present, it is appended to the phone number
";isub=". Phone numbers can also contain a post-dial sequence.
is what is often used with voice mailboxes and other services
are controlled by dialing numbers from your phone keypad while
call is in progress. The sequence describes what and
the local entity should send to the phone line
Phone numbers can be either "global" or "local". Global numbers
unambiguous everywhere. Local numbers are usable only within
certain area, which is called "context", see section 2.5.2.
Local numbers always have an , which specifies
context in which the number is usable (the same number may
different interpretation in different network areas). The context
be indicated with three different prefixes. A
indicates that the number is valid within a numbering area
global numbers start with . Similarly
means that the number is valid within
Vaha-Sipila Standards Track [Page 5]
RFC 2806 URLs for Telephone Calls April 2000
numbering area whose numbers (or dial strings) start with it.
is a name of a context. The local entity must
knowledge of this private context to be able to deduce whether it
use the number, see section 2.5.2. Additional information about
phone number's usage can be included by adding the name of
telephony services provider in provider>, see
2.5.10.
The extension> mechanism makes it possible to add
parameters to this URL scheme. See section 2.5.11.
The , and
may seem a bit complex at first, but they simply describe the set
octets that are legal in those nonterminals. Some octets may have
be escaped, see [RFC2396].
2.3 "fax" URL
The URL syntax is formally described as follows (the
reuses nonterminals from the above definition). For the basis of
syntax, see [RFC2303] and [RFC2304].
fax-url = fax-scheme ":" fax-
fax-scheme = "fax
fax-subscriber = fax-global-phone / fax-local-
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-
*(area-specifier / service-provider /
future-extension
t33-subaddress = ";tsub=" 1*
The fax: URL is very similar to the tel: URL. The main difference
that in addition to ISDN subaddresses, telefaxes also have an
type of subaddress, see section 2.5.8.
2.4 "modem" URL
The URL syntax is formally described as follows (the
reuses nonterminals from the above definitions). For the basis
this syntax, see [RFC2303].
Vaha-Sipila Standards Track [Page 6]
RFC 2806 URLs for Telephone Calls April 2000
modem-url = modem-scheme ":" remote-
modem-scheme = "modem
remote-host = telephone-subscriber *(modem-
/ recommended-params
modem-params = ";type=" data-
recommended-params = ";rec=" data-
data-capabilities = accepted-modem ["?" data-bits
stop-bits
accepted-modem = "V21" / "V22" / "V22b" /
"V23" / "V26t" / "V32" /
"V32b" / "V34" / "V90" /
"V110" / "V120" / "B103" /
"B212" / "X75" /
"vnd." vendor-name "." modem-
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
remote entity. Minimum required compliance is listed in
params> and recommended compliance is listed in <recommended-params>.
For details, see section 2.5.9.
2.5 Parsing telephone, fax and modem
2.5.1 Call
The type of call is specified by the scheme specifier. "Tel"
that a voice call is opened. "Fax" indicates that the call should
a facsimile (telefax) call. "Modem" means that it should be a
call. Not all networks differentiate between the types of call;
this case, the scheme specifier indicates the
equipment type to use
2.5.2 Phone numbers and their
<telephone-subscriber> and subscriber> indicate the phone
to be dialed. The phone number can be written in either
or local notation. All phone numbers SHOULD always be written in
international form if there is no good reason to use the local form
Not all numbers are valid within all numbering areas. The
specifier> parameter, which is mandatory for local numbers, is
to indicate the locale within which this number is valid, or
qualify the phone number so that it may be used unambiguously.
Vaha-Sipila Standards Track [Page 7]
RFC 2806 URLs for Telephone Calls April 2000
can take three forms: ,
or . These are used
describe the validity area of the phone number either in
numbering plan, local numbering plan, or in a private numbering plan
respectively
If is present, the local entity MUST NOT attempt
call out using the phone number if it cannot originate the
within the specified locale. If a is used,
MUST be included as well
There can be multiple instances of . 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
for a phone number, so it will start with a "+", followed by
part of an E.164 number. It also specifies the region in which
phone number is valid. For example, if
"+358", the given number is valid only within Finland (country
358) - even if it is a .
The local prefix form is intended to act as an intermediate
in those situations where the outermost context for a phone number
given by another means. One example of use is where the local
is known to originate calls only within the North American
Plan Area, so an "outermost" phone context can be assumed. The
context could, for example, be used to indicate the area code
which an associated phone number is situated. Thus "tel:456-
7890;phone-context=213" would suffice to deliver a call to
telephone number "+1-213-456-7890". Note that the version
the implies further that the call can only
originated within the "area code 213" region
The form is intended for use in those
where the context cannot be expressed with a start of a global
number or a dialing string. The is actually a
of a private context. The creator of the URL and the local
have been configured to recognize this name, and as such they
interpret the number and know how they can utilize the number.
example, a private network numbering plan may be indicated by
name "X-COMPANY-NET", but the private dialling plan from the
of the sender of the telephony URL and the local entity
different. The syntax of these tokens will be left for
specification. The ABNF above specifies the accepted characters
can be a part of .
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
network access digit string with the local entity, then they MUST
use a dialling plan number (a local phone number, or one qualified
a local context), as the result may be incorrect. Instead,
SHOULD use a global number, or if that is not possible, a
context as the last resort. If the local entity does not
dialling into the private network indicated by that context, then
request MUST be rejected. If it does, then it will use the
digit string appropriate for its locale
Note that the use of is orthogonal to use of
telephony service provider parameter (see 2.5.10); it qualifies
phone number, whilst the provider> parameter indicates
carrier to be used for the call attempt
For example, a large company may have private
interconnections between its sites, as well as connections to
Global Switched Telephone Network. A phone number may be given
"public network" form, but with a provider> indicating
the call should be carried over the corporate network
Conversely, it would be possible to represent a phone number
private network form, with a private context to indicate this,
indicate a public telephony service provider. This would request
the user agent convert the private network number plan address into
form that can be carried using the selected service provider
Any telephone number MUST contain at least one
, that is, subscriber numbers consisting only of
characters are not allowed
International numbers MUST begin with the "+" character.
numbers MUST NOT contain that character. International numbers
be written with the country (CC) and national (NSN) numbers
specified in [E.123] and [E.164]. International numbers have
property of being totally unambiguous everywhere in the world if
local entity is properly configured
Local numbers MAY be used if the number only works from inside
certain geographical area or a network. Note that some numbers
work from several networks but not from the whole world -
SHOULD be written in international form, with a set of
specifier> tags and optional provider> parameters.
containing local phone numbers should only appear in an
where all local entities can get the call successfully set up
passing the number to the dialing entity "as is". An example could
a company intranet, where all local entities are located under a
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
of the context in which they are intended to be used, and
appropriate SHOULD be present in the URL
In some regions, it is popular to write phone numbers
alphabetic characters which correspond to certain numbers on
telephone keypad. Letters in characters do not
anything to do with this, nor is this method supported by these
schemes
It should also be noted that implementations MUST NOT assume
telephone numbers have a maximum, minimum or fixed length, or
they would always begin with a certain number. Implementors
encouraged to familiarize themselves with the
standards
2.5.3 Separators in phone
All characters MUST be ignored by the local
when using the URL. These characters are present only to
readability: they MUST NOT have any other meaning. Note that
[E.123] recommends the use of space (SP) characters as the
in printed telephone numbers, spaces MUST NOT be used in
numbers in URLs as the space character cannot be used in URLs
escaping it
2.5.4 Converting the number to the local numbering
After the telephone number has been extracted, it can be converted
the local dialing convention. (For example, the "+" character
be replaced by the international call prefix, or the
and trunk prefixes might be removed to place a local call.)
that have been specified using or
MUST be used by the local entity "as is", without any conversions
unless the local entity decides to utilize the information in
optional provider> parameter
2.5.5 Sending post-dial sequence after call
The number may contain a sequence, which MUST be
using Dual Tone Multifrequency (DTMF) in-band signalling or
dialing after the call setup is complete. If the user agent does
support DTMF or pulse dialing after the call has been set up,
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
A local phone number or a post-dial sequence may contain
character> characters which indicate a pause while dialing ("p"),
a wait for dial tone ("w").
Local entities MAY support this method of dialing, and the
interpretation of these characters is left to the local entity.
is RECOMMENDED that the length of each pause is about one second
If it is not supported, local entities MUST ignore everything in
dial string after the first character> and the user SHOULD
notified. The user or the local entity MAY opt not to place a call
this feature is not supported and these characters are present in
URL
Any characters and all dial string characters after
first character> or SHOULD be sent to line
DTMF (Dual Tone Multifrequency) in-band signaling, even if dialing
done using direct network signaling (a digital subscriber loop or
mobile phone). If the local infrastructure does not support
codes, the local entity MAY opt to use pulse dialing. However,
should be noted that certain services which are controlled using
tones cannot be controlled with pulse dialing. If pulse dialing
used, the user SHOULD be notified
2.5.7 ISDN
A phone number MAY also contain an which
an ISDN subaddress. The local entity SHOULD support
subaddresses. These addresses are sent to the network by using
method available to the local entity (typically, ISDN
send the address with the call setup signalling). If
subaddressing is not supported by the caller,
be ignored and the user SHOULD be notified. The user or the
entity MAY opt not to place a call if this feature is not supported
2.5.8 T.33
A fax number MAY also contain a , which indicates
start of a T.33 subaddress [T.33]. Local entities SHOULD
this. Otherwise MUST be ignored and the user
be notified. The user or the local entity MAY opt not to place a
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
indicate the minimum compliance required from
local entity to be able to connect to the remote entity. The
compliance is defined as being equal to or a superset of
capabilities of the listed modem type. There can be several
param> parameters, in which case compliance to any one of them
be accepted. <recommended-params> indicates the
compliance required from the local entity. This is typically
fastest and/or the most reliable modem type supported by the
pool. The local entity can use this information to select the
number from a group of modem URLs. There can be several
modem types, which are equally desirable from the modem pool's
of view. <recommended-params> MAY NOT conflict with .
If they do, the local entity MUST ignore the <recommended-params>.
The local entity MUST call out using compatible hardware, or
that the network provides such a service
For example, if the local entity only has access to a V.22bis
and the URL indicates that the minimum acceptable connection
V.32bis, the local entity MUST NOT try to connect to the remote
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
V.32bis to create a connection since V.32bis is a superset of V.32.
This feature is present because modem pools often have
numbers for slow modems and fast modems, or have different
for analog and ISDN connections, or may use proprietary modems
are incompatible with standards. It is somewhat analogous to
connection type specifier (typecode) in FTP URLs [RFC1738]:
provides the local entity with information that can not be
from the scheme specifier, but is helpful for successful operation
This also means that the number of data and stop bits and parity
be set according to the information given in the URL, or to
values given in this document, if the information is not present
The capability tokens are listed below. If capabilities suggest
it is impossible to create a connection, the connection MUST NOT
created
If new modem types are standardized by ITU-T, this list can
extended with those capability tokens. Tokens are formed by
the number of the standard and joining together the first letter (
example, "V"), number (for example, 22) and the first letter of
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
tree', which takes the form "vnd.x.y", in which "x" is the name
the entity from which the specifications for the modem type can
acquired and "y" is the type or model of the modem. Vendor names
share the same name space with vendor names used in MIME
[RFC2048]. Submitting the modem types to ietf-types list for
is strongly recommended
New capabilities MUST always be documented in an RFC, and they
refer to this document or a newer version of it. The
SHOULD also list the existing modem types with which the
defined modem type is compatible with
Capability
V21 ITU-T V.21
V22 ITU-T V.22
V22b ITU-T V.22
V23 ITU-T V.23
V26t ITU-T V.26
V32 ITU-T V.32
V32b ITU-T V.32
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
specified, defaults to "8".
Parity: "n", "e", "o", Parity. None, even, odd, mark
"m", "s" space parity, respectively.
not specified, defaults to "n".
Stop bits: "1" or "2" The number of stop bits. If
specified, defaults to "1".
2.5.10 Telephony service provider
It is possible to indicate the identity of the telephony
provider for the given phone number. provider> MAY be
by the user-agent to place the call using this network, to
the user interface, for billing estimates or to otherwise
its functionality. It MAY also be ignored by the user-agent
provider> consists of a fully qualified Internet domain
of the telephony service provider, for
";tsp=terrifictelecom.com". The syntax of the domain name
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
In addition to T.33 and ISDN subaddresses, modem types and
specifiers, future extensions to this URL scheme may add
additional parameters (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
parameters gracefully. Implementations MUST NOT use the URL if
contains unknown parameters, as they may be vital for the
interpretation of the URL. Instead, the implementation SHOULD
an error
For example, extension> can be used to store application
specific additional data about the phone number, its intended use,
any conversions that have been applied to the number. Whenever
extension> is used in an open environment, its syntax
usage MUST be properly documented in an RFC
extension> nonterminal a rephrased version of, and
with the as defined in [RFC2543] (which
borrows BNF from an earlier version of this specification).
2.6 Examples of
tel:+358-555-1234567
This URL points to a phone number in Finland capable of
voice calls. The hyphens are included to make the number more human
readable: country and area codes have been separated from
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
effect on the functionality
modem:+3585551234567;type=v32b?7e1;type=v110
This phone number belongs to an entity which is able to receive
calls. The local entity may opt to use either a ITU-T V.32bis
(or a faster one, which is compatible with V.32bis), using
of 7 data bits, even parity and one stop bit, or an ISDN
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
+358-555-1234567, then wait for an implementation-dependent time (
example, two seconds) and emit two DTMF dialing tones "2" on the
(for example, to choose a particular extension number, or to invoke
particular service).
tel:0w003585551234567;phone-context=+3585551234
This URL places a voice call to the given number. The number
is intended for local use: the first zero opens an outside line,
"w" character waits for a second dial tone, and the number
has the international access code appended to it ("00"). This kind
phone number MUST NOT be used in an environment where all users
this URL might not be able to successfully dial out by using
number directly. However, this might be appropriate for pages in
company intranet. The which is present hints
the number is usable only in an environment where the local entity'
phone number starts with the given string (perhaps singling out
company-wide block of telephone numbers).
tel:+1234567890;phone-context=+1234;vnd.company.option=
The URL describes a phone number which, even if it is written in
international form, is only usable within the numbering area
phone numbers start with +1234. There is also a proprietary
"vnd.company.option", which has the value "foo". The meaning of
extension is application-specific. Note that the order of
parameters (phone-context and vnd.company.option) is irrelevant
2.7 Rationale behind the
2.7.1 Why distinguish between call types
URLs locate resources, which in this case is some
equipment at a given phone number. However, it is not
enough to know the subscriber number in order to
communicate with that equipment. Digital phone networks
between voice, fax and data calls (and possibly other types of calls
not discussed in this specification). To be able to
connect to, say, a fax machine, the caller may have to specify that
fax call is being made. Otherwise the call might be routed to
voice number of the subscriber. In this sense, the call type is
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
the URL simple to remember and use. Making it a parameter, much
the way modem parameters are handled now, will substantially
the human readability of this URL
2.7.2 Why "tel" is "tel"?
There has been discussion on whether the scheme name "tel"
appropriate. To summarize, these are the points made against
other proposals
callto URL schemes locate a resource and do not
an action to be taken
telephone Too long. Also, "tel" considered to be a
international form
phone Was countered on the basis that "tel" is
internationally acceptable
2.7.3 Why to use E.164-style numbering
E.164 refers to international telephone numbers, and the string
digits after the country code is usually a national matter. In
case, phone numbers are usually written as a simple string of
everywhere. Because of this, the syntax in this specification
intuitively clear to most people. This is the usual way to
phone numbers in business cards, advertisements, telephone books
so on
It should be noted that phone numbers may have 'hierarchical
characteristics, so that one could build a 'forest' of phone
with country codes as roots, area codes as branches and
numbers as leaves. However, this is not always the case. Not
areas have area codes; some areas may have different area
depending on how one wants to route the call; some numbers
always be dialled "as is", without prepending area or country
(notably emergency numbers); and area codes can and do change
Usually, if something has a hierarchical structure, the URL
should reflect that fact. These URLs are an exception
Also, when writing the phone number in the form described in
specification, the writer does not need to know which part of
number is the country code and which part is the area code. If
hierarchical URL would be used (with a "/" character separating
parts of the phone numbers), the writer of the URL would have to
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
specified here, they are unambiguous and can always be converted
the local dialing convention, given that the user agent has
knowledge of the local country and area codes
2.7.4 Not everyone has the same equipment as
There are several ways for the subscriber to dial a phone number
- By pulse dialing. Typically old telephone exchanges. Usually
dialing method has only to be used to set up the call;
connecting to the remote entity, can be sent to
line using DTMF, because it will typically be processed by
remote entity, not the telephone network
- By DTMF. These are the 'beeps' that you hear when you dial
most phones
- By direct network signalling. ISDN subscribers and mobile
users usually have this. There is no dial tone (or if there is,
is generated locally by the equipment), and the number of
called party is communicated to the telephone network using
network signalling method. After setting up the call,
sequences are usually sent using DTMF codes
2.7.5 Do not confuse numbers with how they are
As an example, +123456789 will be dialled in many countries
00123456789, where the leading "00" is a prefix for
calls. However, if a URL contains a local phone number 00123456789,
the user-agent MUST NOT assume that this number is equal to a
phone number +123456789. If a user-agent received a telephony
with a local number in it, it MUST make sure that it knows
context in which the local phone number is to be processed, or
the number MUST NOT be used. Equally, anyone sending a telephony
MUST take into consideration that the recipient may have
information about the phone number's context
3. Comments on
These are examples of the recommended usage of this URL in
documents
First of all, the number SHOULD be visible to the end user, if it
conceivable that the user might not have a local entity which is
to use these URLs
Telephone: +358-555-1234567
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
always be in the international form, even if the text of the
uses some local format
Telephone: (0555) 1234567
or
For more info, call 1-555-IETF-RULZ
OK.
Moreover, if the number is a , and the scope
the number is not clear from the context in which the URL
displayed, a human-readable explanation SHOULD be included
For customer service, dial 1234 (only from Terrific Telecom
phones).
4.
[RFC1035] Mockapetris, P., "Domain Names - Implementation
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
- 2.0", RFC 1866, November 1995.
[RFC2048] Freed, N., Klensin, J. and J. Postel, "
Internet Mail Extensions (MIME) Part Four:
Procedures", RFC 2048, November 1996.
[RFC2119] Bradner, S., "Key Words for Use in RFCs to
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2234] Crocker, D. and P. Overall, "Augmented BNF for
Specifications: ABNF", RFC 2234, November 1997.
[RFC2303] Allocchio, C., "Minimal PSTN Address Format in
Mail", RFC 2303, March 1998.
[RFC2304] Allocchio, C., "Minimal FAX Address Format in
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, "
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
Operation, Numbering, Routing and Mobile Service:
for National and International Telephone Numbers. 1993.
[E.164] ITU-T Recommendation E.164/I.331 (05/97): The
Public Telecommunication Numbering Plan. 1997.
[T.33] ITU-T Recommendation T.33: Facsimile Routing Utilizing
Subaddress. 1996.
5. Security
It should be noted that the local entity SHOULD NOT call out
the knowledge of the user because of associated risks, which
- call costs (including long calls, long distance calls
international calls and premium rate calls, or calls which do
terminate due to sequences that have been left out
the local entity
- wrong numbers inserted on web pages by malicious users, or sent
e-mail, perhaps in direct
- making the user's phone line unavailable (off-hook) for a
- opening a data call to a remote host, thus possibly opening a
door to the user's
- revealing the user's (possibly unlisted) phone number to the
host in the caller identification data, and correlating the
entity's phone number with other information such as the e-mail
IP
- using the same local number in different contexts, in which
number may have a different
All of these risks MUST be taken into consideration when
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
filter out unwanted numbers. The local entity SHOULD NOT use
redialing of the number if it is busy to avoid the congestion of
(signaling) network. Also, the local entity SHOULD detect if
number is unavailable or if the call is terminated before the
string has been completely processed (for example, the call
terminated while waiting for user input) and not try to call again
unless instructed by the user
6.
Writing this specification would not have been possible
extensive support from many people
Contributors include numerous people from IETF FAX, PINT, URI
URLREG mailing lists, as well as from World Wide Web Consortium
several companies, plus several individuals. Thanks to all people
offered criticism, corrections and feedback
All phone numbers and company names used in the examples of
specification are fictional. Any similarities to real entities
coincidental
7. Author's
Antti Vaha-
(quoted-printable: Antti V=E4h=E4-Sipil=E4)
Nokia Mobile
P. O. Box 68
FIN-33721
EMail: avs@iki.
antti.vaha-sipila@nokia.
Vaha-Sipila Standards Track [Page 20]
RFC 2806 URLs for Telephone Calls April 2000
8. Full Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Vaha-Sipila Standards Track [Page 21]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
