INTERNET-DRAFT                                           A. Vaha-Sipila
Expires 28-Feb-1998                                               Nokia
                                                            26-Aug-1997


                          URLs for Telephony
                  <draft-antti-telephony-url-00.txt>

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

. 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].

. 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.)

. References

    [RFC1738] Uniform Resource Locators (URL). December 1994. T.
    Berners-Lee et al. <URL:ftp://ftp.ds.internic.net/rfc/rfc1738.txt>

    [RFC2119] Key words for use in RFCs to Indicate Requirement
    Levels. March 1997. S. Bradner.
    <URL:ftp://ftp.ds.internic.net/rfc/rfc2119.txt>

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

. 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