INTERNET-DRAFT                                           Peter Kurrasch
                                                         Motorola, Inc.
                                                       October 21, 1999


                        Tele-Media Address Resolution
                          draft-kurrasch-tmar-00.txt



Status of this Memo

     This document is an Internet-Draft and is in full conformance
     with all provisions of Section 10 of RFC2026.

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

     The list of current Internet-Drafts can be accessed at
       http://www.ietf.org/ietf/1id-abstracts.txt

     The list of Internet-Draft Shadow Directories can be accessed at
       http://www.ietf.org/shadow.html.

Abstract

Tele-Media Address Resolution (TMAR) is a scheme for use with internet
telephony.  The scheme introduces a URL format and protocol that is
simple and flexible yet powerful enough to meet most any
telecommunication need.  The URL takes the form of
tmar://caller:password@host:port/path, where path may be written as a
directory tree or in E.164 notation.  The protocol allows for such
features as customized call routing, call load balancing, and
firewalls to be implemented within an internet telephony network.
This internet-draft contains the requirements, examples, and
recommendations for the implementation of this scheme.

Table of Contents

     1. Introduction and Soapbox  . . . . . . . . . . . .  2
     2. Components and Expectations . . . . . . . . . . .  3
     2.1. The Originating Party . . . . . . . . . . . . .  3
     2.2. The Uniform Resource Locator  . . . . . . . . .  3
     2.3. URL Interpretation and Call Handling Software .  3
     2.4. The Destination Party . . . . . . . . . . . . .  4


Kurrasch                   Expires APR 2000                   [Page 01]


Internet Draft          draft-kurrasch-tmar-00.txt         October 1999


     3. Network Topologies  . . . . . . . . . . . . . . .  4
     3.1. Peer-to-Peer, No Server Resolution  . . . . . .  4
     3.2. Peer-to-Peer, Server-Completed Resolution . . .  5
     3.3. Client-Server-Client  . . . . . . . . . . . . .  5
     3.4. Multiple Servers  . . . . . . . . . . . . . . .  6
     3.5. IP-to-PSTN  . . . . . . . . . . . . . . . . . .  6
     4. TMAR Uniform Resource Locator . . . . . . . . . .  7
     4.1. Syntax  . . . . . . . . . . . . . . . . . . . .  7
     4.2. How to Create a TMAR URL  . . . . . . . . . . .  7
     4.3. URL Examples  . . . . . . . . . . . . . . . . .  8
     5. TMAR Procedures and Requirements  . . . . . . . .  9
     5.1. URL-to-IP Mapping . . . . . . . . . . . . . . . 10
     5.2. TCP Socket and Call Leg Management  . . . . . . 13
     5.3. IP Call Setup . . . . . . . . . . . . . . . . . 15
     5.4. IP Call Monitoring  . . . . . . . . . . . . . . 18
     5.5. IP Call Termination . . . . . . . . . . . . . . 18
     6. Message Structures  . . . . . . . . . . . . . . . 19
     6.1. Call Setup Request  . . . . . . . . . . . . . . 20
     6.2. Call Setup Acknowledge  . . . . . . . . . . . . 21
     6.3. Call Setup Complete . . . . . . . . . . . . . . 22
     6.4. Keep-Alive  . . . . . . . . . . . . . . . . . . 24
     6.5. Call Termination  . . . . . . . . . . . . . . . 25
     7. Security Considerations . . . . . . . . . . . . . 26
     7.1. Weaknesses of this Scheme . . . . . . . . . . . 26
     7.2. Strengths of this Scheme  . . . . . . . . . . . 26
     8. Intellectual Property Rights  . . . . . . . . . . 27
     9. References  . . . . . . . . . . . . . . . . . . . 27
     10. Contact Information  . . . . . . . . . . . . . . 28


1.	Introduction and Soapbox

Tele-Media is a term which is intended to encompass those areas of
telecommunications which are essentially voice-centric but not limited
to voice-only communication.  This tele-media category includes such
activities as video telephony and conference calling in addition to
cellular and fixed-line voice calls.  Tele-media also includes
single-duplex transmissions such as those traditionally broadcast by
radio and television stations.  Note that tele-media does not include
data-only communications such as HTTP, FTP, etc.

That said, the simple goal of the Tele-Media Address Resolution (TMAR)
scheme can be summarized in a single word: connect.  The goal of the
URL and protocol presented in this document is to get people connected
to one-another.  What exactly takes place after the connection has been
established is not so much the concern of this scheme.  Rather, this
scheme sets out to present a unified approach to making those
connections in the first place.

With the TMAR scheme, many commonplace telephony services may be
offered.  Such services include caller ID, call forwarding, and even
directory look-up.  In addition, this scheme enables a service


Kurrasch                   Expires APR 2000                   [Page 02]


Internet Draft          draft-kurrasch-tmar-00.txt         October 1999


provider to offer customizable call routing (over and above call
forwarding) as well as firewalls between separate phone networks.
Perhaps the most promising improvement that this scheme offers is the
ability to place phone calls without actually requiring a phone
number.  That is to say that not only does the calling party need not
know the phone number of the destination party, but the destination
party could very well not have a phone number assigned in the first
place.

2.	Components and Expectations

2.1.  The Originating Party

The originating party is the one who is initiating the phone call.
This party must utilize a piece of computing equipment in order to
place the call.  Such equipment is necessary because the device must
be capable of exchanging signalling data and otherwise exhibit a level
of intelligence that is not possible with a simple telephone regularly
used today.  

Ideally the computing equipment will have HTML-browsing capabilities
built in.  This feature allows for the URL component of this scheme to
be embedded into web pages thereby providing a higher level of
usability than what might be available otherwise.  Because URLs may be
used independent of web pages, however, such HTML browsing
capabilities are not required.

This originating party could be: an individual using a personal
computer at home, a group of people at a business engaging in a
multi-site conference bridge, an individual using an internet-enabled
cellular phone, or someone at an airport or bus terminal using a
kiosk, among many other possibilities.

2.2.  The Uniform Resource Locator

The Uniform Resource Locator (URL) is a convenient means of expressing
the destination party's location.  The structure of the URL for this
scheme is derived from the basic URL syntax as specified in RFC 1738
and, in particular, sections 3.1. and 3.3. of that document.  The URL
itself can be broken down into the following sub-components: URL
scheme prefix; caller's name; caller's password; the destination host
address; a path way describing the ultimate destination the caller
wishes to reach; and some optional parameters.  The URL is thus
summarized as:

tmar://<caller>:<password>@<destination><path>?<options>

Note that not all fields need to be specified.  More details on this
URL are available in subsequent sections.

2.3.  URL Interpretation and Call Handling Software



Kurrasch                   Expires APR 2000                   [Page 03]


Internet Draft          draft-kurrasch-tmar-00.txt         October 1999


The URL interpretation software resides on the originator's host
equipment as well as subsequent computers encountered on the network.
(The actual quantity and location of the networked computers running
this software is implementation specific.)  By utilizing multiple
servers, telephony networks may be deployed which utilize firewalls,
call load balancing, call forwarding, and customized call routing all
based upon where the destination party is located (determined via a
registration scheme) and who the originating party is.  Because not
everyone is part of a multi- server configuration, however, the TMAR
URL scheme does allow for direct connections between parties.  In most
all cases, though, the URL Interpretation software will perform the
URL-to-IP mapping, as specified in greater detail in Section 5.1.

The call handling software works in conjunction with the URL
interpretation software to manage and monitor active calls that are
placed using this scheme.  In addition, the call handling software may
be responsible for any transcoding that is necessary between the
origination and destination parties.  This statement is particularly
true if the software is bridging between an internet and the PSTN.

2.4.  The Destination Party

The destination party is the party which is targeted by the URL.  The
party may actually be a machine or a person.  A machine is a likely
destination for conference bridges, single-duplex broadcasts, or voice
mail answering systems, among many others.  A person is a likely
destination for all other cases, particularly for point-to-point
communications.

The TMAR scheme has provisions for Internet-to-PSTN connections.  As a
result, the destination party is not required to utilize computing
equipment (unlike the originating party).  Certainly, though,
computing equipment which has implemented the TMAR scheme may be used.

3.	Network Topologies

This section discusses some potential network topologies in which this
TMAR scheme could be utilized.  This section addresses only a few,
simple topologies that represent some basic configurations.  This
section is intended only to illustrate the main concepts behind this
scheme and not necessarily to provide a comprehensive discussion of
all possible scenarios.

For all topologies in this section, layers 1 and 2 are not discussed
and do not impact this protocol.  The only expectation is that the IP
protocol stack can reside on top of those layers.

3.1.  Peer-to-Peer, No Server Resolution

This configuration is the simplest configuration in that only two hosts
(origination and destination) are present.  The originating host must
be able to resolve any URL requests into the address of the


Kurrasch                   Expires APR 2000                   [Page 04]


Internet Draft          draft-kurrasch-tmar-00.txt         October 1999


destination host (either the domain name or IP address).  Such
resolution may be accomplished via a table (i.e. URL-to-IP mapping per
Section 5.1.) or if the address is specified as part of the URL
itself.  Note that a router [R] is shown to indicate that zero or more
routers may actually be present between the two hosts.

      [O]-+--------[R]--------+-[D]

   Figure 1:  Simple peer-to-peer configuration.

3.2.  Peer-to-Peer, Server-Completed Resolution

This configuration is similar to the previous one except for the
introduction of a server [S] which is needed to complete the address
resolution.  Since the origination and destination hosts are on a
single IP network, the only roles performed by the server are address
resolution and possible call monitoring (for billing purposes, etc.).
All call traffic may be routed directly between the origination and
destination.  As was the case in Section 3.1., the routers [R] are
shown only to indicate that zero or more routers may be present
between each host in this configuration.

                    [S]
                     |
      [O]-+----[R]---+---[R]----+-[D]

   Figure 2:  Peer-to-peer configuration, standalone server utilized to
	      complete address resolution.

3.3.  Client-Server-Client

This network topology is best illustrated as two independent internets
being bridged by a single server.  To be technically precise, however,
the two networks could, in fact, be one in the same.  The key
difference between this configuration and that presented in Section
3.2. is that in this case the server is also routing the call traffic
between the origination and destination hosts.  Again, zero or more of
the routers [R] may be present between any of the hosts.

This topology presents two advantages over those topologies previously
discussed.  The first advantage is the ability to create firewalls
between different networks.  By routing the call traffic through the
server, the server is able to grant or deny access from the originator
to the destination.  The second advantage is that by routing call
traffic through the server, the server is able to perform voice
transcoding that may not be possible at either the originating or the
destined host.  For example, if the origination host has only A-law
encoding but the destination host has only Mu-law encoding, the server
could be utilized to transcode the A-law into Mu-law speech.

                       [SERVER]
      (a)                |  |


Kurrasch                   Expires APR 2000                   [Page 05]


Internet Draft          draft-kurrasch-tmar-00.txt         October 1999


          [O]-+----[R]---+  +---[R]----+-[D]

                         [S]
      (b)                 |
           [O]-+----[R]---+---[R]----+-[D]

   Figure 3:  Server utilized to bridge connection between origination
	      and destination on either (a) different networks or (b)
	      the same network.

3.4.  Multiple Servers

This topology is an extrapolation of the topologies shown in Figure 3
in that multiple servers must be bridged before the destination is
reached.  As was the case in those networks, the network between the
origination and destination hosts may be implemented as a single
network or as multiple networks.  For brevity, only the multiple
network case is shown in Figure 4.

                 [S1]~~~~[S2]~~~~[S3]
                  |                |
      [O]-+--[R]--+                +--[R]--+-[D]

   Figure 4:  Multiple servers bridging path between origination and
	      destination.

One potential application of this topology is to balance the call load
across multiple servers.  The communication links between the servers
(represented using the tilde character "~") is not explicitly
addressed by this specification.  Ideally, the interface specification
between these servers will be consistent with this specification.
However, situations can easily arise in which a proprietary interface
has its own benefits.

3.5.  IP-to-PSTN

This topology can be considered to be a special case of that in Section
3.4.  For this topology, the additional servers are replaced with a
PSTN.  The signalling required between the server and PSTN is entirely
dependent upon the PSTN interface itself.  This interface may be
anywhere from simple DTMF tone generation to a full-fledged SS7 link.
Note that "PSTN" in this case could also be a locally installed PBX, a
voice mail system, or other telephony equipment.  The tilde character
"~" represents communication links which are implementation-specific
and not addressed by this specification.

                  [S]~~~~[PSTN]
                   |        |
      [O]-+---[R]--+        +~~~~~~[D]

   Figure 5:  Origination part of an internet, Destination part of
	      existing PSTN.


Kurrasch                   Expires APR 2000                   [Page 06]


Internet Draft          draft-kurrasch-tmar-00.txt         October 1999



4.	TMAR Uniform Resource Locator

4.1.  Syntax

Below is the grammar that defines the precise syntax for the TMAR
URL.  This grammar uses the Augmented Backus-Naur Form (ABNF) as
described in RFC 2234 [4], including the core rules listed in Appendix
A of that document.

     tmar_url = "tmar://" [login] [destination] [path] ["?" options]
     login = callername [ ":" password ] "@"
     callername = 1*<VCHAR other than ":" or "@">
     password = 1*<VCHAR other than "@">
     destination = ( hostname / hostaddr ) [ ":" port ]
     hostname = <legitimate hostname using host.network.domain notation>
     hostaddr = ipdig "." ipdig "." ipdig "." ipdig  ; for IPv4
     ipdig = 1*3(DIGIT)  ; valid range is "0" to "255"
     port = 1*DIGIT
     path = tele_num / tele_path
     tele_num = "+" 1*( DIGIT / "(" / ")" / "-" / "." )
     tele_path = "/" *<VCHAR other than "/" or "?"> [ path ]
     options = *CHAR

4.2.  How to Create a TMAR URL

The following flow chart identifies the basic procedure to follow when
specifying a URL.

          put "tmar://" at the beginning of the URL
                          |
                          V
        do you want the other party to see your name? -------+
            |                                                |  "yes"
      "no"  |                                                V
            V                               "yes"        add your name
  is a username/password required to   ----------------> to the URL
  gain access to the telephony network                       |
            |                                                V
      "no"  |                           "no"  is a password required
            V                            +--- to verify your identity?
       do you know the host              |                   | "yes"
  +--- you wish to contact? <--------+   |                   V
  |         |                        |   |        add a `:' followed
  |"no"     | "yes"                  |   |        by your password
  |         V                        |   |                   |
  |   add the host's IP address or   |   |                   V
  |   host.domain name to the URL    |   +------> add a `@' to the URL
  |         |                        |                       |
  |         |                        +-----------------------+
  |         V
  |  do you wish to specify a port?


