HTTP/1.1 200 OK Date: Mon, 08 Apr 2002 22:33:16 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Tue, 26 Aug 1997 15:33:00 GMT ETag: "2e7d07-4307-3402f72c" Accept-Ranges: bytes Content-Length: 17159 Connection: close Content-Type: text/plain INTERNET-DRAFT A. Vaha-Sipila Expires 28-Feb-1998 Nokia 26-Aug-1997 URLs for Telephony Status of This Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This document specifies a URL (Uniform Resource Locator) scheme 'callto' for specifying a location for an entity 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. Contents 1. Introduction . . . . . . . . . . . . . . . . . . . 1 1.1 New URL Schemes . . . . . . . . . . . . . . . . . 1 1.2 Formal Definitions . . . . . . . . . . . . . . . . 2 1.3 Requirements . . . . . . . . . . . . . . . . . . . 2 2. URL Schemes for Telephone Calls . . . . . . . . . 2 2.1 Applicability . . . . . . . . . . . . . . . . . . 2 2.2 callto URL Scheme . . . . . . . . . . . . . . . . 2 2.3 Parsing a callto URL . . . . . . . . . . . . . . . 4 2.4 Examples of Use . . . . . . . . . . . . . . . . . 6 3. References . . . . . . . . . . . . . . . . . . . . 6 4. Security Considerations . . . . . . . . . . . . . 6 5. Authors' Addresses . . . . . . . . . . . . . . . . 7 1. Introduction 1.1 New URL Schemes A. Vaha-Sipila URLs for Telephony August 1997 INTERNET-DRAFT Expires February, 1998 [Page 2] This specification defines a new URL scheme, callto. It is intended for describing an entity that can be contacted using the telephone network. This URL scheme caters for voice calls (including DTMF based supplementary services), fax (facsimile) calls and data calls. URLs that designate phone or fax numbers that can be dialed have been brought forward in other (currently expired) Internet-Drafts. However, none of these has reached the RFC status. This document tries to remedy the situation. All interested parties are invited to submit comments on this Internet-Draft. Contact information can be found at the end of this document. 1.2 Formal Definitions Rules are separated from definitions by an equal "=", literals are quoted with double quotes "", parentheses "(" and ")" are used to group elements, optional elements are enclosed in "[" and "]" brackets, and a set of elements where order is not significant is enclosed by "{" and "}" (note that this does not imply repetition; only that the elements in that group can appear in any order). Elements may be preceded with n* to designate n repetitions of the following element; n defaults to 0. Single quotes '' are used to indicate elements that are not formally specified and are described in free text instead. Indentation indicates that the definition continues from the previous line. 1.3 Requirements Compliant software MUST follow this specification. Requirements are indicated by capitalized words as specified in [RFC2119]. 2. URL Schemes for Telephone Calls 2.1 Applicability The callto URL scheme is used to direct the user agent to place a call using the telephone network. The network in question may be a landline or mobile phone network. If the phone network differentiates between (for example) voice and data calls, or if the user agent has several different telecommunications equipment at its disposal, it is possible to specify which kind of call (voice/fax/data) is requested. It is also possible to give information about the capabilities of the remote entity. 2.2 callto URL Scheme The callto URL does not have a 'path' in it - it is always absolute. Everything is case-insensitive, expect for the "user-name" and "password", which may be case-sensitive in some environments. Some characters are considered "reserved" and cannot be used in the free text fields (such as "user-name" and "password") without A. Vaha-Sipila URLs for Telephony August 1997 INTERNET-DRAFT Expires February, 1998 [Page 3] escaping them using URL encoding. reserved = " " | ":" | "?" | ";" | "=" The URL syntax is formally described as follows: callto-url = scheme ":" scheme-specific-part scheme = 'callto' scheme-specific-part = subscriber-id [type-specifier] subscriber-id = ["+"] phone-number type-specifier = [";type=" call-type] call-type = "voice" | "data" {[";params=" data-capabilities] [";proto=" protocol-specifier] [";user=" user-name] [";pass=" password]} | "fax" [";params=" facsimile-capabilities] phone-number = 1*phonedigit [pause-character *(phonedigit | dtmf-digit | pause-character)] phonedigit = digit | "-" pause-character = "p" | "w" digit = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" dtmf-digit = "*" | "#" | "A" | "B" | "C" | "D" user-name = 'a user name for authentication; in URL-encoded notation' password = 'a password for authentication; in URL-encoded notation' protocol-specifier = "raw" | "ppp" data-capabilities = modem-type ["?" data-bits parity stop-bits] data-bits = "7" | "8" parity = "n" | "e" | "o" | "m" | "s" stop-bits = "1" | "2" modem-type = "V21" | "V22" | "V22b" | "V23" | "V26" | "V32" | "V32b" | "V34" | "V110" | "V120" | "B103" | "B212" | "X75" facsimile-capabilities = "G1" | "G2" | "G3" | "G4" "Subscriber-id" is the phone number to be dialed. This phone number SHOULD be written in international notation with country (CC) and area (NDC) codes, that is, both ITU-T CC and NSN elements SHOULD be present. International numbers MUST begin with "+", which indicates that the number begins with a country code (CC). Hyphens are only to aid readability; they MUST NOT have any other meaning. Numbers that only work from inside a certain geographical area or from a certain network MUST NOT start with a "+". For the meaning of "p" and "w", see below. "Type-specifier" specifies the call type (which kind of terminal A. Vaha-Sipila URLs for Telephony August 1997 INTERNET-DRAFT Expires February, 1998 [Page 4] equipment is used or what services are requested from the network). If not defined, it defaults to "voice". "Data-capabilities" is an optional field which indicates what kind of entity is answering at the other end. The "modem-type" field is present to indicate the line speed or protocol. The "modem-type" listed should be the one that offers the fastest connection. If several, incompatible modem types are connected to the same number, each of these is listed. Possible modem types are described below. Also, optional information on data bits, parity and stop bits may be provided for each "modem-type". "Proto" is the definition of the protocol that is spoken over the data connection. If not specified, it defaults to "raw", which implies no higher-level protocol at either end (for example a terminal connection). "PPP" tells the user agent (client, caller) to start negotiating a PPP connection with the server. "User-name" and "password" are the credentials used for authenticating the user. These direct the upper-level protocol or session that utilitises the newly created data connection. Use of this information is left to the user agent. When specified in a URL that directs the user agent to create a PPP connection this information SHOULD be used for PPP authentication. In a normal terminal ("raw") connection, this information MAY be utilised by automatic login scripts or a similar purpose. "Facsimile-capabilities" inform the user agent about the remote fax capabilities. These are described below. 2.3 Parsing a callto URL A. The "subscriber-id" is extracted. If it begins with a "+", it is an international number. This kind of a number is converted to the user agent's local format (for example, if the agent is a browser component that dials out, the "+" is replaced by the international call prefix, or if the country code matches the country code of user agent's home country, the "+" and the country code are replaced by a domestic call prefix). A phone number may contain "p" or "w" characters which indicate a pause of 1 second while dialing, or a wait for user input, respectively. User agents SHOULD support this method of dialing. If it is not supported, user agents MUST ignore everything after the "p" or "w" characters. All digits after the first "p" or "w" character MUST 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). B. If there is no "type-specifier" after the "subscriber-id", the user agent MUST open a normal voice call, and if the true nature of the call type can be defined later (for example, modem/fax autodetection), user agent MAY opt to change to the detected mode. A. Vaha-Sipila URLs for Telephony August 1997 INTERNET-DRAFT Expires February, 1998 [Page 5] C. If there is a "type-specifier" after "subscriber-id", the user agent MUST call out using either a suitable terminal equipment (modem, telefax) or request that the network provides such a service. If call type is specified, calls MUST NOT be done in such a way that is incompatible with the recipient entity (such as calling a voice number with a modem, or calling a modem number with a telefax). Type specifiers are "voice" for normal voice call, or a call to a voice mailbox, or a voice messaging service; "fax" for a facsimile (telefax) call; "data" for a data call, with no processing of transferred data implied at either end by default; and data with a "ppp" protocol specifier for a data call where the caller (client) and the callee (server) should begin negotiating a PPP connection after the call has been established. What protocols are negotiated at this phase depends on the user agent's and server's capabilities and configuration. What happens after the call has been established is outside of the scope of this document. D. If there are any parameters after "call-type", the user agent SHOULD parse the remote capabilities, such as the data bits/parity/ stop bits and remote user name and password and adjust itself appropriately. The capability tokens are listed below. If listed capabilities have been parsed and suggest that it is impossible to create a connection, the connection MUST NOT be created. 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 V110 ITU-T V.110 V120 ITU-T V.120 X75 ITU-T X.75 B103 Bell 103 B212 Bell 212 G1 ITU-T T.2 (G1) facsimile G2 ITU-T T.3 (G2) facsimile G3 ITU-T T.4 (G3) facsimile G4 ITU-T T.6 (G4) facsimile 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". Protocol specifier: The higher level protocol to be used "ppp" or "raw" over the raw data stream. If not A. Vaha-Sipila URLs for Telephony August 1997 INTERNET-DRAFT Expires February, 1998 [Page 6] specified, defaults to "raw" which implies that the data stream does not contain any higher level protocol (for example, a terminal connection). "ppp" implies that PPP handshake should be started over the data stream. 2.4 Examples of Use callto:+358-55-1234567 This URL instructs the user agent to place a voice call to the specified number in Finland. The hyphens are included to make the number more human-readable: country and area codes have been separated from the subscriber number. callto:+358-55-1234567;type=fax The above URL instructs the user agent to place a fax call to the specified number. callto:+358-55-1234567;type=data;params=v34?7e1;params=v110 This URL instructs the user agent to place a data call to the specified number. The user agent may opt to use either a ITU-T V.34 modem (or a slower one, which is compatible with V.34), using settings of 7 data bits, even parity and one stop bit, or an ISDN connection using ITU-T V.110 protocol. callto:+358-55-1234567pp22 The above URL instructs the user agent to place a voice call to +358-55-1234567, then wait two seconds and emit two DMTF dialing tones "2" on the line (for example, to choose a particular extension number). (Most Hayes AT compatible modems accept commas "," as the pause characters.) 3. References [RFC1738] Uniform Resource Locators (URL). December 1994. T. Berners-Lee et al. [RFC2119] Key words for use in RFCs to Indicate Requirement Levels. March 1997. S. Bradner. 4. Security Considerations It should be noted that the user agent 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 prime rate calls) A. Vaha-Sipila URLs for Telephony August 1997 INTERNET-DRAFT Expires February, 1998 [Page 7] - wrong numbers inserted on web pages by malicious users - 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 The user agent SHOULD have some mechanism that the user can use to filter out unwanted numbers. The user agent SHOULD NOT use rapid redialing of the number if it is busy to avoid the congestion of (signaling) network. Also, user agent 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. 5. Authors' Addresses Contact person for this specification: Nokia Mobile Phones Antti Vaha-Sipila P. O. Box 68 FIN-33721 Tampere Finland Electronic mail: antti.vaha-sipila@nmp.nokia.com Please include your name and electronic mail address in all communications. If you want to receive the newest version of this specification electronically, send mail to the address above. This document expires on the 28th of February, 1998, or when a new version is released. A. Vaha-Sipila URLs for Telephony August 1997