WO2009109068A1

WO2009109068A1 - Transmitting network ip address in pstn channel

Info

Publication number: WO2009109068A1
Application number: PCT/CN2008/000456
Authority: WO
Inventors: Zhishan Zhuang; Min Xu; Dongren Chen
Original assignee: Arcsoft (Shanghai) Technology Company, Ltd.
Priority date: 2008-03-07
Filing date: 2008-03-07
Publication date: 2009-09-11

Abstract

A method is provided for a first device to exchange network addresses with a second device over a public switched telephone network (PSTN). The method includes the first device calling the second device, the second device answering the call from the first device, the second device transmitting a handshake request in dual-tone multi-frequency (DTMF) codes to the first device, the first device transmitting a first handshake acknowledgement in DTMF codes to the second device, the second device transmitting a first network address in DTMF codes to the first device, the first device transmitting a second network address in DTMF codes to the second device, and the second device transmitting a second handshake acknowledgement in DTMF codes to the first device.

Description

TRANSMITTING NETWORK IP ADDRESS IN PSTN CHANNEL

Zhishan Zhuang

Min Xu

Dongren Chen

CROSS REFERENCE TO RELATED APPLICATIONS

[0001] This application is related to U.S. Application No. 11/280,688 entitled "Using PSTN to Communicate IP Addresses for Point-to-Point Text, Voice, Video, or Data Communication," Attorney Docket No. ARC-P152, and U.S. Application No. 11/280,688, entitled "Using Second Channel to Communicate IP Address for Point-to-Point Text, Voice, Video, or Data Communication," Attorney Docket No. ARC-P 165, which are commonly assigned and incorporated herein by reference.

[0002] This application is further related to U.S. Application No. XX/XXX,XXX, entitled "Improving Voice Quality of VoIP Devices," Attorney Docket No. ARC-P176, which is concurrently filed, commonly assigned, and incorporated herein by reference.

FIELD OF INVENTION

[0003] This invention relates to Internet-based telephony, and more specifically to methods for communicating Internet Protocol (IP) addresses over a public switched telephone network (PSTN) between devices before establishing point-to-point communication between the devices over an IP network.

DESCRIPTION OF RELATED ART

[0004] Voice over Internet Protocol (VoIP) is the routing of voice conversations over the Internet or through any other IP-based network. Companies providing VoIP service are commonly referred to as providers, and protocols which are used to carry voice signals over the IP network are commonly referred to as VoIP protocols. Some cost savings are due to utilizing a single network to carry voice and data, especially where users have existing underutilized network capacity that can carry VoIP at no additional cost. VoIP to VoIP phone calls are sometimes free, while VoIP to public switched telephone networks, PSTN, may have a cost that's borne by the VoIP user.

SUMMARY

[0005] In one embodiment of the invention, a method is provided for a first device to exchange network addresses with a second device over a public switched telephone network (PSTN). The method includes the first device calling the second device, the second device answering the call from the first device, the second device transmitting a handshake request in dual-tone multi- frequency (DTMF) codes to the first device, the first device transmitting a first handshake acknowledgement in DTMF codes to the second device, the second device transmitting a first network address in DTMF codes to the first device, the first device transmitting a second network address in DTMF codes to the second device, and the second device transmitting a second handshake acknowledgement in DTMF codes to the first device.

BRIEF DESCRIPTION OF THE DRAWINGS

[0006] Fig. 1 illustrates a system including two VoIP devices that communicate their IP addresses over a PSTN in one embodiment of the invention.

[0007] Fig. 2 illustrates a VoIP device of the system in Fig. 1 in one embodiment of the invention.

[0008] Figs. 3A to 3F illustrate synchronized processes for the VoIP devices in the system of Fig. 1 to exchange their IP addresses using dual-tone multi-frequency (DTMF) codes in embodiments of the invention.

[0009] Fig. 4 illustrates DTMF codes that express an IP address and a checksum for the IP address in one embodiment of the invention.

[0010] Fig. 5 is a flowchart of a method to determine if a lost DTMF code is consecutive or discontinuous in one embodiment of the invention. [0011] Fig. 6 illustrates a synchronized process for the VoIP devices in the system of Fig. 1 to exchange their IP addresses using DTMF codes in one embodiment of the invention.

[0012] Fig. 7 is a flowchart of a method to determine a timeout period for retransinitting an IP address in one embodiment of the invention.

[0013] Use of the same reference numbers in different figures indicates similar or identical elements.

DETAILED DESCRIPTION OF THE INVENTION

[0014] Fig. 1 illustrates an exemplary Voice over Internet Protocol (VoIP) system 100 disclosed in U.S. Patent Application Serial No. 11/280,688, entitled "Using PSTN to Communicate IP Addresses for Point-to-Point Text, Voice, Video, or Data Communication." System 100 includes VoIP devices 104 and 106 connected by a wide area network (WAN) 108 (e.g., the Internet) for exchanging data packets through a network connection. Devices 104 and 106 are also connected by a PSTN 110 to exchange IP addresses to establish the network connection over WAN 108. In some scenarios, device 104 is connected by a local area network (LAN) 107 to WAN 108, and device 106 is connected by LAN 109 to WAN 108.

[0015] Fig. 2 ύ ^' ]ustrates the hardware of VoIP device 104 in one embodiment of the invention. Device 104 has the form factor of a telephone or a videophone. Device 104 includes a central processing unit (CPU) or digital signal processor (DSP) 202 that executes VoIP software loaded from nonvolatile memory 204 to volatile memory 206. CPU 202 uses a network card 208 to access LAN 107 through a LAN interface. CPU 202 uses a telephone chip 212 to access PSTN 1 10. Telephone chip 212 includes a modem for generating and receiving signals over PSTN ] 10. For text, voice, and video communications, CPU 202 may be further connected to peripherals including a display 214, a keypad or keyboard 216, microphone and speaker 218, and a camera 220. VoIP device 106 can be similarly constructed as device 104.

[0016] VoIP devices 104 and 106 can communicate IP addresses over PSTN 110 using several methods. VoIP devices 104 and 106 can use frequency modulation/demodulation to communicate their IP addresses over a PSTN 110. However, such a scheme is not compatible with the use of digital subscriber line (DSL) service. For DSL service, the PSTN line carries both voice and DSL signals where the lower frequencies are assigned to voice and the higher frequencies are assigned to.DSL. Thus, if frequency modulation is used to transmit the IP addresses over the PSTN line, the higher frequency signals may be either removed by a DSL filter connected to the PSTN line or interfere with the operation of the DSL modem.

[0017] VoIP devices 104 and 106 can use frequency-shift keying (FSK) to communicate their IP addresses over a PSTN 110. However, in many countries and regions FSK is assigned to special services, such as caller ID, fax, and other value-added services from a telecom service provider. Furthermore, the telecom service provider may mask the FSK signals so that the VoIP devices cannot receive them to deter people from using VoIP.