Kurrasch                   Expires APR 2000                   [Page 07]


Internet Draft          draft-kurrasch-tmar-00.txt         October 1999


  |      |                    |
  |      | "no"               | "yes"
  |      |                    V
  |      |        add a `:' followed by the port number to the URL
  |      |                    |
  |      |                    V
  +------+----------> do you wish to specify a path? ---------+
                            |                                 |
                      "yes" |                                 |
                            V                                 | "no"
        is the path in the form of a telephone                |
        number or directory tree?                             |
                /             \                               |
   "directory" /               \ "phone number"               |
              /                 \                             |
  add the path to the URL,     add the phone number to the    |
  starting with a `/' and      URL starting with a `+' and    |
  using a `/' to separate      writing the number using       |
  the directory names          E.164 notation                 |
            |                        |                        |
            V                        V                        |
           do you wish to specify any options? <--------------+
                  |               |
             "no" |               | "yes"
                  |               V
                  |    add a `?' followed by the options you want
                  |               |
                  |               V
                  +------------> END

   Figure 6:  Flowchart of how to use the TMAR URL scheme.

4.3.  URL Examples

This section contains examples that all illustrate legitimate usages
of this URL specification.  Please note, however, that even though
these URL examples are legitimate syntactically, the ability for a
host to resolve the URL into an IP address is highly dependent upon
the host's configuration.  For more information on the URL-to-IP
address mapping refer to Section 5.1.

tmar://+1-312-555-1212 -- This URL tells the localhost to connect the
caller with the phone number +1-312-555-1212 using a default address
resolution server.

tmar://+1(312)555.1212?reverse_billing=no;language=en -- This URL is
identical to the previous example except that billing and language
options are specified.  (Admittedly, it is not clear exactly what
entity will use such options but they nonetheless are provided.)

tmar://agent_xyz@+1(800)345-6789 -- This URL connects the caller with
the phone number +1(800)345-6789 using a default server.  Further


Kurrasch                   Expires APR 2000                   [Page 08]


Internet Draft          draft-kurrasch-tmar-00.txt         October 1999


"Agent XYZ" is used for caller identification purposes.

tmar://local-telco.com/IL/Chicago/Sears_Tower/skydeck/gift_shop --
This URL instructs the localhost to contact "local-telco.com" to
resolve the tele-media address for the gift shop at the Sears Tower
Skydeck (the observation deck at the top of the Sears Tower in
downtown Chicago).

tmar://182.183.184.185:5555/webmaster/voicemail -- This URL instructs
the localhost to contact the host at address 182.183.184.185, TCP port
5555, to determine where the webmaster's voice mail account resides.

tmar://james_bond:agent007@secret_service.uk/moneypenny -- This URL
identifies the caller as James Bond (password is agent007) and shows
that James wishes to speak with Moneypenny at the British Secret
Service.  Note that the host "secret_service.uk" could choose to grant
or deny access via telephone to Moneypenny based on the caller's
identity.

tmar:// -- This URL represents the simplest format acceptable and
implies that the caller wishes to speak with a "default" person
located at some "default" server.  Such a person could be a network
operator or security officer or helpdesk attendant.  In essence, this
URL is equivalent to the "dial 0 for an operator" facility used in
North America.

tmar://my_server.company.com:8765+1(555)678-1234 -- This URL suggests
that the caller wishes to place a call to +1(555)678-1234 but that the
call should be serviced by the host "my_server.company.com" (and TCP
port 8765 on that host) instead of a default server.  This particular
format is useful for those situations in which tail end hop-off is
desired (i.e.  use the IP network to get closer to the destination
point and then "hop-off" the IP network and use the PSTN to get to the
final destination).

tmar://geneva_office:1234a@conference.com/bridges/motorola/voip_demo?
audio=yes;video=no -- This URL could be utilized when one wishes to
engage in a pre-arranged conference bridge.  This URL identifies the
following all in a single statement: calling party is the Geneva
office; password is 1234a (could be an authorization code provided by
"conference.com"); the service provider (and host to contact) for the
conference bridge is "conference.com"; the actual conference to
participate in is a "voip_demo" set up for Motorola; and finally, this
is to be an audio-only conference.

5.	TMAR Procedures and Requirements

This section focuses on the procedures required by the TMAR scheme for
call handling purposes.  Throughout the remainder of this section, the
following terms are utilized.

originating host -- This host is the machine on which the originating


Kurrasch                   Expires APR 2000                   [Page 09]


Internet Draft          draft-kurrasch-tmar-00.txt         October 1999


party is located.

targeted host -- This host is simply any machine which receives a call
setup request.  This host could be one in the same as the coordinating
host as well as the destination host.  From the originator's
perspective, however, it is better to make a distinction between the
targeted and other hosts in the event that these latter hosts are
behind a firewall or are part of a load-balancing pool.  Note that the
TMAR scheme allows for multiple targeted hosts to be contacted prior
to finding a coordinating or destination host.

coordinating host -- This host is defined as any machine that is
performing coordinating activities between two or more hosts (e.g.
between an originating and destination host).  The coordinating host
is responsible for assigning call reference numbers to the individual
call legs as well as monitoring the call's progress.  In addition,
this host may choose to perform transcoding functions between the
various call legs.  Note that the TMAR scheme allows for multiple
coordinating hosts to be involved in a single call.

destination host -- This host is the machine on which the destination
party is located.  To be technically precise, however, this host
represents only the destination party which is participating in the
TMAR scheme.  If the destination party is on the PSTN or H.323
network, this destination host effectively is ignored.

call leg -- A call leg is defined as a single, independent connection
that is an intrinsic part of the overall call.  For example, in a
peer-to-peer configuration (per Section 3.1. or Section 3.2.) only a
single call leg exists, which is between the originating party and the
destination party.  In a configuration involving a coordinating host
(such as the client-server-client configuration in Section 3.3.), two
call legs are said to exist--one between the originating party and the
coordinating host and another between the coordinating host and the
destination party.

5.1.  URL-to-IP Mapping

In order for call setup to complete, the originating host must first
determine which host to contact as the targeted host.  Furthermore, a
targeted host may itself need to determine which host to contact next.
Because the TMAR URL scheme allows for a host to not be specified, the
originating and targeted hosts may need to perform a mapping of the
URL to an IP address.  If an IP address can not be determined, the
call setup can not proceed.  Once a targeted host has been identified,
call setup may proceed.  Figure 7 gives a high level overview of the
call setup procedure, and in particular indicates where this URL-to-IP
mapping takes place.

     user enters the URL on the originating host
                     |
                     V


Kurrasch                   Expires APR 2000                   [Page 10]


Internet Draft          draft-kurrasch-tmar-00.txt         October 1999


  +-- is a target host specified as part of the URL?
  |                  |
  | "yes"            | "no"
  |                  V
  |       using URL path fragment, can    "no"
  |       a target host be found in the  ------> call setup fails
  |       tele-media address table?
  |                  |
  |                  | "yes"
  |                  V
  +--> send call setup request to the targeted host
                     |
                     V                    "no"
      does the host accept the request?  ------> call setup fails
                     |
                     | "yes"
                     V
       wait for call setup to complete
                     |
                     V                  "no"
        does call setup complete?      ------> call fails
                     |
                     | "yes"
                     V
  call setup is successful, proceed with conversation

   Figure 7:  Simplified flow chart of URL-to-IP mapping during the
	      call setup procedure.

Suggestion 1.	A host that participates in the TMAR scheme should
maintain a table of known tele-media address locations.  The table
must contain at least two fields:  one for the destination address and
one for a URL path fragment.

This first suggestion is only a suggestion (and not a requirement)
because certain applications may arise during the deployment of the
TMAR scheme in which originating hosts should allow only URLs that
contain destination hosts.  One possible situation is for those
networks in which security is a consideration.  By utilizing only URLs
with hosts in them, an advantage may be attained by ensuring that
originating hosts are communicating only with known destination hosts
for call completion purposes.  In any event, should a host choose to
implement this tele-media address location table, the following
requirements must also be implemented.

Requirement 1.	The "address" field for the table in Suggestion 1.
must be either a hostname (e.g.  server.net) or a raw IP address (e.g.
127.128.129.130) as well as the TCP port number to use when contacting
that host.  Note that "localhost" or "127.0.0.1" should be used for
those URL path fragments that are to be resolved by the local machine.

Requirement 2.	The "URL path fragment" field for the table in


Kurrasch                   Expires APR 2000                   [Page 11]


Internet Draft          draft-kurrasch-tmar-00.txt         October 1999


Suggestion 1.  must be NULL or must start with either a slash "/" or
plus "+".  A NULL indicates the corresponding address is considered a
"default" host.  A slash indicates a directory path is given.  A plus
indicates the path fragment is specified using the E.164 notation.

Requirement 3.	Only one entry in the table identified in Suggestion
1. may contain a NULL URL path fragment.  In other words, the table
may contain only one default host.  This entry may be referred to as
the default entry.

Requirement 4.	When examining URL path fragments, a host machine must
match the fragment that is either identical or most similar to a given
URL before matching a fragment that is less similar.  In other words,
if the URL path is given as "+1-999-789-1234" the host shall match the
fragment "+1-999-78" before matching the fragment "+1-999".

Requirement 5.	If a more suitable match can not be found (per
Requirement 4.) and a default entry is specified, the host must use
this default host to complete the address resolution.

Requirement 6.	When examining URL path fragments, a host machine must
ignore all non-alphanumeric characters (except for the slash character
"/") and ignore differences in case.  This requirement is stipulated
to avoid potential problems from occurring when a user uses a
different case or a different symbol from the one stored within a host.

With respect to these requirements, note that no stipulation is made
as to how a host should store this table of known tele-media address
locations.  In particular, it is noteworthy that Requirement 6. does
not oblige the host to store path fragments without the offending
characters.  Notice, too, that no stipulation is made as to how this
table is to be populated with known addresses.  Such details are left
for implementation considerations.  One suggestion, however, is made:

Suggestion 2.	A host should provide a means to view the entries
stored in the tele-media address location table.  Such a means may not
be desirable, for example, in those environments in which security is
a consideration.

To illustrate the usage of these requirements, consider a table which
has the following entries:

  address:port           URL path fragment
  ---------------------	 -------------------------------
  myphone.com:555        "/IL/Chicago"
  searstower.com:555     "/IL/Chicago/SearsTower"
  192.193.194.195:196    "/"
  127.0.0.1:555          "+"
  127.128.129.130:555    "+1-999-78"
  myfriend.net:555       "+1-999-123-4567"
  bogus_entry.com:435    "ddd"
  default_entry.net:555  ""


Kurrasch                   Expires APR 2000                   [Page 12]


Internet Draft          draft-kurrasch-tmar-00.txt         October 1999



Because of Requirement 4., ordering of the entries is not important.
If the user gives a URL path as "/IL/Chicago/sears_tower/skydeck/
gift_shop", the host will contact TCP port 555 at "searstower.com" to
completely resolve the tele-media address.  Notice that Requirement
6.  allows for "SearsTower" to be given as "sears_tower".

If the user gives a URL of "+1-999-789-1234", the host will contact
TCP port 555 on the host at IP address 127.128.129.130.  One likely
example where this would prove useful is in an office environment
which allows users to call each other by specifying only the last 5
digits of the phone number.  In this case, the address
"127.128.129.130" could represent the IP address of a locally-
installed PBX which is prepared to handle this dialing convention.  If
the user were instead to call "+1-999-555-1212", that number is not
part of the local dialing environment so the address resolution is
left to the localhost (i.e. port 555 at IP address 127.0.0.1) instead
of the PBX.

This table contains 3 entries which serve as catch-alls should no
other path fragments match the user's URL.  If the URL is given as a
path, the "/" entry will match and the host corresponding to IP
address 192.193.194.195 (and port 196 of that host) is contacted to
complete the tele-media address resolution.  If the URL is given in
the E.164 notation, the "+" entry will match and port 555 of the
localhost (IP address 127.0.0.1) is used to complete the addressing.
This last example could prove useful if the given host is connected to
a PSTN and capable of establishing a phone call (either by generating
DTMF tones or via a signalling link such as SS7).

The third catch-all entry is the one with a NULL path fragment.  Per
Requirement 2. and Requirement 5., this entry is called the default
entry and is to be used if no other entries match.  Since this table
has an entry for both the "/" and "+" notations, the only URL that
will ever utilize this default entry is "tmar://".  Notice that the
URLs "tmar://" and "tmar:///" match to two different entries
(default_entry.net and 192.193.194.195, respectively).

This table also contains an entry which serves no useful purpose--the
entry with a path fragment of "ddd".  Per Requirement 2., a URL path
fragment must begin with "/" or "+" or simply be NULL.  As such, no
URL should ever match "ddd" and thus the entry should never be used.

5.2.  TCP Socket and Call Leg Management

A basic problem for any telecommunications system is associating call
signalling with a particular call leg (i.e. connection-oriented
signalling).  For the TMAR scheme, call signalling is accomplished
using TCP socket connections.  Given the nature of these connections,
it is possible for a host to uniquely determine what call signalling
originated from which host and with which call leg the signalling is
associated.


Kurrasch                   Expires APR 2000                   [Page 13]


Internet Draft          draft-kurrasch-tmar-00.txt         October 1999



Consider the case of a simple peer-to-peer configuration, such as that
shown in Section 3.1., in which a single call leg is established
between the originator and the destination.  In this configuration
only a single TCP connection need be established to handle the
signalling.  Because only these two hosts are involved in the
conversation, any signalling that is exchanged across this connection
is understood to be associated with the call leg.  As long as the TCP
connection remains active, the call leg itself does not require a
unique identification.

In a larger network, however, keeping a TCP connection open for the
duration of a call may be undesirable or even impossible due to
performance constraints of the individual hosts.  Thus, a need arises
to uniquely identify the call legs so that signalling may remain
connection-oriented even though the signalling connection itself may
be transient.  To address this problem, the TMAR scheme provides for
call legs to be uniquely identified using a call reference number.

The call reference number is a 32-bit value which is included in all
TMAR messaging.  Rules on its use in conjunction with TCP socket
connections are as follows:

Requirement 7.	A TCP socket connection must be established between
hosts prior to sending a call setup request.

Requirement 8.	Each call setup request must utilize a call reference
number of zero.  A targeted host must reject a call setup request that
contains a non-zero call reference number.

* For further study * The TMAR scheme should offer provisions to allow
a URL (and subsequent call setup request) to be given for a call
already in session.  Such provisions would offer real-time control of
the call session to the callers.  For example, if the call is in
session and a caller wishes to add video services, it would be
convenient to specify that as part of the URL.  Another example is if
a caller wishes to add another party to the conversation (i.e.
three-way calling), specifying that desire within a URL would be most
convenient.  However, such provisions are not specified at this time.

Requirement 9.	If the TCP socket connection between hosts is broken
at any point prior to a call reference number being established for a
call leg, the call is considered to have failed and must be handled
accordingly.

For added emphasis, note that Requirement 9. dictates that a TCP socket
connection may not be broken until at least the call setup acknowledge
message has been received.  Furthermore, if the TCP connection is
broken at any time prior to a call terminate, the call must be treated
as a failed call.

Requirement 10.	If a call reference number is to be utilized for a


Kurrasch                   Expires APR 2000                   [Page 14]


Internet Draft          draft-kurrasch-tmar-00.txt         October 1999


call leg, the number is to be determined by that host which sends the
call setup acknowledge message.

Requirement 11.	If a call reference number is not specified in the call
setup acknowledge message, a reference number of zero should be used
for all subsequent messages.  A call reference number may not be used
for the duration of that call leg.

Requirement 12.	A host must allow for multiple call legs to be managed
by a single TCP connection.

Note that Requirement 12. is stipulated so that multiple TCP
connections (and the network overhead to establish and maintain those
connections) are not required between heavily-used hosts.  Without
this requirement in place, a separate TCP connection would be need to
be established prior to sending any sort of call leg signalling.
While this requirement does help to optimize network performance,
notice that a host is not required to use only one TCP connection for
call signalling purposes.

5.3.  IP Call Setup

Of the procedures presented in this scheme, certainly call setup is
most important.  The basic principle used behind call setup is similar
to that used by routers and domain name servers.  Essentially, if a
local host knows which host to contact, contact that host; if not,
contact a default host.  The contacted host may, in turn, choose to
contact other hosts until the final destination host is reached.  This
approach is consistent with other telecommunications systems and
provides for a maximum amount of flexibility in the deployment of the
TMAR scheme.

Once the call setup has completed, the TMAR scheme requires that a
session-specific protocol take over to handle the encoding or decoding
needs of the session.  Note, however, that some level of interfacing
is still necessary between the TMAR scheme and the session-specific
call handling for two reasons:  call monitoring and call termination.
Both events are detailed in Section 5.4. and Section 5.5.,
respectively.

As demonstrated in Figure 7, the key to call setup using the TMAR
scheme is identifying the targeted host.  Thus, the following two
requirements are stipulated:

Requirement 13.	When beginning the call setup procedure, if the user
specifies a host within the URL, the originating host must send the
call setup request to that host.  The originating host must not
compare the URL path fragment with any potential entries within the
tele- media address location table.

Requirement 14.	If the originating host must determine where to send
the call setup request, the host must use the tele-media address


Kurrasch                   Expires APR 2000                   [Page 15]


Internet Draft          draft-kurrasch-tmar-00.txt         October 1999


location table, as outlined in Section 5.1.  If a suitable host can
not be found, the call setup request fails and the user must be
notified.

After a suitable host has been identified, the originating host must
establish contact with that targeted host and request that a call be
established.  The message flow diagram in Figure 8 demonstrates this
procedure for a hypothetical network configuration involving four
hosts.

  originating          targeted         coordinating       destination
     host                host               host               host
      |                   |                  |                  |
      |<--[open socket]-->|                  |                  |
      |                   |                  |                  |
      |--call setup req-->|                  |                  |
      |                   |<-[open socket]-->|                  |
      |                   |                  |                  |
      |                   |--call setup req->|                  |
      |                   |                  |                  |
      |                   |        [   call reference   ]       |
      |                   |        [number determination]       |
      |                   |                  |                  |
      |                   |<-call setup ack--|                  |
      |<--call setup ack--|                  |                  |
      |                   |                  |                  |
      |<-[close socket]-->|<-[close socket]->|                  |
      |                   |                  |<-[open socket]-->|
      |                   |                  |                  |
      |                   |                  |-call setup req-->|
      |                   |                  |                  |
      |                   |                  |        [call ref num ]
      |                   |                  |        [determination]
      |                   |                  |                  |
      |                   |                  |<-call setup ack--|
      |<------------[open socket]----------->|                  |
      |                   |                  |                  |
      |<-----call setup complete-------------|-call setup comp->|
      |                   |                  |                  |
      |<-----------[close socket]----------->|<-[close socket]->|
      |                   |                  |                  |

   Figure 8:  Simplified message flow diagram for call setup procedure.

When a targeted host has accepted a call setup request, the host must
then determine how best to complete the call.  While this
determination is implementation-specific, the behavior can be
categorized under one of three possibilities.  The first possibility
is that the destination party is accessible directly from the targeted
host.  In this case, the targeted host must alert the destination
party in order to complete the call.



Kurrasch                   Expires APR 2000                   [Page 16]


Internet Draft          draft-kurrasch-tmar-00.txt         October 1999


The second possibility is that the targeted host is able to contact the
destination host, which in turn is able to alert the destination
party.  In this case the targeted host and the coordinating host are
one in the same.

The third possibility is that the targeted host is unable or unwilling
to complete the call setup procedure and thus passes the request on to
another host which will serve as the coordinating host.  This
situation could arise under the following conditions (among others):
when the targeted host does not know the complete routing to the
destination host (in which case multiple targeted hosts may be used
before reaching the coordinating host); when the desired transcoding
scheme is not available on the targeted host (but the targeted host
knows of another host which is able to perform that function); or if
the targeted host wants to balance the call load across multiple
coordinating hosts across a pool of hosts.  Notice that this third
possibility is the one demonstrated in Figure 8.

With these possibilities in mind, the following requirements are made:

Requirement 15.	If the targeted host chooses to accept the call setup
request, this host must respond back to the originating host with a
call setup acknowledge.  The targeted host, however, may choose to
delay this acknowledge until after contacting another host.

Requirement 16.	If a targeted host is unable to determine the location
of the destination host or does not wish to serve as the coordinating
host, the targeted host must forward the call setup request to
another, targeted host.  This latter host may in turn choose to
perform the roles of a coordinating host or may instead choose to
behave as a targeted host passing the call setup request to yet
another host.

Requirement 17.	If a targeted host chooses not to accept a call setup
request for any reason, the host must indicate a failure to the
originating host using the call termination message.

Requirement 18.	If a targeted host chooses to become a coordinating
host, that host must include its IP address and a TCP port number in
any call setup requests that it sends to other hosts.

Requirement 19.	Any targeted host that receives a call setup request in
which a coordinating host is specified must yield control of that call
leg (for setup and monitoring purposes) to that host.

Note that Requirement 19. does not supersede Requirement 18.  In
particular, realize that a coordinating host is always responsible for
the call legs that it establishes (by sending a call setup request)
and may or may not be responsible for the call legs that are
established for it (by receiving a call setup request).

Requirement 20.	Once all call setup activity has taken place, the


Kurrasch                   Expires APR 2000                   [Page 17]


Internet Draft          draft-kurrasch-tmar-00.txt         October 1999


coordinating host must send the call setup complete message to all
parties involved in the call.  For those configurations which do not
have a coordinating host (i.e. peer-to-peer networks), the destination
host shall perform this function.

Referring back to Figure 8, notice that it is the coordinating host
that sends the call setup complete message to not only the originating
host but also the destination host.

5.4.  IP Call Monitoring

In a packet-switched environment, ideal utilization of the network
dictates that no voice packets are exchanged when one party is not
speaking.  As such, the absence of voice packets could suggest either:
noone is speaking; the phone call has ended; or a fault has occurred
such that the call can not continue.  For the first case, the call is
still active and should be left alone.  For the latter two cases, the
call is no longer active and must be terminated immediately.  To help
distinguish between the two situations, a "keep-alive" message
facility is provided.

Requirement 21.	The coordinating host must determine if keep-alive
messages are to be used during a phone call and if so what the
periodicity (in seconds) of the messages should be.  Only the
coordinating host is permitted to set or change this periodicity.

Requirement 22.	The coordinating host must inform the origination host
and destination host (if destination and coordination hosts are not
one in the same) when a change in periodicity is to be made.  The
periodicity is included in any of the following messages: call setup
acknowledge, call setup complete, and call keep-alive.

Requirement 23.	When informed of a change in keep-alive periodicity,
the host must immediately send a keep-alive message to the
coordinating host.

Requirement 24.	Upon the passing of the specified period of time, the
originating and destination hosts must send a keep-alive message to the
originating host, and vice-versa.  The beginning of this time period
is the time of: 1) the initial setting of the periodicity by the
coordinating host; 2) the changing of the periodicity by the
coordinating host; or 3) the sending of the previous keep-alive
message.

Requirement 25.	Should any host not receive a keep-alive message for
two time periods, the call is considered to have failed.  At such
time, that host must send a call termination message.

5.5.  IP Call Termination

Call termination may be initiated by any host involved in the phone
call.  As such, all hosts must be prepared to receive that message.


Kurrasch                   Expires APR 2000                   [Page 18]


Internet Draft          draft-kurrasch-tmar-00.txt         October 1999


Furthermore, should the origination or the destination host receive
this message it would be ideal for the user to know that the call has
terminated.  In many instances, the user will probably know that the
call has terminated.  Thus, the notification of the user is specified
as merely as suggestion and not a requirement.

Requirement 26.	When the user has completed a call, the host must send
a call termination request to the coordinating host.  For those calls
which do not have a coordinating host present, the host must send the
request to the other party's host.

Requirement 27.	Upon reception by a host of a call termination
message, the host must immediately terminate the phone call.

Requirement 28.	A host must accommodate the possibility that
termination requests will not make it to the intended host (i.e.
connection refused or no response, etc.).  This requirement is
stipulated due to race conditions that can occur during a call
termination process.

Suggestion 3.	Upon reception of the call termination message, the
origination and/or destination hosts should inform the user that the
call has been terminated.

6.	Message Structures

The message structures described in this section consist of three
parts.  The first part is an ASCII text string identifying the message
type.  The second part is the fixed-length, binary portion of the
message body.  The third part is the variable-length portion of the
message body sent as ASCII text.

All binary data is transmitted in big endian format, most significant
bit to least significant bit (bit 0 to bit 31 in the diagrams).  The
binary data must end on a 32-bit boundary with pad bytes included at
the end of the structure as appropriate.  All data sent as ASCII text
shall be sent one item per line.  In other words, the termination of
each ASCII string shall be a carriage return/line feed combination (no
null-termination characters or string-length indicators).  No maximum
length for an ASCII string is specified and certain fields may be left
blank (i.e. containing only a carriage return/line feed and no other
ASCII text).

A general outline of the TMAR message structures is:

  TMAR-<message type><CR><LF>
  <binary data>
  TMAR-DATA-BEGIN<CR><LF>
  <ASCII string><CR><LF>
  <ASCII string><CR><LF>
  TMAR-DATA-END<CR><LF>



Kurrasch                   Expires APR 2000                   [Page 19]


Internet Draft          draft-kurrasch-tmar-00.txt         October 1999


Any data sent after the TMAR-DATA-END is to be ignored by the
receiving host.

Some of the messages in this document take advantage of the variable
length portion of the message structure to provide a general-purpose
interface to the end user.  Examples of how this interface could be
used include:  an HTML document detailing the duration of the call and
charges accrued during the call; an audio file containing a
pre-recorded message--possibly even containing an error message
explaining why a call could not be completed; or a Java applet that
allows the user to complete some post-call activities.  Use of this
facility is not required, nor is a host necessarily obligated to
display this information to the user.

6.1.  Call Setup Request

The call setup request appears as follows:

  TMAR-CALL-SETUP-REQUEST<CR><LF>
  <call setup request binary data, see Figure 9>
  TMAR-DATA-BEGIN<CR><LF>
  <TMAR URL as specified by originator><CR><LF>
  <caller's identity><CR><LF>
  <caller's call-back URL><CR><LF>
  <coordinating host address><CR><LF>
  <allowed response type><CR><LF>
  <allowed response type><CR><LF>
     . . .
  <allowed response type><CR><LF>
  TMAR-DATA-END<CR><LF>

The structure for the binary portion of the call setup request message
is shown in Figure 9.

  0                       15 16                        31
  +-------------------------+-------------------------+
  |            32-bit call reference number           |
  +-------------------------+-+-+----+-+-+------------+
  |  call setup wait time   |U|C|PRIO|Q|V| [not used] |
  +-------------------------+-+-+----+-+-+------------+

   Figure 9:  Fields and byte-ordering of binary data for call setup
	      request message.

The 32-bit call reference number should be set to zero (per Requirement
8.).  The call setup wait time is a 16-bit value indicating the maximum
amount of time that the sender of the call setup request will wait for
the setup to complete.  The units for this value are in 5msec
increments resulting in a maximum wait time of 5.46 minutes.

The fields U, C, PRIO, Q, and V correspond to the call's priority and
are adopted from the GSM technical specifications [5].  The fields are


Kurrasch                   Expires APR 2000                   [Page 20]


Internet Draft          draft-kurrasch-tmar-00.txt         October 1999


as follows:  `U' is an unused bit and should be set to zero.  `C' is
the preemption capability indicator where 0 means this call shall not
preempt an existing call, 1 means this call may preempt an existing
call.  `PRIO' is the 4-bit priority level where priority level 1 is
the highest priority and priority level 14 is the lowest priority;
priority levels 0 and 15 are not used.  `Q' is the queueing allowed
indicator where 0 means queueing is not allowed, 1 means queueing is
allowed.  `V' is the preemption vulnerability indicator where 0 means
this call shall not be preempted by another call and 1 means this call
might be preempted by another call.  Note that the call's ultimate
priority and preemption disposition is dictated by the call setup
complete message.  The priority and preemption information included in
the call setup request is intended to be strictly suggested values for
use by the recipient of this message.

The remaining eight bits in this structure are not used and are
included merely to pad out the structure to a 32-bit boundary.

The TMAR URL string is the string for the call and must be specified
exactly as written by the call originator (including the "tmar://"
prefix).  The caller's identity is a human-readable string identifying
who the caller is.  The caller's call back URL is a URL that the
destination party may use to call back the caller.  Either or both of
the caller's identity and call-back URL fields may be blank if the
caller wishes to remain anonymous.

The coordinating host address field identifies what host (if any) is
acting as the coordinating host for this particular call leg.  This
field may be blank.  The formatting of this field is <address>:<port>
where <address> is specified using either the dotted-decimal notation
(e.g.  192.193.194.195) or the host.domain notation.  Note that the
port must be specified, no default port number is available.

Finally, the allowed response type strings indicate the types of
responses that the sender of the call setup request is capable of
handling.  These ASCII strings are written as MIME types, such as
text/plain, text/html, audio/basic, and so forth.  Only one type may
be given on a single line.  No limit is placed on the number of types
that may be specified.

6.2.  Call Setup Acknowledge

The call setup acknowledge appears as follows:

  TMAR-CALL-SETUP-ACKNOWLEDGE<CR><LF>
  <call setup acknowledge binary data, see Figure 10>
  TMAR-DATA-BEGIN<CR><LF>
  <coordinating host address><CR><LF>
  <response type><CR><LF>
  <response type-specific data><CR><LF>
     . . .
  <response type-specific data><CR><LF>


Kurrasch                   Expires APR 2000                   [Page 21]


Internet Draft          draft-kurrasch-tmar-00.txt         October 1999


  TMAR-DATA-END<CR><LF>

The structure for the binary portion of the call setup acknowledge
message is shown in Figure 10.  

  0                       15 16                        31
  +-------------------------+-------------------------+
  |            32-bit call reference number           |
  +-------------------------+-------------------------+
  |       periodicity       |        [not used]       |
  +-------------------------+-------------------------+

   Figure 10:  Fields and byte-ordering of binary data for call setup
               acknowledge message.

The 32-bit call reference number is set to zero or a non-zero value in
accordance with Section 5.2.  The periodicity field is a 16-bit value
indicating the amount of time (in seconds) that may pass before sending
another keep-alive message.  Proper use of the keep-alive facility is
explained in Section 5.4.  The remaining sixteen bits in this
structure are not used and are included merely to pad out the
structure to a 32-bit boundary.

The coordinating host address field identifies what host (if any) is
acting as the coordinating host for this particular call leg.  This
field indicates to which host the keep-alive messages are to be sent.
If this field is blank, the implication is that no host is interested
(at this point in time, at least) in monitoring the call using
keep-alive messages.  The formatting of this field is <address>:<port>
where <address> is specified using either the dotted-decimal notation
(e.g.  192.193.194.195) or the host.domain notation.  Note that the
port must be specified, no default port number is available.

The response type field indicates what type of data is being included
in the remainder of this message (i.e. as part of the response
type-specific data fields).  This response type is written as a MIME
type and should be one of the types specified in the call setup
request message.  One possible application of this facility is to
include HTML text to be displayed within a browser indicating that the
call is proceeding.

6.3.  Call Setup Complete

The call setup complete appears as follows:

  TMAR-CALL-SETUP-COMPLETE<CR><LF>
  <call setup complete binary data, see Figure 11>
  TMAR-DATA-BEGIN<CR><LF>
  <coordinating host address><CR><LF>
  <response type><CR><LF>
  <response type-specific data><CR><LF>
     . . .


Kurrasch                   Expires APR 2000                   [Page 22]


Internet Draft          draft-kurrasch-tmar-00.txt         October 1999


  <response type-specific data><CR><LF>
  TMAR-DATA-END<CR><LF>

The structure for the binary portion of the call setup complete
message is shown in Figure 11.

  0                       15 16        23 24           31
  +-------------------------+------------+------------+
  |            32-bit call reference number           |
  +-------------------------+-+-+----+-+-+-+----------+
  |       periodicity       |U|C|PRIO|Q|V|S|[not used]|
  +-------------------------+-+-+----+-+-+-+----------+

   Figure 11:  Fields and byte-ordering of binary data for call setup
	       complete message.

The 32-bit call reference number is set to zero or a non-zero value in
accordance with Section 5.2.  The periodicity field is a 16-bit value
indicating the amount of time (in seconds) that may pass before sending
another keep-alive message.  Proper use of the keep-alive facility is
explained in Section 5.4.

The fields U, C, PRIO, Q, and V correspond to the call's priority and
are adopted from the GSM technical specifications [5].  The fields are
as follows:  `U' is an unused bit and should be set to zero.  `C' is
the preemption capability indicator where 0 means this call shall not
preempt an existing call, 1 means this call may preempt an existing
call.  `PRIO' is the 4-bit priority level where priority level 1 is
the highest priority and priority level 14 is the lowest priority;
priority levels 0 and 15 are not used.  `Q' is the queueing allowed
indicator where 0 means queueing is not allowed, 1 means queueing is
allowed.  `V' is the preemption vulnerability indicator where 0 means
this call shall not be preempted by another call and 1 means this call
might be preempted by another call.  Note that the call setup complete
message dictates a call's ultimate priority and preemption disposition
and may be different from that included in the call setup request.

The priority bits are included in this message in case the call is
placed within a resource- constrained environment.  The coordinating
host is expected to be in a position to assess the availability of
resources and to assign a call's priority accordingly.  To provide an
equivalent level of service to that provided by a circuit-switched
network, the priority bits are set as follows:  no preempting of other
calls (C=0), priority level of 13 (all calls are one step above the
lowest priority), no queueing is allowed (Q=0), and the call is not
vulnerable to preemption (V=0).  The hexadecimal value of this
priority is 0x34.

The S field is a single bit and indicates if the call address is
"storable" by the origination host.  Because this message contains the
final resolution to the original URL, the origination host may wish to
store the call address for future uses (for example, the host may want


Kurrasch                   Expires APR 2000                   [Page 23]


Internet Draft          draft-kurrasch-tmar-00.txt         October 1999


to store this address in an address book or speed dial equivalent).
One very good reason to not allow the address to be stored is because
the address represents a transient connection and the next time the
URL is resolved, the tele-media address could be something completely
different.  If the storable bit is set to 0, the origination host must
not store the call address.  If the storable bit is set to 1, the host
may choose to store the call address but is not required to do so.

The remaining seven bits in this structure are not used and are
included merely to pad out the structure to a 32-bit boundary.

The coordinating host address field identifies what host (if any) is
acting as the coordinating host for this particular call leg.  This
field indicates to which host the keep-alive messages are to be sent.
If this field is blank, the implication is that no host is interested
(at this point in time, at least) in monitoring the call using
keep-alive messages.  The formatting of this field is <address>:<port>
where <address> is specified using either the dotted-decimal notation
(e.g.  192.193.194.195) or the host.domain notation.  Note that the
port must be specified, no default port number is available.

The response type field indicates what type of data is being included
in the remainder of this message (i.e. as part of the response
type-specific data fields).  This response type is written as a MIME
type and should be one of the types specified in the call setup
request message.  One possible application of this facility is to
include HTML text to be displayed within a browser indicating that the
call is proceeding.

6.4.  Keep-Alive

The keep alive message appears as follows:

  TMAR-KEEP-ALIVE<CR><LF>
  <keep alive binary data, see Figure 12>
  TMAR-DATA-BEGIN<CR><LF>
  TMAR-DATA-END<CR><LF>

Notice that no variable length data is included in the keep-alive
message, although the begin-and end-markers must still be included in
the message.  The structure for the binary portion of the keep-alive
message is shown in Figure 12.

  0                       15 16                        31
  +-------------------------+-------------------------+
  |            32-bit call reference number           |
  +-------------------------+-------------------------+
  |       periodicity       |        [not used]       |
  +-------------------------+-------------------------+

   Figure 12:  Fields and byte-ordering of keep-alive message.



Kurrasch                   Expires APR 2000                   [Page 24]


Internet Draft          draft-kurrasch-tmar-00.txt         October 1999


The 32-bit call reference number is set to zero or a non-zero value in
accordance with Section 5.2.  The periodicity field is a 16-bit value
indicating the amount of time (in seconds) that may pass before sending
another keep-alive message.  Proper use of the keep-alive facility is
explained in Section 5.4.

When the keep-alive message is received by the coordinating host, that
host is not obligated to concern itself with the value of the
periodicity field.  However, to accommodate a coordinating host that
does pay attention to this field, both the origination and destination
hosts should use its current periodicity value when sending a
keep-alive message to the coordinating host.  Note that a value of
0x0000 is used by a coordinating host to signify that keep-alive
messages are not required to be sent by the other hosts.

The remaining sixteen bits in this structure are not used and are
included merely to pad out the structure to a 32-bit boundary.

6.5.  Call Termination

The call termination message appears as follows:

  TMAR-CALL-TERMINATION<CR><LF>
  <call termination binary data, see Figure 13>
  TMAR-DATA-BEGIN<CR><LF>
  <response type><CR><LF>
  <response type-specific data><CR><LF>
     . . .
  <response type-specific data><CR><LF>
  TMAR-DATA-END<CR><LF>

The structure for the binary portion of the call termination message is
shown in Figure 13.

  0                       15 16                        31
  +-------------------------+-------------------------+
  |            32-bit call reference number           |
  +-------------------------+-------------------------+

   Figure 13:  Fields and byte-ordering of call termination message.

The 32-bit call reference number is set to zero or a non-zero value in
accordance with Section 5.2.

The response type field indicates what type of data is being included
in the remainder of this message (i.e. as part of the response
type-specific data fields).  This response type is written as a MIME
type and should be one of the types specified in the call setup
request message.  One possible application of this facility is to
include HTML text to be displayed within a browser indicating that the
call is proceeding.



Kurrasch                   Expires APR 2000                   [Page 25]


Internet Draft          draft-kurrasch-tmar-00.txt         October 1999


7.	Security Considerations

The first area for consideration has to do with weaknesses that are
inherent to this design of the TMAR scheme.  The second area is
concerned with strengths that this scheme provides.  The relative
significance of these strengths and weaknesses are highly dependent
upon the type of deployment in which this scheme is used.  For
instance, if this scheme is used only informally between friends, the
weaknesses may not be that troublesome.  If, on the other hand, this
scheme is to be deployed by internet telephony providers or within a
corporate network, better security measures may be warranted.

7.1.  Weaknesses of this Scheme

The primary weakness to this scheme is the fact that messages are not
encrypted between hosts.  Any person on the network is therefore able
to see who is contacting whom as well as the outcome of that contact
(i.e. was communication established, etc.).  In addition, if a
username and password is included as part of the URL, this information
would be visible to any such snooper.  Should that happen, further
security within a host (or perhaps an entire network) may be
compromised if the same password is used for multiple accounts.

A more subtle implication of having the messaging data unencrypted
pertains to the outcome of the phone call.  In particular, a negative
outcome (i.e.  communication was not established) has the potential to
reveal information about the destination party that perhaps should not
be made known.  For instance, is the destination party at home?  Is
the destination party accepting calls from the originating party?  Is
the destination party reachable at a particular address/URL?

A secondary weakness is the potential to reveal the addressing of each
party when either or both parties prefer to be anonymous.  In the case
of "unlisted" phone numbers, a person's phone number is not available
to the general public unless the person chooses otherwise.  In the
case of this scheme, however, the potential exists for a person's IP
address to become public knowledge.  That said, if the network employs
a server to act as a firewall such weaknesses could be overcome.
Refer to Section 7.2. for more information on firewalls.

One additional consideration that should be made is the fact that this
scheme does not directly address encryption of the actual voice
conversation.  Neither does this scheme necessarily preclude an
encryption mechanism from being utilized, provided such encryption is
incorporated into the voice encoding scheme.  An assumption is made
that as voice encryption techniques are developed, they may be
deployed without requiring changes to the underlying protocol used by
this TMAR scheme.

7.2.  Strengths of this Scheme

The primary strength that this scheme offers is the ability to create a


Kurrasch                   Expires APR 2000                   [Page 26]


Internet Draft          draft-kurrasch-tmar-00.txt         October 1999


firewall that protects the calling party from the caller--and
vice-versa.  One example of such a utilization is within a corporate
network.  In such a situation, the corporation may not want the phone
numbers for its employees to be known to the public.  If the
corporation chooses to deploy a voice over IP network, such anonymity
may be preserved by using a firewall server between the corporate
network and the outside network (including the PSTN).

Please note that only Figure 3, Figure 4, and Figure 5. truly
demonstrate such a firewall server.  Figure 2. does not represent a
firewall because the voice traffic is routed peer-to-peer and is not
routed through the server.  As such, the network address for one party
is completely available to the other party.

One additional strength of this scheme is the fact that the behavior
of the server is not overly specified within this document.  As such,
a lot of flexibility is provided for how the server chooses to
incorporate any security measures.  For example, in server-to-server
communications, a proprietary messaging system using secure links
could be utilized.

Perhaps a more promising example involves the call setup procedure
itself.  For instance, as part of a call setup, the server could
respond to the originator using a Java applet or HTML-based form
prompting the caller to enter a username or password as appropriate.
From that point on, the call setup procedure becomes
implementation-specific and thus is limited only by the creativity of
the internet community.

8.	Intellectual Property Rights

A patent application is currently outstanding concerning the URL scheme
presented in this document. 

9.	References

[1]	RFC 2026:  S. Bradner, "The Internet Standards Process --
	Revision 3", BCP 9, October 1996

[2]	E.164:  ITU-T, "The International Public Telecommunication
	Numbering Plan", May 1997

[3]	RFC 1738:  T. Berners-Lee, L. Masinter, M. McCahill, "Uniform
	Resource Locators (URL)", December 1994

[4]	RFC 2234:  D. Crocker, Ed., P. Overell, "Augmented BNF for
	Syntax Specifications:  ABNF", November 1997

[5]	GSM Technical Specification 08.08 (section 3.2.2.18):  ETSI,
	"Mobile-services Switching Centre - Base Station System (MSC -
	BSS) interface; Layer 3 specification", revision 5.10.0, July
	1998


Kurrasch                   Expires APR 2000                   [Page 27]


Internet Draft          draft-kurrasch-tmar-00.txt         October 1999



10.	  Contact Information

Questions and comments about the TMAR scheme may be directed to:

     Peter Kurrasch
     Motorola, Inc.
     1501 W. Shure Dr., IL27-3205
     Arlington Heights, IL  60004
     USA

     Phone:  +1-847-632-7088
     Email:  kurrasch@cig.mot.com









































Kurrasch                   Expires APR 2000                   [Page 28]