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://:@? 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* password = 1* destination = ( hostname / hostaddr ) [ ":" port ] hostname = 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 = "/" * [ 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- TMAR-DATA-BEGIN TMAR-DATA-END 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 TMAR-DATA-BEGIN . . . TMAR-DATA-END 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
: where
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 TMAR-DATA-BEGIN . . . Kurrasch Expires APR 2000 [Page 21] Internet Draft draft-kurrasch-tmar-00.txt October 1999 TMAR-DATA-END 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
: where
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 TMAR-DATA-BEGIN . . . Kurrasch Expires APR 2000 [Page 22] Internet Draft draft-kurrasch-tmar-00.txt October 1999 TMAR-DATA-END 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
: where
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 TMAR-DATA-BEGIN TMAR-DATA-END 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 TMAR-DATA-BEGIN . . . TMAR-DATA-END 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]