[0018] VoIP devices 104 and 106 can use a newly defined modulation scheme to communicate their IP addresses over a PSTN 1 10. However, many conventional telephone systems have been upgraded to a combination of PSTN and VoIP systems where calls are routed either PSTN or VoIP channel. For example, a call from the U.S. to Japan may go though a U.S. PSTN channel, a U.S.-Japan VoIP channel, and a Japanese PSTN channel. If the newly defined signal goes through a VoIP channel, it will be considered as voice and compressed. Once compressed, the signals are distorted so that a VoIP device cannot correctly decipher the IP address.

[0019] VoIP devices 104 and 106 can use dual-tone multi-frequency (DTMF) to communicate their IP addresses over a PSTN 110. DTMF has been used for several decades. Nearly all the countries use DTMF for dialing telephone numbers and nearly all the analog private branch exchange (PBX) are compatible with it. DTMF signals also have frequencies in the voice band so it can go through the PSTN line without impacting DSL service. Once the PSTN system or the analog PBX detects a DTMF signal, the signal is routed to its destination in out-of-band so the data will not be compressed.

[0020] While DTMF appears to be the most suitable mechanism for communicating IP addresses over PSTN 110, the DTMF signals can may still be distorted or lost due to following problems.

[0021] (1) When the PSTN channel has noise, the signal will be distorted or lost.

[0022] (2) When the power or duration of the DTMF signals is changed by the PSTN/PBX system, the VoIP devices will not be correctly synchronization so that the signals are lost. [0023] (3) The PSTN/PBX system may have errors and ignore the DTMF signals or decode the DTMF signals incorrectly.

[0024] (4) The callee or the caller's voice can produce noise in the PSTN channel that affects the DTMF receiver in decoding the signal at either end.

[0025] To solve the above problems, the present invention has to meet the following objectives.

[0026] (1) Shield the DTMF tones from the user.

[0027] (2) Provide a peer-to-peer DTMF transmission process that avoids losing DTMF transmission time synchronization while using the minimal transmission time.

[0028] (3) Adjust system transmission parameter to get the minimal DTMF code loss rate.

[0029] (4) Check for lost or incorrect DTMF codes.

[0030] (5) Retransmit the DTMF codes when there are lost or incorrect DTMF codes.

Synchronized IP address exchange

[0031] For DTMF transmission system, the PSTN is a simplex channel. Two VoIP devices cannot transmit DTMF codes at the same time or otherwise the DTMF codes will be distorted. If two VoIP devices want to exchange their addresses through the PSTN, they must be synchronized so one does not start to transmit its DTMF codes until the other has transmitted all of its DTMF codes. Furthermore, the DTMF codes are easily lost or distorted by the PSTN. Thus, error detection and address retransmission are needed to ensure that the two VoIP devices correctly exchange their addresses. In one embodiment of the invention, a synchronized process is provided to exchange the IP addresses. The process is divided into two portions: a handshake process and an address exchange process.

[0032] Handshaking is necessary since one device does not know the other device. The other device may be a VoIP device that is part of system 100 or a normal telephone. Furthermore, each device needs to know if the other device has a public or a private network address. The purpose of handshaking is to identify the two devices and exchange such information for the next step. The devices only start to exchange their IP addresses only when they have a successful handshake process.

[0033] Either the VoIP device that initiates the call (hereafter "caller") or the VoIP device that receives the call (hereafter "callee") can transmit a handshake request first. For example, the caller can transmit the handshake request when the caller detects that the callee has picked up phone. Alternatively, the callee can transmit the handshake request when the callee picks up the phone. It is logical for the callee to transmit the handshake request after the callee picks up the phone. In one embodiment of the invention, the callee transmits the handshake requests after the callee picks up the phone.

[0034] In the address exchange process, either the caller or the callee can transmit its IP address first. As the entire process must be synchronized, it is logical for the callee who receives a handshake acknowledgement from the caller to transmit the callee' s IP address first. In one embodiment, the callee transmits its IP address after receiving a handshake acknowledgement from the caller.

[0035] One device can notify the other that the IP address has been received. A new control message does not need to be added for this purpose. This information can be indicated by a DTMF code transmitted by the last partyfo receive the IP address at the end of the exchange process. Furthermore, a checksum is added to the IP address to protect against loss and distortion.

[0036] Fig. 3A illustrates a synchronized address exchange process when both the caller and the callee have public network addresses in one embodiment of the invention.

[0037] First, the caller calls the callee. The callee picks up the phone and transmits a handshake request as a string of DTMF codes. The combination of the DTMF codes indicates that the callee is a VoIP device capable of address exchange over the PSTN, and if the callee believes it has a public network address. When either the caller or the callee believes it has a public network address, it will later transmit the public network address to the other party. For example, the callee transmits DTMF codes 15 and 0 to indicate that it is a VoIP device capable of address exchange over the PSTN, and that it believes it has a public network address. The caller and the callee each can determine that it has a public network address by examining its IP address or when the user has programmed it to always transmit its IP address.

[0038] Second, the caller receives the handshake request. From the combination of the DTMF codes in the handshake request, the caller identifies the callee as a VoIP device capable of address exchange over the PSTN and learns that the callee believes it has a public network address. In response, the caller then transmits a first handshake acknowledgment as a string of DTMF codes. The combination of the DTMF codes indicates if the caller believes it has a public network address. For example, the caller transmits DTMF codes 15, 0, and 0 where DTMF codes 15 and 0 indicate that the caller believes it has a public network address.

[0039] After transmitting the first handshake acknowledgement, the caller starts a timer and waits for the callee to send its IP address. When the timer expires before the caller receives the IP address of the callee, the caller retransmits the first handshake acknowledgement. The caller can retransmit the first handshake acknowledgement for a number of times (e.g., a total of three times) before aborting the address exchange process by hanging up.

[0040] Third, the callee receives the first handshake acknowledgement. From the combination of the DTMF codes in the first handshake acknowledgement, the callee identifies the caller as a VoIP device capable of address exchange over the PSTN and learns that the caller believes that it has a public network address. In response, the callee transmits its IP address as a string of DTMF codes and waits for the caller to send its IP address.

[0041] Each DTMF code comprises a low frequency tone and a high frequency tone selected from 4 low and 4 high frequency tones to define sixteen (16) codes. The sixteen codes can be used to express integer values 0 to 15 so that each DTMF code can denote an integer that consists of four (4) bits. As IPv4 address is a 32-bit integer, eight (8) DTMF codes are used to denote one IPv4 address. In other words, IPv4 address can be converted to eight or more DTMF codes.

[0042] To ensure that the DTMF codes correctly express an IP address, a checksum is calculated for the DTMF codes. In one embodiment, the checksum is the cumulative value of the DTMF codes and it is sent as DTMF codes along with the IP address. The number of the DTMF codes used for the checksum depends on the size of the checksum. In addition, the DTMF codes have one bit reserved for indicating if the IP address of a peer has been received (e.g., reserve bit is set to 1 when the peer address has been received correctly). For example, if eight (8) DTMF codes are used to convey the IP address, then two (2) DTMF codes are used to express the checksum. After a device receives the DTMF codes for the IP address, it calculates a checksum as "ip_sum" and compares the value of ip_sum with the checksum value received in the DTMF codes. If they match, then the IP address passes the checksum test. Otherwise the IP address fails the checksum test.

[0043] Fig. 4 illustrates the generation of the DTMF codes for the IP address and the checksum in one embodiment of the invention. Eight (8) DTMF codes are used to express the IP address, and two (2) DTMF codes are used to express the checksum of the IP address. As Fig. 4 illustrates, the checksum and the IP address form 10 consecutive DTMF codes. The first bit of the first DTMF code is the reserved bit for indicating if the IP address of a peer has been received correctly while the next seven bits of the first and the second DTMF codes express the checksum. In other words, the checksum is a 7-bit integer. The third to the tenth DTMF codes express the IP address.

[0044] Referring back to Fig. 3 A, the callee transmits ten DTMF codes consisting of two checksum codes and eight address codes. For example, the callee transmits DTMF codes 3, 8, 13, 6, 1, 6, 10, 8, 12, and 0, where 3 and 8 are the checksum and the first bit of 3 is "0" indicates that the callee has not correctly received the IP address of the caller.

[0045] Fourth, the caller receives the IP address of the callee. The caller verifies that the IP address has been received correctly with the checksum. Assuming so, the caller transmits its IP address as a string of DTMF codes and waits for the callee to send a handshake acknowledgement. For example, the caller transmits DTMF codes 11, 8, 15, 4, 1, 6, 10, 8, 12, and 0, where 11 and 8 are the checksum and the first bit of 11 is "1" indicates that the caller has correctly received the IP address of the callee.

[0046] Fifth, the callee receives the IP address of the caller. The callee verifies that the IP address has been received correctly with the checksum. Assuming so, the callee transmits second handshake acknowledgement as a string of DTMF codes to the caller. The DTMF codes of the second handshake acknowledgement follows the same format as the checksum and has a reserved bit indicating if the IP address of the caller has been received correctly and the remaining bits form the actual checksum of the callee's address. For example, the callee transmits DTMF codes 8 and 0, where the first bit of 8 is "1" indicates that the callee has correctly received the IP address of the caller and the process is complete. As there is no IP address codes in this DTMF string, the remaining 7 bits are set to O's so the handshake acknowledgement is "8 0."

[0047] Sixth, the process ends when the caller receives the second handshake acknowledgment. The caller and the callee then proceeds to establish a VoIP call using the exchanged IP addresses.

[0048] In another embodiment, after one side has correctly received the IP address of the other side, it can try to connect to the peer device without waiting for the end of the address exchange procedure. For example, the callee can start to connect the caller when it receives the IP address of the caller after it passes the checksum and before the callee transmits its IP address. In this case, the caller starts a network service waiting for the VoIP client at the callee when it transmits its IP address. Once the VoIP connection has been successfully established, the address exchange procedure can be teπninated even though it has not been finished because the caller can determine the IP address of the callee from the IP packets from the callee.

[0049] Fig. 3B illustrates a synchronized address exchange process when only the callee as a public network address in one embodiment of the invention.

[0050] First, the caller calls the callee. The callee picks up the phone and transmits a handshake request as a string of DTMF codes. For example, the callee transmits DTMF codes 15 and 0 to indicate that it is a VoIP device capable of address exchange over the PSTN, and that it believes it has a public network address.

[0051] Second, the caller receives the handshake request. In response, the caller then transmits a handshake acknowledgment as a string of DTMF codes. For example, the caller transmits DTMF codes 13, 14, and 14 where DTMF codes 13 and 14 indicate that the caller believes it has a private network address. When either the caller or the callee believes it has a private network address, it will not transmit the private network address to the other party. As discussed above, the caller starts a timer and waits for the callee to send its IP address.

[0052] Third, the callee receives the handshake acknowledgement. From the combination of the DTMF codes in the first handshake acknowledgement, the callee identifies the caller as a VoIP device capable of address exchange over the PSTN and learns that the caller believes that it has a private network address. In response, the callee transmits its IP address as a string of DTMF codes and waits for the caller to send its IP address. For example, the callee transmits DTMF codes 11, 8, 13, 6, 1, 6, 10, 8, 12, and 0, where 11 and 8 are the checksum and the first bit of 11 is "1." The callee has set the reserve bit to "1" even though the callee has not actually correctly received the IP address of the caller because the caller does not believe it has a public network address and the caller will not transmit its own address.

[0053] Fourth, the caller receives the IP address of the callee. The caller verifies that the IP address has been received correctly with the checksum. Assuming so, the caller transmits two checksum codes instead of its IP address. For example, the caller transmits DTMF codes 8 and 0, where the first bit of 8 is "1" indicates that the caller has correctly received the IP address of the callee and the process is complete. As there is no IP address codes in this DTMF string, the remaining 7 bits are set to O's so the handshake acknowledgement is "8 0."

[0054] Fifth, the process ends and a VoIP call is established when the caller connects to the callee using the callee's IP address. Once connected, the callee can determine a public network address for communicating with the caller. As similarly discussed above, the caller can attempt to connect to the callee as soon as it correctly receives the callee's IP address. The callee should start a network service waiting for the VoIP client at the caller after it transmits its IP address. Once the VoIP connection has been successfully established, the address exchange procedure can be terminated even though it has not been finished because the callee can determine the IP address of the caller from the caller's IP packets.

[0055] Fig. 3C illustrates a synchronized address exchange process when only the caller has a public network address in one embodiment of the invention.

[0056] First, the caller calls the callee. The callee picks up the phone and transmits a handshake request as a string of DTMF codes. For example, the callee transmits DTMF codes 13 and 14 to indicate that it is a VoIP device capable of address exchange over the PSTN, and that it believes it has a private network address.

[0057] Second, the caller receives the handshake request. From the combination of the DTMF codes in the handshake request, the caller identifies the callee as a VoIP device capable of address exchange over the PSTN and learns that the callee believes it has a private network address. In response, the caller then transmits a first handshake acknowledgment as a string of DTMF codes. For example, the caller transmits DTMF codes 15, 0, and 0 where DTMF codes 15 and 0 indicate that the caller believes it has a public network address. As discussed above, the caller starts a timer and waits for the callee to respond.

[0058] Third, the callee receives the first handshake acknowledgement. From the combination of the DTMF codes in the first handshake acknowledgement, the callee identifies the caller as a VoIP device capable of address exchange over the PSTN and learns that the caller believes that it has a public network address. In response, the callee transmits two checksum codes instead of its IP address and waits for the caller to send its IP address. For example, the callee transmits DTMF codes 0 and 0 where the first bit of 0 is "0" indicates that the callee has not correctly received the IP address of the caller. As there is no IP address codes in this DTMF string, the remaining 7 bits are set to O's so the handshake acknowledgement is "0 0."

[0059] Fourth, the caller receives the checksum codes from the callee. In response, the caller transmits its IP address as a string of DTMF codes and waits for the callee to send a handshake acknowledgement. For example, the caller transmits DTMF codes 11, 8, 15, 4, 1, 6, 10, 8, 12, and 0, where 11 and 8 are the checksum and the first bit of 11 is "I₁" The caller has set the reserve bit to "1" even though the caller has not actually correctly received the IP address of the callee because the callee does not believe it has a public network address and the callee will not transmit its own address even when requested.

[0060] Fifth, the callee receives the IP address of the caller. The callee verifies that the IP address has been received correctly with the checksum. Assuming so, the caller transmits a second handshake acknowledgement as a string of DTMF codes to the caller. For example, the callee transmits DTMF codes 8 and 0, where the first bit of 8 is "1" indicates that the callee has correctly received the IP address of the caller and the process is complete. As there is no IP address codes in this DTMF string, the remaining 7 bits are set to O's so the handshake acknowledgement is "8 0."

[0061] Sixth, the process ends and a VoIP call is established when the callee connects to the caller using the caller's IP address. Once connected, the caller can determine a public network address for communicating with the callee. As similarly discussed above, the callee can attempt to connect to the caller as soon as it correctly receives the caller's IP address. The caller should start a network service waiting for the VoIP client at the callee after it transmits its IP address. Once the VoIP connection has been successfully established, the address exchange procedure can be terminated even though it has not been finished because the caller can determine the IP address of the callee from the callee' s IP packets.

[0062] Fig. 3D illustrates a synchronized address exchange process when both the caller and the callee do not have public network addresses in one embodiment of the invention.

[0063] First, the caller calls the callee. The callee picks up the phone and transmits a handshake request as a string of DTMF codes. For example, the callee transmits DTMF codes 13 and 14 to indicate that it is a VoIP device capable of address exchange over the PSTN, and that it believes it has a private network address.

[0064] Second, the caller receives the handshake request. From the combination of the DTMF codes in the handshake request, the caller identifies the callee as a VoIP device capable of address exchange over the PSTN and learns that the callee believes it has a private network address. As the caller also has a private network address, a VoIP call probably cannot be established between the devices. In response, the caller does not transmit its IP address to further the process. Instead, the caller and the callee enable a normal telephone call over the PSTN over the established connection.

[0065] Fig. 3E illustrates a synchronized address exchange process when the caller and the callee have private network addresses, they are located in the same private network, and they can obtain the public network address of the private network from a network device (e.g., a network gateway or router) in one embodiment of the invention. In this embodiment, the caller and the callee do not know they are in the same private network until they exchange their addresses. [0066] First, the caller calls the callee. The callee picks up the phone and transmits a handshake request as a string of DTMF codes. For example, the callee transmits DTMF codes 15 and 0 to indicate that it is a VoIP device capable of address exchange over the PSTN, and that it believes it has a public network address. In this case, the user has programmed the callee to always transmit its IP address and the callee will transmit the public network address of the private network.

[0067] Second, the caller receives the handshake request. From the combination of the DTMF codes in the handshake request, the caller identifies the callee as a VoIP device capable of address exchange over the PSTN and learns that the callee believes it has a public network address. In response, the caller then transmits a first handshake acknowledgment as a string of DTMF codes. For example, the caller transmits DTMF codes 15, 0, and 0 where DTMF codes 15 and 0 indicate that the caller believes it has a public network address. In this case, the user has programmed the caller to always transmit its IP address and it will transmit the public network address of the private network. As discussed above, the caller starts a timer and waits for the callee to respond.

[0068] Third, the callee receives the first handshake acknowledgement. From the combination of the DTMF codes in the first handshake acknowledgement, the callee identifies the caller as a VoIP device capable of address exchange over the PSTN and learns that the caller believes that it has a public network address. In response, the callee transmits the public network address of the private network as a string of DTMF codes and waits for the caller to send its IP address. As discussed above, the callee obtains the public network address from a network device. For example, the callee transmits DTMF codes 3, 8, 13, 6, 1, 6, 10, 8, 12, and 0, where 3 and 8 are the checksum and the first bit of 3 is "0" indicates that the callee has not correctly received the IP address of the caller.

[0069] Fourth, the caller receives the IP address from the callee. The caller verifies that the IP address has been received correctly with the checksum. Assuming so, the caller examines the IP address of the callee and determines that it is the same as the public network address of its private network. This indicates to the caller that the caller and the callee are in the same private network. The caller then transmits its private network address as a string of DTMF codes and waits for the callee to send a handshake acknowledgement. For example, the caller transmits DTMF codes 1 1, 8, 15, 4, 1, 6, 10, 8, 12, and 0, where 11 and 8 are the checksum and the first bit of 1 1 is "1" indicates that the caller has correctly received the IP address of the callee.

[0070] Fifth, the callee receives the IP address of the caller. The callee verifies that the IP address has been received correctly with the checksum. Assuming so, the callee transmits a second handshake acknowledgement as a string of DTMF codes to the caller. For example, the callee transmits DTMF codes 8 and 0, where the first bit of 8 is "1" indicates that the callee has correctly received the IP address of the caller and the process is complete. As there is no IP address codes in this DTMF string, the remaining 7 bits are set to O's so the handshake acknowledgement is "8 0."

[0071] Sixth, the process ends and a VoIP call is established when the callee connects to the caller using the caller's private network address. Once connected, the caller can determine the private network address of the callee from the callee' s IP packets.

[0072] In this embodiment, the caller does not attempt to connect to the callee as soon as the caller correctly receives the callee' s public network address when the caller has determined the caller and the callee are in the same private network. However, the callee can attempt to connect to the caller as soon as it correctly receives the caller's private network address. The caller should start the network service waiting for the VoIP client at the callee after it transmits its private network address. Once the VoIP has been successfully established, the address exchange procedure can be¹ terminated even though it has not been finished.

[0073] Fig. 3F illustrates a synchronized address exchange process when the caller and the callee have public network addresses and one of the IP address fails the checksum in one embodiment of the invention.

[0074] First, the caller calls the callee. The callee picks up the phone and transmits a handshake request as a string of DTMF codes. For example, the callee transmits DTMF codes 15 and 0 to indicate that it is a VoIP device capable of address exchange over the PSTN, and that it believes it has a public network address.

[0075] Second, the caller receives the handshake request. From the combination of the DTMF codes in the handshake request, the caller identifies the callee as a VoIP device capable of address exchange over the PSTN and learns that the callee believes it has a public network address. In response, the caller then transmits a first handshake acknowledgment as a string of DTMF codes. For example, the caller transmits DTMF codes 15, 0, and 0 where DTMF codes 15 and 0 indicate that the caller believes it has a public network address. As discussed above, the caller starts a timer and waits for the callee to respond.

[0076] Third, the callee receives the first handshake acknowledgement. From the combination of the DTMF codes in the first handshake acknowledgement, the callee identifies the caller as a VoIP device capable of address exchange over the PSTN and learns that the caller believes that it has a public network address. In response, the callee transmits its IP address as a string of DTMF codes and waits for the caller to send its IP address. For example, the callee transmits DTMF codes 3, 8, 13, 6, 1, 6, 10, 8, 12, and 0, where 3 and 8 are the checksum and the first bit of 3 is "0" indicates that the callee has not correctly received the IP address of the caller.

[0077] Fourth, the caller receives the IP address from the callee. The caller verifies that the IP address has been received correctly with the checksum. Assuming the IP address fails the checksum, the caller transmits its IP address as a string of DTMF codes indicating so and waits for the callee to send a handshake acknowledgement. For example, the caller transmits DTMF codes 3, 8, 15, 4, 1, 6, 10, 8, 12, and 0, where 3 and 8 are the checksum and the first bit of 3 is "0" indicates that the caller has not correctly received the IP address of the callee.

[0078] Fifth, the callee receives the IP address of the caller. The callee verifies that the IP address has been received correctly with the checksum. From the checksum, the callee also determines that its IP address was not correctly received by the caller so it has to retransmits its IP address. In response, the caller retransmits its IP address. For example, the caller transmits DTMF codes 11, 8, 15, 4, 1, 6, 10, 8, 12, and 0, where 11 and 8 are the checksum and the first bit of 1 1 is "1" indicates that the caller has correctly received the IP address of the callee.

[0079] Sixth, the caller receives the IP address of the callee. Assuming the IP address passes the checksum, the caller transmits a second handshake acknowledgement as a string of DTMF codes to the caller. For example, the caller transmits DTMF codes 8 and 0, where the first bit of 8 is "1 " indicates that the caller has correctly received the IP address of the callee and the process is complete. As there is no IP address codes in this DTMF string, the remaining 7 bits are set to O's so the handshake acknowledgement is "8 0."

[0080] Seventh, the process ends and a VoIP call is established over the public network.

Handling lost DTMF codes

[0081] From testing, it is known that some of the DTMF codes may be lost. As the physical nature of the PSTN cannot be changed, a method must be provided to reduce the loss of the DTMF codes in the handshake and the IP address exchange.

[0082] Two methods are proposed to reduce the loss of the DTMF codes in the handshake process. In the first method, the callee transmits one handshake request code and then retransmits the handshake request code if it has not received a handshake acknowledgment code from the caller after a timeout. In the second method, the callee transmits several consecutive handshake request codes and the caller transmits several consecutive handshake acknowledgement codes in response to the handshake request codes. Thus, the handshake process succeeds as long as the caller receives one of the consecutive handshake request codes and the callee receives one of the consecutive handshake acknowledgment codes.

[0083] The first method is complex to implement. The success rate and the time consumed by the handshake process depend on the PSTN condition. In contrast, the success rate of the second method is guaranteed regardless of the PSTN condition, and the time consumed by handshake process is identical. However, in the second method, the success rate and the time consumed for the handshake process must be balanced. If the number of handshake codes is increased, the success rate can be improved but the handshake time is longer. If the number of handshake codes is decreased, the handshake time is reduced but the success rate may deteriorate. Through testing, the handshake process uses 2 handshake request codes and 3 handshake acknowledgment codes in one embodiment of the invention.

[0084] In the IP address exchange, a single or several DTMF codes may be lost. As will be described later, when several DTMF codes are lost, it is solved by retransmitting the DTMF codes. When only a single DTMF code is lost, the lost code can be computed according to the other address codes and the checksum. Single lost DTMF code is classified into two types: it is a missing code from consecutive codes or discontinuous codes.

[0085] A missing code from consecutive codes can be the first or the last code. When the first code is lost, it means all the address codes are received and the checksum can be determined from the address codes. Thus, the first code received should be the second code of the checksum and the first code of the checksum should have a value from 0 to 15 for a valid DTMF code. If the calculated first code of the checksum does not have a value from 0 to 15, then the lost code must be the last code. When the last code is lost, it means the whole checksum is received and the last address code can be calculated from the checksum and the other address codes. The calculated last address code should have a value from 0 to 15 for a valid DTMF code. When both conditions are fulfilled or both conditions are not fulfilled, the entire series of DTMF codes must be retransmitted. The above description is based on the checksum codes being located at the beginning of the address DTMF codes. If the checksum is at the end of the address DTMF codes, the same concept can be applied to determine the missing code.

[0086] Fig. 5 is a flowchart of a method to determine if the lost DTMF code belongs the consecutive address codes or discontinuous address codes.

[0087] In step 502, the VoIP device computes the time interval between all consecutive DTMF codes where intervalj (i=l ...9) denotes the time interval between the (i+l)^th code and the i^th code.

[0088] In step 504, the VoIP device computes the total time interval as totaHnter = ∑ interval;, (i=l,...,9).

[0089] In step 506, the VoIP device computes the average time interval as avg_inter = totaHnter / 9 and then set an upper limit of the average interval equal to avg_inter + aγg_inter / 2.

[0090] In step 508, the VoIP device determines the maximum time interval from the 9 intervals between the DTMF codes and denotes it as max_i.

[0091] In step 510, the VoIP device determines if the maximum time interval max_i determined in step 508 is less than the upper limit of the average interval determined in step 506. If so, then step 510 is followed by step 512. Otherwise step 510 is followed by step 514.

[0092] In step 512, the VoIP device determines that the received DTMF codes are consecutive address codes, uses the checksum to determine the missing DTMF code, and inserts the missing DTMF code into the IP address. As described above, if the value of the missing DTMF code is invalid (not 0 to 15), then all the address codes must be retransmitted. Methods for retransmission are described later in detail. Step 512 then ends method 500.

[0093] In step 514, the VoIP device determines that the received DTMF codes are discontinuous address codes, uses the checksum to determine the missing DTMF code, and inserts the missing DTMF code into the IP address. If the value of the missing DTMF code is invalid (not 0 to 15), then all the address codes must be retransmitted. Methods for retransmission are described later in detail. For the discontinuous address codes, the missing DTMF code is located between the two DTMF codes with the largest interval identified in step 508. Step 514 then ends method 500.

