GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc2806

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)

1)
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:
  1. 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.
  1. By DTMF. These are the 'beeps' that you hear when you dial on
most phones.
  1. 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
  1. 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)
  1. wrong numbers inserted on web pages by malicious users, or sent via
e-mail, perhaps in direct advertising
  1. making the user's phone line unavailable (off-hook) for a malicious
purpose
  1. opening a data call to a remote host, thus possibly opening a back
door to the user's computer
  1. 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
  1. 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]
/data/webs/external/dokuwiki/data/pages/rfc/rfc2806.txt · Last modified: 2000/04/26 16:15 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki