Internet-Draft Michael Ross draft-ross-ptp-00.txt April 19, 2003 Expires October 19, 2003 Telephony Tunneling Protocol (TTP) This document is an Internet-Draft and is subject to 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract ======== The purpose of this document is to propose a protocol called Telephony Tunneling Protocol (TTP) to tunnel one or more plain old telephone system (POTS) connections between two Internet hosts. The hosts may have one or more telephones connected directly to them or may receive calls from the local Public Switched Telephone Network (PSTN). The Internet hosts are connected via two or more TCP connections (one for control and each of the others for one channel of voice traffic). This document makes no specification for sending Signaling System 7 (SS7) or other PSTN control commands through the control connection, though such commands may be outlined in other documents. Comments are solicited and should be sent to the author, Michael Ross Telephony Tunneling Protocol (TTP) Introduction ============ Telephony Tunneling Protocol (TTP) tunnels plain old telephone system (POTS) phone calls between two IP hosts. The IP hosts might be full-blown multifunctional computers or small boxes containing hardware built specifically to translate between an analog POTS line and a digital IP network. In its simplest implementation, a single phone is directly connected to each IP host and a single TTP connection is established between the two hosts. In more complex implementations, TTP can be used as a telephony trunking substitute, with each TTP connection carrying several, dozens, or even hundreds of telephone lines. It is anticipated that TTP will find its widest implementation between home users who want to use their traditional telephone to talk to someone far away, using the Internet to avoid long distance charges. With this protocol, there are no quality of service guarantees. The quality of TTP connections can only be as good as the quality of the underlying IP network. Technical Specification ======================= TTP consists of one TCP connection, used for control (currently port 1027 on the listening IP host), and one additional TCP connection (currently port 1028 on the listening IP host) for each POTS phone line carried. Each TCP data connection uses the ITU-T G.728 speech coder standard[1][2] at 16 Kbps to encode and decode telephone connections. Call Origination ================ When a person takes a host-connected phone off-hook or calls the host through the Public Switched Telephone Network (PSTN), the host should generate and send to the caller's earpiece a POTS dial tone or a synthesized or recorded verbal message to enter an IP phone number. The person then dials (using traditional tone or pulse dialing) the IP address of the destination host. IPv4 IP phone numbers are 12 digits long--three base-10 digits for each binary octet. IPv6 IP phone numbers are 40 digits long--five base-10 digits for every four hexadecimal digits. If a control connection is not already established, the originating host begins a TTP connection by opening a TCP connection to the destination host, which is listening on TCP port 1027. This establishes the control connection. If a control connection is already established, commands should be sent through the existing control connection as outlined below. If this connection sits idle for 45 seconds or longer, and no voice TCP connections are established during that time, this connection should be dropped and a fast busy signal sent to the earpiece of the connected telephone (if it is off-hook). If the calling host is unable to open a control connection, it should generate a fast busy signal and send it to the earpiece of the calling telephone. If the host is equipped with a display, it can display the reason for the fast busy at this time. Commands sent through the control connection are in the form of markup tags. Markup tags in TTP, as in other markup languages, are case insensitive and begin and end with less than and greater than signs ("<" and ">"). If data in the markup tags contain spaces, the data must be enclosed in double quotes. Otherwise, enclosing the data in double quotes is optional. The character case of data inside markup tags (a person's name in caller ID, for example) should be preserved. All information sent through the control connection should be encoded in the UTF-8 character set, to support international usage. After a control connection has been established, either host can request a new voice TCP connection with the other host. This is done by sending the following markup tag through the control connection: N - Line number, of calling host's choice, in base-10. Unique to TTP connection between IP hosts. name - Name of caller (enclosed in double quotes if name contains spaces). For calls that originate on the PSTN, this name is obtained from PSTN caller ID information. If the call originated from a telephone connected directly to the source host, the name is obtained from configuration information on the host. If the name is not available, this part of the tag can be left blank or omitted. number - Phone number of caller. For calls that originate on the PSTN, this phone number is obtained from PSTN caller ID information. For calls that originate from a phone directly connected to the source host, this number is the IP address of the source host. IPv4 IP phone numbers should be in base-10 and 12 digits long, with three base-10 digits used for every binary octet. IPv6 IP phone numbers should be in base-10 and 40 digits long, with five base-10 digits for every four hexadecimal digits. Only base-10 digits should be used in this number--no dashes, periods, parenthesis, or other punctuation. The number can be formatted when it is displayed to the called party. No hexadecimal, octal, or binary numbers should be used. If the number is not available, this part of the tag can be left blank or omitted. The called host responds to the RequestLine tag by sending either a LineGranted or a LineDenied tag as described below. N - LineNum, as specified in RequestLine tag. N - LineNum, as specified in RequestLine tag. code - Code for why line was denied: 1 - No more lines available 2 - Line number already in use 3 - Originating phone number blocked by destination 4 - No phone connected 5 - Called phone is off-hook description - Description for why line was denied. The called host should send a LineGranted tag if the called telephone is taken off-hook. The called host should send a LineDenied tag for any of the reasons listed above for a LineDenied code. If the called phone is on-hook and there are no other problems, the called host should send a ringing signal to the ringer of the called telephone and wait for it to be taken off-hook. If the called host is equipped with a display, it can display the caller's name and phone number at this time. If the calling host receives a LineDenied tag, it should generate a busy signal and send it to the earpiece of the calling telephone. If the calling host is equipped with a display, it can display the reason for the denial at this time. If the calling host is waiting for the called host to send a LineGranted tag, the calling host should generate a ringing signal and send it to the earpiece of the calling telephone. If the called host sends a LineGranted tag, it begins listening on TCP port 1028 for a voice data connection for the new line. The calling host opens a TCP connection to port 1028 on the called host. Bi-directional voice data then flows through the connection, encoded and decoded with the ITU-T G.728 speech coder standard. The telephone users at each end of the connection can then carry on a normal, bi-directional telephone conversation until the call is terminated. Call Termination ================ Calls can be terminated in one of three ways: the TCP control connection is lost, the voice data TCP connection is lost, or one of the telephone users hangs up their telephone. If the TCP control connection is lost, all associated voice data connections should be dropped. If the callers would like to reconnect, at this point they need to hang up their phones and one of them needs to initiate another TTP phone call. If a voice data TCP connection is lost, the line it carried should be treated as dropped and will need to be re-established from the beginning of the call origination process. If the lost line was the last one being carried through the TTP connection, the control TCP connection should be dropped. If one of the telephone users hangs up their phone, the associated voice data TCP connection should be dropped by the host closest to the hung-up phone. If the terminated line was the last one being carried through the TTP connection, the control TCP connection should be dropped. IANA Considerations =================== If this specification approaches being accepted as a standard, IANA is or will be requested to assign two TCP ports (preferrably adjacent) for use by the TTP protocol herein specified. One port (preferrably the lower one) will be used for a TTP control connection. The second port will be used for digitized voice traffic. Security Considerations ======================= This specification has no security considerations. References ========== [1] Hellosoft, Products, G.728 Speech Codec (2003). Available: http://www.hellosoft.com/products/hellovoice/g728.htm [2] Encore Software, ITU-T G.728 (2002). Available: http://www.ncoretech.com/speech/g728.html IPR Notices =========== The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Copyright Notice ================ Copyright (C) The Internet Society (April 2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." Author Contact Information ========================== Michael Ross 4400 S Quebec St #K-201 Denver, CO 80237 USA Electronic mail: rossmi@attbi.com Expires October 19, 2003