Reducing loss rate

[0094] The stability of the PSTN channel will affect the lost rate of the DTMF codes. A VoIP device that transmits DTMF codes immediately after it receives DTMF codes from another VoIP device will result in a higher loss rate. After the transmission of a group of DTMF codes, the PSTN channel is not stable and there may still be residual effects from the last DTMF code transmitted over the PSTN channel.

[0095] Accordingly, a delay-transmit method is used to reduce the loss rate in one embodiment of the invention. In the delay-transmit method, one VoIP device will wait some time to transmit its DTMF codes after it receives DTMF codes from another VoIP device. This wait time is called TD. The TD value depends on the time to transmit a DTMF code (hereafter "DTMF transmission time"). Generally the PSTN channel will be more stable after TD. The TD value also depends on the synchronization between the VoIP devices.

[0096] If several DTMF handshake codes are used, a device cannot immediately transmit DTMF codes after it receives the first handshake code. The device must wait some time until other handshake codes arrive. This wait time is called TS. The value of TS is determined by the number of handshake codes transmitted by the peer device. Assuming the peer device transmits three handshake codes, the TS value is approximately double the DTMF transmission time. The TS value can be longer if it does not affect the synchronization between the two devices.

[0097] If the device immediately transmits a handshake request after the PSTN channel is set up between two devices (i.e., right after the callee takes the phone off hook), it is likely to fail because the PSTN channel needs some time to set up and the loss rate is higher when the PSTN has just set up. To solve this problem, the device will wait some time to transmit handshake request codes after the PSTN is set up. This time is called TP. Through testing, the value of TP has been optimized to 1,800 ms where the success rate of transmitting handshake codes is nearly 100%. Of course the longer the time, the higher the success rate but the longer the time for the IP address exchange.

Shielding DTMF tones from user

[0098] The DTMF tones are not melodious to the user so it is best to shield the DTMF tones from the user (i.e., lower the volume of the DTMF tones so they are not audible to the user). Shielding the DTMF tones must consider three scenarios: (1) the caller is part of the system and the callee is not, (2) the caller is not part of the system but the callee is, and (3) both the caller and the callee are part of the system.

[0099] If two devices can shake hand successfully, then both of them are part of the system and they can shield the DTMF tones after the handshake process. Thus, only the handshaking process needs to be examined for shielding the DTMF tones from the user.

[00100] First, it is determined if who initiates the handshaking process affects the shielding of the DTMF tones. If the caller initiates the handshake process, the callee will hear the DTMF tones in the first scenario but the callee will not hear the DTMF tones in the second scenario. Conversely, if the callee initiates the handshake process, the caller will hear the DTMF tones in the first scenario but the caller will not hear the DTMF tones in the second scenario. In the third scenario, when both sides are part of the system, the system will shield the DTMF tones after the first handshake request so the two devices will hear only the DTMF tones for the first handshake request. In short, shielding is not affected by who initiates the handshake process.

[00101] Second, it is determined if retransmission of handshake request/acknowledgment after timeout or transmitting consecutive handshake request/acknowledgement is better suited for shielding DTMF tones from the user. Using retransmission of handshake codes after timeout, a device that is not part of the system may hear one or several DTMF tones. These DTMF tones may not be continuous and may be heard from time to time. Using transmission of several consecutive handshake codes, any device that is not part of the system will hear several DTMF tones and the number of the DTMF tones is identical. It is believed that transmission of several consecutive handshake codes is more comfortable and familiar to the user.

[00102] Third, it is determined if the number of the handshake requests affects the shielding of the DTMF tones. If both devices are part of the system, they will both hear one DTMF tone. However, if one device is not part of the system, the number of DTMF tones heard is determined by the number of the handshake requests. Thus, while guaranteeing the success rate of the handshake process, the lesser the number of handshake codes the better.

Specific plan of synchronized IP address exchange

[00103] In view of the above, Fig. 6 illustrates a specific address exchange process 600 in one embodiment of the invention. Process 600 has two major advantages: higher success rate of address exchange and shorter time to exchange IP addresses. The main parameters of process 600 include:

[00104] 1. The DTMF transmission time is set to 160 ms.

[00105] 2. Handshake request uses two DTMF codes, and handshake acknowledgement uses three DTMF codes during handshake process.

[00106] 3. During the IP address exchange process, eight DTMF codes express the IP address and two DTMF codes express the checksum.

[00107] 4. The time of waiting for PSTN stability after PSTN setting up (i.e., TP) is set to be 1,800 ms.

[00108] 5. The time of waiting for PSTN stability after receiving DTMF codes from another device (i.e., the sum of TD and TS) is different at various points of the IP address exchange. [00109] Process 600 is described below in reference to Fig. 6. Fig. 6 shows the time for each step and the overall timeline for the process.

[00110] First, the callee takes the telephone off hook, waits about 1,800 ms, and then transmits a handshake request as a string of DTMF codes to the caller in about 320 ms. The callee then waits for the caller's handshake ACK.

[00111] Second, the caller receives the handshake request from the callee, wait 400 ms after the start of the first handshake request, and then transmit a handshake acknowledgment as a string of DTMF codes to the callee in about 480 ms. The caller then waits for the callee's IP address codes.

[00112] Third, the callee receives the handshake acknowledgment from the caller, waits

640 ms after the start of the first handshake acknowledgement, and then transmits its eight address codes and two checksum codes to the caller in about 1,600 ms. The callee notifies the caller that it has not received the caller's IP address by setting the reserved bit (i.e., the 8^th bit) of the checksum codes.

[00113] Fourth, the caller receives the eight address codes and two checksum codes from the callee and verifies the eight address codes using the two checksum codes. As described above, the caller may use the checksum to determine if the IP address is missing a single DTMF code and recover the missing DTMF code. The caller then waits 240 ms and transmits its eight address codes and two checksum codes to the callee in about 1,600 ms. The caller notifies the callee whether or not it has correctly received the IP address by setting the reserved bit of checksum codes.

[00114] Fifth, the callee receives eight address codes and two checksum codes from the caller and verifies the eight address codes with the two checksum codes. As described above, the caller may use the checksum to determine if the IP address is missing a single DTMF code and recover the missing DTMF code. The callee then waits 240 ms and transmits an address acknowledgment as a string of DTMF codes to the caller in about 320 ms. The address acknowledgement notifies the caller that its IP address has been received and thereby terminating the address exchange process. Method to retransmit the IP address

[00115] Through testing, it was determined that the loss of DTFM codes over the PSTN is the main reason for the address exchange process to fail. Although the PSTN cannot be changed, an address retransmission method is provided to improve the success rate of the address exchange method.

[00116] As the name implies, the address retransmission method involves one device transmitting the address codes several times to the other device. The address retransmission can be divided into two scenarios: when the address code fails the checksum test and when less than all the address codes are received from the other side.

[00117] In the first scenario, a first device has received all the address codes form a second device but the address code fails the checksum test. This is because the PSTN has distorted the address codes.

[00118] When the first device is the callee in Fig. 6 and detects a checksum failure, it does not know whether or not the second device (a caller) has correctly received the callee address codes. Thus, the callee device retransmits the callee address codes to cause the caller device to retransmits the caller address codes. Alternatively, if the callee address codes have been correctly received by the caller, the callee does not need to retransmit its address with the checksum and it only transmits the checksum alone.

[00119] When the first device is the caller device-.in Fig. 6 and detects a checksum failure, it does not transmit the caller address codes and waits for the callee device to retransmit the callee address codes after timing out from not receiving the caller address codes from the caller device. Alternatively, the caller can retransmit the caller address codes with the reserve bit set to 0 to inform the callee that the callee address codes failed the checksum, The timeout procedure is described in the second scenario below.

[00120] In the second scenario, the retransmission method includes a timeout mechanism.

When a first device is waiting for the address code from a second device, the first device starts a timer. When the first device is a callee, it will retransmit the callee address codes if it has not received all the address codes within a timeout. When the first device is a caller, it will not transmit the caller address codes and it will wait for the callee device to retransmit the callee address codes after timing out from not receiving the caller address codes from the caller device. For the retransmission method to work, it must use an appropriate timeout period and devise steps that do not break the synchronization of the address exchange process. Note that if only one address code is lost, a device can attempt to calculate the lost code as described above and carry on the next procedure by sending its own address codes or the next handshaking step.

[00121] The timeout period and the synchronization of the address exchange process are interrelated and cannot be handled separately. If the timeout period is too short, it is possible to for the transmissions from both sides to collide. Thus, the timeout period must be computed according to the number of the address codes and the DTMF transmission time. Assume the number of address code is n, and the DTMF transmission time for one code is T, then the timeout period can be set as n * T + C so that no collision will occur during retransmission. C represents a variable used to accommodate the time difference between the devices in the system caused by decoding and transmission. For example, if n is 10, T is 160 ms, then the timeout period can be set to 2,000 ms so C is 400 ms.

[00122] Consider an extreme situation where the timeout of (n * T + C) cannot satisfy the synchronization between devices. Assume devices A and B are exchanging IP addresses, and the last one of DTMF codes which B transmits to A is lost. Assume that B finishes transmitting the IP address at the time point TB so that B starts to calculate the timeout from time TB. B will retransmit when it does not receive the IP address code from A after the time reaches TB + n * T + C. The time which A receives the second to last address code from B is TA « TB - T. Thus, A starts to calculate the timeout from time TB - T, and it retransmits at TB - T + n*T + C. Unfortunately, B may start retransmitting when the first address code or the following address codes transmitted by A to B is lost and B times out before it receives the retransmission of the address code from A. At this time, the address codes from A and B will collide on the PSTN line and the synchronization between the two sides will be destroyed. Therefore, in this scenario, the timeout period must be increased.

[00123] So, the timeout period has to change according to if a device has received part of the address codes. If a device has received part of the address codes, timeout TO is set to n * T + C. If not, then timeout TO is set to 2 (n * T + C). Assuming n is 10 and T is 160 ras, the following ranges of the timeout TO may be used: (1) when receiving part of address codes, the range of TO is [1800, 2200], preferably 2,000 ms; (2) when not receiving any address code, the range of TO is [3600, 4400], preferably 4,000 ms.

[00124] Fig. 7 is a flowchart of a method for a first device to use the appropriate timeout while waiting to receive IP address codes from a second device in one embodiment of the invention. The first device can be the callee and the second device can be the caller in Fig. 6, or vice versa.

[00125] In step 702, the first device sets a first timeout to (n*T + C), sets a second timeout to 2(n*T + C), and starts a timer. When the first device is the caller, it starts the timer after it transmits the handshake acknowledgement. When the first device is the callee, it starts the timer after it sends the callee address codes. Step 702 is followed by step 703.

[00126] In step 704, the first device determines if it has received at least part of the IP address codes (e.g., at least one IP address code) from second device within the first timout. If so, then step 704 is followed by step 706. If not, then step 704 is followed by step 712.

[00127] In step 706, the first device determines if it has received all the IP address codes.

If so, then step 706 is followed by step 708. Otherwise step 706 is followed by step 716.

[00128] In step 708, the first device performs checksum test on the received IP address from the second device. If the received IP address fail the checksum test and the first device is the callee in Fig. 6, then the first device retransmits the callee IP address with the reserve bit set to 0 to cause the second device to retransmit the caller address.

[00129] If the received IP address codes fail the checksum test and the first device is the caller, then the first device does not transmit the caller address and waits for the second device to retransmits the callee IP address. Alternatively, the first device can retransmit the caller address with the reserve bit set to 0 to cause the second device to retransmit the callee address.

[00130] In step 712, the first device determines if it has received all the IP address codes within the second timeout. If so, then step 712 is followed by step 708 described above. If not, then step 712 is followed by step 716.

[00131] In step 716, the first device determines if the IP address codes is missing only one code. If so, then step 716 is followed by step 718. Otherwise step 716 is followed by step 720.

[00132] In step 718, the first device reconstructs the lost code as described above. If the lost code cannot be reconstructed and the first device is the callee in Fig. 6, then the first device retransmits the callee IP address with the reserve bit set to 0 to cause the second device to retransmit the caller address.

[00133] If the lost code cannot be reconstructed and the first device is the caller in Fig. 6, then the first device does not transmit the caller address and waits for the second device to retransmits the callee IP address. Alternatively, the first device can retransmit the caller address with the reserve bit set to 0 to cause the second device to retransmit the callee address.

[00134] In step 720, if the first device is the callee in Fig. 6, then it retransmits the callee

IP address to cause the second device to retransmits the caller address.

[00135] If the first device is the caller in Fig. 6, then the first device does not transmit the caller address and waits for the second device to retransmits the callee IP address. Alternatively, the first device can retransmit the caller address with the reserve bit set to 0 to cause the second device to retransmit the callee address.

[00136] Various other adaptations and combinations of features of the embodiments disclosed are within the scope of the invention. Numerous embodiments are encompassed by the following claims.

Claims

CLATMS

1. A method for a first device to exchange network addresses with a second device over a public switched telephone network (PSTN), comprising:

communicating a handshake request and a first handshake acknowledgement with the second device, the handshake request comprising a first plurality of dual-tone multi- frequency (DTMF)- codes, the first handshake acknowledgment comprising a second plurality of DTMF codes; and communicating at least one network address with the second device, the network address being represented by a third plurality of DTMF codes.

2. The method of claim 1 , wherein said communicating a handshake request and a first handshake acknowledgement with the second device comprises: transmitting the handshake request to the second device, the handshake request indicating if the first device believes it has a public network address; and receiving the first handshake acknowledgement from the second device, the first handshake acknowledgement indicates if the second device believes it has a pubic network address.

3. The method of claim 2, wherein said communicating at least one network address with the second device comprises: after said receiving the first handshake acknowledgment from the second device, transmitting the third plurality of DTMF codes to the second device, the third plurality of DTMF codes representing a first network address of the first device; after said transmitting the third plurality of DTMF codes to the second device, receiving a fourth plurality of DTMF codes from the second device, the fourth plurality of DTMF codes representing a second network address of the second device.

4. The method of claim 3, wherein the third and the fourth pluralities of DTMF codes each comprises eight DTMF codes representing a 32-bit integer of a network address of a corresponding device.

5. The method of claim 4, wherein the third and the fourth pluralities of DTMF codes each comprises two DTMF codes representing 7 bits that form a checksum for the eight DTMF codes and 1 bit that indicates if another network address of the other device has been correctly received.

6. The method of claim 5, further comprising:

determining if the fourth plurality of DTMF codes is missing a single DTMF code; when the fourth plurality of DTMF codes is missing a single DTMF code: determining if the missing single DTMF code is located between two DTMF codes or at one end of received DTMF codes; when the sin ^•Όgle DTMF code is located between two DTMF codes: determining the missing DTMF code from the checksum; and reconstructing the fourth plurality of DTMF address codes by placing the missing DTMF code at its proper location among the received DTMF codes.

7. The method of claim 6, when the missing single DTMF code is located at one end of the received DTMF codes, further comprising: calculating the first DTMF code from the received DTMF codes;

calculating the last DTMF s code from the received DTMF codes; determining if the missing single DTMF code is a first DTMF code or a last DTMF code, wherein:

the single missing DTMF code is the first DTMF code when the first DTMF code has a valid DTMF value and the last DTMF code does not have a valid DTMF value; and

the single missing DTMF code is the last DTMF code -when the last DTMF code has a valid DTMF value and the first DTMF code does not have a valid DTMF value,

8. The method of claim 7, further comprising: when the first and the last DTMF codes both have valid or invalid DTMF values, retransmitting the third plurality of DTMF codes to the second device to cause the second device to retransmit the fourth plurality of DTMF codes to the first device,

9. The method of claim 6, wherein said determining if the missing single DTMF code is located between two DTMF codes or at one end of received DTMF codes comprises:

determining intervals between adjacent DTMF codes; determining an average interval; determining an upper limit of the average interval as the sum of the average interval and half of the average interval;

determining if a maximum interval from the intervals is less than the upper limit of the average interval; wherein the single missing DTMF code is located at one end of the DTMF codes when the maximum interval from the intervals is less than the upper limit of the average interval; and

wherein the single missing DTMF code is located between adjacent DTMF codes with the maximum interval when the maximum interval from the intervals is not less than the upper limit of the average interval.

10. The method of claim 5, further comprising, prior to said transmitting a handshake request to the second device: answering a telephone call from the second device.

1 1. The method of claim 10, further comprising, after said answering a telephone call from the second device and prior to said transmitting a handshake request to the second device:

waiting a first period of time before said transmitting a handshake request to the second device.

12. The method of claim 11 , further comprising, after receiving the first handshake acknowledgment and prior to said transmitting the third plurality of DTMF codes to the second device: waiting a second period of time before said transmitting the third plurality of DTMF codes to the second device.

13. The method of claim 12, further comprising, after said receiving a fourth plurality of DTMF codes from the second device, waiting a third period of time before transmitting a second handshake acknowledgement to the second device, the second handshake acknowledgment comprising a fifth plurality of DTMF codes indicating the second network address of the second device has been correctly received.

14. The method of claim 13, wherein the first period of time is 1,800 ms, the second period of time is 640 ms, and the third period of time is 240 ms.

15. The method of claim 3, further comprising, after said transmitting the third plurality of DTMF codes to the second device: starting a timer; and when only part of the fourth plurality of DTMF codes is received from the second device within a first timeout, retransmitting the third plurality of DTMF codes to the second device to cause the second device to retransmit the fourth plurality of DTMF codes.

16. The method of claim 15, further comprising:

when no part of the fourth plurality of DTMF codes is received within the first timeout and only part of the fourth plurality of DTMF codes is received from the second device within a second timeout, retransmitting the third plurality of DTMF codes to the second device to cause the second device to retransmit the fourth plurality of DTMF codes.

17. The method of claim 16, wherein the first timeout is equal to n*t + C, the second timeout is equal to 2 (n*t + C)₃ n is the number of DTMF codes in the third and the fourth plurality of DTMF codes, t is the transmission time for a single DTMF code, and C is a constant accommodating synchronization variations.

18. The method of claim 2:

wherein, when the handshake request indicates the first device believes it has a public network address and the first handshake acknowledgment indicates the second device believes it does not have a public network address, said communicating at least one network address with the second device comprises transmitting the third plurality of DTMF codes to the second device, the third plurality of DTMF codes representing a network address of the first device; the method further comprising: receiving a data packet from the second device;

determining a network address of the second device from the data packet; and sending data packets to the second device.

19. The method of claim 2: wherein, when the handshake request indicates that the first device believes it does not have a public network address and the first acknowledgment indicates that the second device believes it has a public network address, said communicating at least one network address with the second device comprises: after receiving the first handshake acknowledgment from the second device, transmitting a fourth plurality of DTMF codes to the second device, the fourth plurality of DTMF codes indicating the first device has not correctly received the IP address of the second device; and

receiving the third plurality of DTMF codes from the second device, the third plurality of DTMF codes representing a network address of the second device; and

the method further comprising:

sending a data packet to the second device, wherein the second device determines a network address of the first device from the data packet; and receiving data packets from the second device.

20. The method of claim 2, wherein said communicating at least one network address with the second device comprises: after said receiving a first handshake acknowledgment from the second device, transmitting the third plurality of DTMF codes to the second device, the third plurality of DTMF codes representing a network address of the first device; after said transmitting the third plurality of DTMF codes to the second device, receiving a fourth plurality of DTMP codes from the second device, the fourth plurality of DTMF code representing a network address of the second device;

after said receiving a fourth plurality of DTMF codes from the second device, determining from the fourth plurality of DTMF codes that the second device has not correctly received the network address of the first device; and

retransmitting the third plurality of DTMF codes to the second device.

21. A method for a first device to communicate with a second device over a public switched telephone network (PSTN), the first device being in a private network, comprising: calling the second device; receiving a handshake request from the second device, the handshake request comprising dual-tone multi-frequency (DTMF) codes that indicates the second device is in a private network; and in response to the handshake request, providing a telephone call between the first and the second devices over the PSTN.