TWI442742B - Performance enhancement protocol, systems, methods and devices - Google Patents

Description

Performance enhancement protocol, system, method and device Field of invention

The present invention relates to communications, and more particularly to systems, methods, apparatus, and related protocols for improving the performance and efficiency of high speed media applications, such as voice over IP, via optimized bandwidth.

Background and review

Traditionally, circuit switching technology is used to transmit telephone calls. The traditional circuit switching technology still widely used today has some unique limitations. One of the limitations is that this technique establishes a permanent (or persistent) connection between the calling party and the called party during the entire call, thus requiring a significant amount of bandwidth to be dedicated to each call. In addition, traditional circuit-switched technology only supports certain types of calls, especially for phone-to-phone calls. The network used by traditional telephone companies is called the Public Switched Telephone Network (PSTN), which provides voice communication and data communication over circuit-switched networks. PSTN is currently the network that provides most of the telephone service to end users.

In order to avoid the additional management data volumes and restrictions (economic, regulatory, physical, and other) imposed by the PSTN, many traditional telephone companies, along with multiple originating entities, have begun to use the Internet infrastructure to connect calls. This type of service delivers voice, video, text and other instant media over an Internet Protocol ("IP") network. This type of technology is commonly known as IP Telephony ("IPTel") or voice over IP ("VoIP "). VoIP refers to the transmission of voice communications (also known as "telephone conversations") over an IP network such as the Internet. As used herein, the term VoIP is synonymous with the more commonly used term IP telephony (IPTel). In other words, as used herein, VoIP is not limited to voice communication, and VoIP can include voice video text and other instant media. VoIP usually refers to calls over an IP network such as the Internet. This means that the calls are routed through the IP network to the Internet, or to the call through a privately managed data network that uses IP to transfer the assignment from one location to another. (Internet Protocol is currently the most widely used packet exchange protocol for the transmission of data between computer systems, in addition to being used over the Internet.)

In general, for VoIP calls, the voice stream is broken into multiple packets, which are compressed and sent over multiple routing paths to their final destination. Unlike traditional PSTN, there is no need to establish a permanent connection or a persistent connection during a VoIP call. Once the packet is received at the final destination, the packet is reassembled, decompressed, and returned to the voice stream.

According to an embodiment of the present invention, a method for operating in an architecture is provided, which uses a packet voice communication system, and at least part of the communication system is performed through a satellite link, and the method includes using a first The agreement establishes a first session between the caller and the cache agent, wherein the caller communicates with the cache agent via the satellite link; and establishes a second agreement with the first agreement a second session between the cache agent and a called party, and providing communication from the calling party to the second party and from the second party to the first party.

Simple illustration

The invention will be further understood by reading the following description with reference to the accompanying drawings in which: FIG. 1 and FIG. 2 illustrate the operation of a satellite telephone system; FIG. 3 shows the layout of a typical packet; FIG. 4-5 shows Communication architecture according to an embodiment of the present invention; FIG. 6 shows an adapter structure according to an embodiment of the present invention; FIG. 7 shows an encoder structure according to an embodiment of the present invention; and FIG. 8 shows an implementation according to the present invention Example of operation of the encoder; Figure 9 shows a decoder in accordance with an embodiment of the present invention; Figure 10 shows the operation of the decoder in accordance with an embodiment of the present invention; and Figure 11 shows an embodiment in accordance with the present invention One of the adapters is a satellite data machine; and Fig. 12 shows an example of the operation of the present invention.

Detailed description of the preferred embodiment

1 shows a typical VoIP system/architecture 100 that uses a satellite link 102 to connect a first phone 104 to a second (remote) phone 106 over an IP network 108. The first telephone 104 is connected to the satellite data machine 110, for example, via an integrated access device (IAD) 112.

Typically, IAD is a device that integrates voice, data, and the Internet and associated managed services such as VoIP over a single wide area network (WAN) network connection. The IAD can also be used as a type of gateway for bridging an IP network with a PBX (Private Branch Exchange) or PSTN.

Although illustrated by "telephone", the first telephone 104 can be a personal computer or any other type of device that can be used to transmit and receive voice material using the VoIP system 100. Those skilled in the art will appreciate that the IAD 112 can be coupled to the telephone 104 or to the satellite data unit 110.

At the other end of satellite link 102, a second satellite modem 114 is coupled to IP network 108. Information from the IP network 108 can be provided to the PSTN 116 via a gateway 118. As is well known in the art, gateways are devices used to connect one type of network to another type of network. For example, as shown here, a gateway is used to connect the legacy PSTN network 116 to the IP network 108. In general terms, the mission of the gateway is to provide interworking and to convert information from one network to another.

The typical telephone call used in the architecture shown in Figure 1 works as follows (refer to Figure 2): the user on the initial call (in this case, phone 104) picks up the phone from the call, dials out The second telephone (telephone 106) corresponds to the telephone number (or uses the computer to perform several equivalent functions in an attempt to connect to the second telephone 106). This caused the system to try to establish a connection between the two phones. The most commonly used protocol for establishing such connections is called SIP (the initial agreement for the talk period), and SIP is defined by the IETF, and those skilled in the art understand how SIP operates in the VoIP architecture. Those skilled in the art will appreciate that SIP indicates an example of agreement, and other suitable agreements may also be used and are considered to be within the scope of the present invention. By way of example and not limitation, other VoIP protocols may be used, such as MGCP (Media Gateway Controller Program) and H.323.

Once a pair of conversations has been established between the two phones, a two-way conversation can begin. Since the dialogue is transmitted over one or more digital networks, the actual speech data is first converted to digital form by analogy. Such A-D conversion can be performed inside the telephone (or telephone) or can be performed by an external adapter such as IAD 112. Once the data is in digital form, the data is then compressed (using an instant agreement, such as RTP/UDP/IP), placed inside the packet, and sent over the network to its destination. In the case of an architecture including a satellite link (such as shown in FIG. 1), the packet is converted to the appropriate form by satellite data machine 110 and transmitted to second satellite data machine 114 via satellite link 102. The recipient's second satellite modem 114 converts the packet into an appropriate form and sends the packet over the IP network 108. In the illustrated architectural example, in order to reach the second telephone 106, the packet must pass through the gateway 118 and the PSTN 116. The data packet is sent to a certain point before the second call, and the data packets must be arranged in the correct order and unpacked. The payload data of the data packet must be decompressed and transferred back to the analogy. In the illustrated case, the gateway 118 can perform a number of such functions.

In other words, VoIP works by digitizing speech into data packets, sending the packets, and re-transferring the data packets back to speech at their destination. In order to control the packet's communication over a packetized network (such as a TCP/IP network) and to pass through such a network to a destination, each packet must contain certain addresses and other control information. Other control information for these addresses is stored in a so-called packet header. The actual data in the packet is also the payload of the packet, which is typically stored separately from the header. VoIP uses headers to roam through the network to its destination. The payload contains a dialogue bit.

In a VoIP architecture such as that shown in Figure 1, the voice is sent in the form of a so-called UDP (User Profile Protocol) packet. UDP is a connectionless transport layer protocol in a TCP/IP protocol stack. UDP is a simple protocol for exchanging pieces of information without acknowledging or guaranteeing the transmission. UDP requires error handling and retransmission by other protocols. The data slice term is used to describe the data that is encapsulated for network transmission. In other words, UDP is a TCP-like protocol that is executed on top of an IP network. UDP is mainly used to broadcast messages over the Internet. UDP uses Internet Protocol to transfer data from one computer or device to another, but UDP does not divide the message into sorted packets, nor does it reassemble the packets at the other end.

Figure 3 shows the logical format of a typical UDP/IP packet containing a voice data payload. In the example shown in the figure, which is a typical TCP/IP network today, the packet header consists of 40-bit tuple header data: a 20-bit IP header, an 8-bit UDP header, And a 12-bit RTP header. Skilled artisans understand that the actual payload size of such packets is determined by the speech compression system/deductive rules used by the system. For several embodiments, the payload can be 20 or 40 bytes. The deductive rule used to compress/decompress dialog or audio signals in VoIP is referred to as a codec. Speech codecs in typical and currently widely used VoIP systems include g.723.1, g.711, and g.729, each of which is defined to be compressed at a very low bit rate, such as a portion of the H.324 family of standards. Conversation or audio signal component. The g.723.1 codec has two associated bit rates: 5.3 kbps and 6.3 kbps. Preferably, a 6.3 kbps bit rate is used. The g.729 codec describes a compression deduction rule in which speech is encoded into an 8 kbps stream.

If the G.723.1 codec is used at 6.3 kbps, the voice (payload) portion of the packet will be a 24-bit tuple representing 30 milliseconds of speech. If a G.729 codec is used (at 8 kbps), the payload portion of the packet will be 20 octets per 20 milliseconds of speech.

Figure 4 shows a VoIP architecture 120 in accordance with an embodiment of the present invention. As shown, the VPEP (Voice Performance Enhancement Protocol) adapter 122 is coupled to the first phone 104. More specifically, the VPEP adapter 122 is coupled to the IAD 112 and the satellite modem 110 so that signals between the IAD and the satellite modem can pass through the VPEP adapter (and can be processed by the VPEP adapter). Although shown as separate component elements in the drawings, the VPEP adapter can be integrated into the satellite data machine and/or integrated into the IAD. Figure 5 shows a VoIP architecture in which a VPEP adapter is integrated with a data machine (to provide a VPEP-enabled or VPEP-enabled satellite modem 111).

In the preferred embodiment of the present invention, the VPEP cache proxy 124 is tied to the other end of the satellite link 102 and is coupled to the satellite hub or to the satellite hub. In view of the nature of the guest-host (or guest-guest) of the operational aspects of the operation of the present invention, the adapter 122 can also be referred to as a guest (guest).

Figure 6 shows the logical structure of the aspect of the adapter 122 in accordance with an embodiment of the present invention. Some components such as a power supply are removed from the figure. As shown in FIG. 5, the adapter 122 in accordance with an embodiment of the present invention includes a VPEP encoder 126 and a VPEP decoder 128. The encoder 126 receives the data from the IAD, processes the data, and provides the processed data to a data machine. On the other hand, the decoder 128 receives the data from the data machine and provides it to an IAD.

A VPEP encoder 126 in accordance with an embodiment of the present invention is shown in FIG. 7, including a data controller 130 that can analyze received data (e.g., received by an IAD). The data controller 130 can be constructed from a user interface 132. The data controller 130 can receive packetized voice material or other types of data (described in detail later). If the data controller 130 determines that the input IP packet contains voice material, the packet is transmitted to the VPEP translation mechanism 134 for further processing (details are detailed later), otherwise the IP packet is transmitted (as the IP data traffic is transmitted).

The VPEP translator 134 takes the voice data packet and generates a corresponding VPEP packet. As shown in Figure 8, one or more IP packets can be converted into a single VPEP packet. The header information from the IP packet can be completely removed and replaced with the VPEP header. The contents of the VPEP header and its usage are described below. The VPEP header can have only one byte, or larger. In addition to removing IP header information, in some embodiments, voice material from an IP packet can be further compressed prior to placement in the VPEP packet.

The VPEP data traffic (in other words, the VPEP packet generated by the VPEP translation mechanism in this example) is sent to the modem along with the IP data traffic not processed by the VPEP translator.

The VPEP decoder 128 receives the VPEP and other communications from the data machine and converts these into a stream of data that can be processed by the IAD or other device connected thereto. A VPEP decoder 128 in accordance with an embodiment of the present invention is shown in FIG. The data analyzer 138 receives the input packet stream (both IP and VPEP) (eg, from the data machine) and forwards the packets back to the IP data stream. Translator 140 converts the VPEP packet from the incoming stream into an IP packet. As shown in FIG. 10, the voice data of the VPEP packet is converted into an IP voice data of an appropriate form, and then the voice data is re-encapsulated into an IP packet containing the original IP header reinserted.

When the data flow control unit 136 is operable, it regulates the output data before it is sent to the data machine. The data flow control mechanism 136 (when operational) is used to determine the flow rate of the transmitted data present on the network in addition to the voice data traffic. The data flow control mechanism 136 analyzes the data transmission requirements of the voice data traffic and shapes the transmission rate of the non-instant data traffic (eg, giving voice packets or VPEP packets a higher priority than non-voice packets).

Figure 11 shows the integration of the VPEP adapter with the satellite modem to form the components of the VPEP capable (or VPEP enabled) satellite modem.

If a VoIP call is made to another VPEP-enabled telephone system, the architecture can be considered (and thus the views of the two phones can be considered) the guest-bin system. In accordance with an embodiment of the invention, each phone will be connected to a VPEP adapter. The phone will negotiate its own VPEP interview period and will allow each to know which IP header information will be added back to the packet upon reorganization.

In the case of a VPEP-enabled guest phone to a non-VPEP-enabled phone, a VPEP Cache Agent 124 (in Figure 4) is used to establish a VPEP session between the two phones. According to an embodiment of the invention, the VPEP cache proxy server also includes a VPEP encoder 126 and a VPEP decoder 128. Data traffic from non-VPEP-enabled phones transmitted via satellite is encoded using an encoder, and VPEP data traffic received via satellite is decoded before being sent to the appropriate telephone (transmitted over IP or other network).

Figure 12 shows the operation of such a call. By way of example, assume that the initial call is VPEP enabled (i.e., as shown in Figure 4, the phone can be operated via the VPEP adapter, or as shown in Figure 11, the phone has a VPEP enabled satellite modem). When the initial call is picked up and the far end phone number is dialed, the VPEP client 122 attempts to establish a VPEP talk session with the VPEP cache agent 124. Once such a talk session is established, the VPEP cache agent 124 then attempts to establish a talk period with the called/remote phone 106. The intercommunication period between the cache proxy server 124 and the called telephone 106 will be established using a protocol such as SIP. The conversation period is established, the initial call is in two-way and a VPEP conversation is performed with the VPEP cache proxy server, and the cache proxy server communicates with the called telephone RTP or the like in two directions. From the point of view of the called phone, the call is made on the initial phone, but in fact the cache agent is disguised as the initial call.

As such, once the VPEP session or SIP session is established, the conversation from the initial call passes through IAD 112 to VPEP Adapter 122 (which may be on satellite modem 111 or on a separate device). The voice is translated into VPEP data traffic (along with non-VPEP data traffic) is sent to the VPEP cache proxy server. The VPEP cache proxy server decodes the VPEP data traffic, combines it with the non-VPEP data traffic, and transmits the data traffic to the called phone as RTP data traffic. The RTP data traffic from the called phone is converted to VPEP data traffic by the VPEP cache agent server and sent (via the satellite link) to the initial phone. The VPEP data traffic from the cache proxy server is decoded by the VPEP decoder in the VPEP adapter, and the decoded data traffic is sent to the phone. If the initial call and the called call are VPEP enabled, the cache proxy server can be skipped and a VPEP talk session can be established directly between the two phones. The VPEP enabling device (via the message content) can determine if the cache proxy server has been skipped. If the destination device confirms the receipt of the VPEP packet, the originator will establish VPEP communication directly between the two devices. For communication between two devices that require IP header information, the assembly device includes IP header information to travel through the IP network.

VPEP header

In a presently preferred embodiment of the invention, the VPEP packet includes header information for a byte (as shown in Figures 8 and 10). This byte contains one half-byte (4 bits) representing the increasing ordinal number and one half-byte (4 bits) representing a unique conversation period id. This information, along with the MAC address, is used to determine the identity of the interview period. In these embodiments, the device can support up to 15 unique conversation periods. The number of such talk periods is considered sufficient for a number of applications of the present invention. However, skilled artisans understand that if more unique conversations are needed, other coding systems, or larger VPEP headers, can be used.

Further, in some embodiments of the present invention, when the talk period id is determined to be invalid, a special packet is transmitted. The size and structure of these packets vary depending on the message being delivered. For example, a DTMF (Double Tone Multi-Frequency) event message consists of a special message describing it as a DTMF number, along with the length and magnitude of the number.

Silence suppression

Recall that a traditional PSTN type telephone call provides a dedicated circuit for the time period of a call. The circuit is released when the call is terminated by either party (signal hanged by phone call, etc.). When either party detects that no message from the other party has experienced a certain period of time, the call link will also be released. Since VoIP phone calls do not have dedicated circuitry or continuous circuitry, a variety of methods can be employed to maintain the action of the talk period in the presence of unpredictable delays. One of these techniques is to send a so-called "silence" or "comfort" message between two directions even when no actual voice data traffic is sent. In addition to maintaining the interactivity between the two parties, these silent messages will prevent them from being terminated. These silent messages will provide some level of comfort to the user via some form of white noise. People understand that the connection is still working. In a typical VoIP system, silence is transmitted in a complete IP packet with a predetermined payload to indicate proper silence (ie, white noise, ie, silent sound).

In still another aspect of the present invention, in some embodiments, the VPEP encoder recognizes silence (e.g., VPEP translator 134) and encodes silence into a special silence represented by a single byte VPEP header (or Consolation) Streaming, the VPEP stream can indicate that the remote silence is being sent. In several embodiments of the invention, an indication of the length of the silence is included. At the far end, ie, at the VPEP cache proxy server, the VPEP silent packet is decoded into the appropriate number of IP silent packets and sent to the called party. In this way, the VPEP cache proxy server silently spoofs the remote end and maintains the SIP session. In a similar manner, the VPEP Cache Agent can send a VPEP Silent Packet to the caller if needed.

In some embodiments of the present invention, the VPEP adapter/data machine 111 can send silence/comfort noise to the (same location) phone 104 when no voice packets are present for playback. The VPEP cache proxy server 124 can send silence/comfort noise to the non-VPEP capable device (i.e., PSTN phone) when there is no voice packet to be broadcast in its direction. In this way, the present invention can perform an ideal remote silence suppression, i.e., each end derives its own silence without silent travel through the satellite link.

Satellites typically use a Constant Bit Rate (CBR) system and occasionally use a dedicated access (DA) system to "guarantee bandwidth" on the loopback path (the loopback path from the user to the satellite hub). The rule is usually associated with a trigger (ie, traveling to a given UDP port) and a timeout (there is no data traffic on the port for a certain period of time). A number of embodiments of the present invention provide a "maintenance operation" mechanism that sends a very small packet to send a designated UDP port to maintain the CBR or DA access operable.

The following table summarizes the bandwidth and other advantages obtained through the use of the present invention. The data in the table is based on the average of the two bytes of each VPEP header. This is the case where there are more than 15 actionable channels in any location (as explained above, the current preferred header size is 1 byte).

The data in the table is described in the size of each pair of talk boxes (the number of milliseconds per packet) for the transmission rate of a particular codec. For example, for a 6.3 Kbps G.723.1 codec, a single frame consists of a 30 millisecond conversation (ie, a 24-bit tuple). With additional management data for IP, the packet size is increased to 78 bytes (MAC = 14 bytes, IP = 20 bytes, UDP = 8 bytes, and RTP = 12 bytes). Using an embodiment of the invention with VPEP, the packet size is reduced to 40 bytes, and the amount of additional management data (and thus the bandwidth used) is reduced from 70% to 40%. Different silence suppression rates can achieve further reduction in bandwidth usage.

Special event handling

Some so-called special events may occur during a telephone call. These events include non-speech signals (eg, DTMF tones) that are sent by one phone to another. The DTMF tone is the sound that is heard when the button of the phone is pressed, and can be used by the caller to access, for example, a voice mailbox, a bank account, or any other service that can be accessed via the phone.

Embodiments of the present invention handle special events as follows. The VPEP translator 134 identifies special packets containing DTMF tones and transmits special VPEP packets representing the tones. In other words, a special VPEP packet representing the tone is sent for each possible DTMF tone. The special event VPEP packet is identified at the remote VPEP decoder and the special event VPEP packet is converted into an appropriate IP packet with the appropriate tone. In this way, special events can be handled with minimal bandwidth without loss. Similar processing also occurs with special events from the called party.

Embodiments of the present invention support some or all of the following special events: DTMF/MF, Silent Content Change, FAX Header, and T38 or Relay.

In a preferred embodiment of the invention, all of the normal RTP voice packets contain a 1-bit VPEP header (4-bit talk period ID, 4-bit sequence number). The rest of the packet contains a coded payload-talking information.

The special event packet type starts with sessionID=0. The VPEP packet starting at sessionID=0 will then follow the special event. After the first byte sessionID, it is the actual session ID of the 4-byte, followed by the 4-bit sequence number (as in different VPEP packets). Second, the byte contains a special event type. Special event types include: DTMF/MF/Reminder tone generation/copying. Silent packet event. Maintain operational events. Talk about coding and decoding change events. Fax event (relay/t38)

Example:

Silent packet: (Silent packets can be configured to be sent as a continuous event, or sent when changed)

This demonstrates performance enhancement protocols, systems, methods, and devices.

Although the term "speech" is used throughout the text to describe the material to be transmitted, those skilled in the art understand that unless otherwise stated, "voice" includes voice, video, text, and other instant media, either alone or in combination.

Although the present invention has been described in terms of a number of codecs, such descriptions are for illustrative purposes only, and those skilled in the art will appreciate that the present invention is applicable to any codec without the particular code used for its description. The example of the decoder is limited.

Although the present invention has been described in terms of satellite transmission, the description is by way of example and is not intended to limit the scope of the invention. Those skilled in the art understand that the aspects of the present invention are applicable not only to satellites, but also to any media operating under an IP protocol.

Although the present invention has been described as being the most practical and preferred embodiment, it is to be understood that the invention is not limited to the disclosed embodiments, but the invention is intended to cover the scope of the appended claims. And various modifications and equivalent configurations within the scope.

100. . . Voice over IP (VoIP) system/architecture, VoIP system

102. . . Satellite link

104. . . First call

106. . . Second phone, remote phone

108. . . IP network

110. . . Satellite data machine

112. . . Integrated access device (IAD)

114. . . Second satellite data machine

116. . . PSTN, public switched telephone network

118. . . Gateway

120. . . VoIP architecture

122. . . VPEP (Voice Performance Enhancement Protocol) Adapter

124. . . VPEP cache proxy server

126. . . VPEP encoder

128. . . VPEP decoder

130. . . Data controller

132. . . user interface

134. . . VPEP Translation Agency

136. . . Data flow control mechanism

138. . . Data analyzer

140. . . Translator

1 and 2 illustrate the operation of a satellite telephone system; Figure 3 shows the layout of a typical packet; Figures 4-5 show the communication architecture in accordance with an embodiment of the present invention; and Figure 6 shows the implementation in accordance with the present invention; Example of an adapter structure; FIG. 7 shows an encoder structure according to an embodiment of the present invention; FIG. 8 shows an operation of an encoder according to an embodiment of the present invention; and FIG. 9 shows one embodiment according to the present invention a decoder; FIG. 10 shows the operation of the decoder according to an embodiment of the present invention; FIG. 11 shows a satellite data machine incorporating one of the adapters according to an embodiment of the present invention; and FIG. 12 shows the operation of the present invention Example.

104. . . First call

106. . . Second phone, remote phone

108. . . IP network

110. . . Satellite data machine

112. . . Integrated access device (IAD)

114. . . Second satellite data machine

116. . . PSTN, public switched telephone network

118. . . Gateway

120. . . VoIP architecture

122. . . VPEP (Voice Performance Enhancement Protocol) Adapter

Claims (21)

A method for communicating a near-end telephone device with a remote telephone device via a proxy server based on a voice-over-IP-based system for a first communication The protocol adapter is associated with the near-end telephony device, the first communication protocol being different from a TCP/IP protocol, the method comprising: (A) establishing a pair with the proxy server using the first communication protocol During the talk period, the conversation period established with the proxy server is associated with a pair of talk period identifiers, which are provided by the proxy server to identify the conversation period; (B) Receiving, by the adapter, a first packet from the near-end telephony device, the first packet being formatted and addressed to the remote telephony device according to a second communication protocol, the second communication protocol The first communication protocol is different, wherein the second communication protocol is the TCP/IP protocol, and wherein the first packet received from the near-end telephony device is a TCP/IP packet, and each of the first packets Including IP header information, and where the power is from the near end At least some of the TCP/IP packets received by the device include voice data; (C) determining, by the adapter, whether a packet of the first packets received from the near-end telephone device includes voice data, and When the packet received by the near-end telephone device does not include voice data, the packet is sent to the proxy server by an IP protocol packet, otherwise at least some of the TCP/IP packets actually containing the voice data are converted into the first packet. G One or more packets of the protocol, the conversion comprising combining at least some of the plurality of the TCP/IP packets containing the voice data into a packet of the first protocol, wherein the combining action comprises removing the voice data a header information of the plurality of the TCP/IP packets; and (D) transmitting the one or more packets of the first protocol to the proxy server, wherein the packets of the first protocol include a standard Header, the header containing the conversation identifier corresponding to the conversation period established with the proxy server; (E) receiving, by the adapter, a second packet from the proxy server, the The second packet is formatted according to the first communication protocol, and the second packet corresponds to a second TCP/IP packet received by the proxy server from the remote telephony device, and the second TCP/IP packet is addressed. And (F) converting, by the adapter, at least some of the received second packets from the first communication protocol to a plurality of corresponding third TCP/IP packets, wherein the first communication At least one second packet of the agreement is converted to include speech a plurality of corresponding third TCP/IP packets, and IP header information of the at least one second packet not present in the first communication protocol is added to the third corresponding TCP/IP Packets, the third TCP/IP packets are addressed to the near-end telephony device; and (G) the plurality of corresponding third TCP/IP packets are sent to the near-end telephony device. The method of claim 1, further comprising: determining one or more received from the near-end telephone device in step (B) Whether the TCP/IP packet indicates silence, and based at least in part on the determination, transmitting one of the silence indications to the proxy server, the indication including the one or more packets of the first communication protocol. The method of claim 2, wherein the indication of the silence comprises an indication of the length of the silence. The method of claim 1, comprising: determining whether one or more TCP/IP packets received from the near-end telephony device represent a dual tone multi-frequency (DTMF) event, and based at least in part on the determination, Sending an event message indicating one of the DTMF events to the proxy server, the event message including a single packet of the first communication protocol. The method of claim 4, wherein the event message includes an indication of one or more of (a) DTMF tonality, (b) DTMF amplitude, and (c) DTMF modulation. The method of claim 1, wherein the packet of the first communication protocol also includes encoded payload information. The method of claim 1, wherein the packet of the first communication protocol comprises forming a 4-bit conversation period identifier and a 4-bit sequence number one byte header. A communication system comprising: (A) a proxy server; and (B) a communication device connectable to an integrated access device (IAD) and a satellite data device, the device comprising: (b1) an encoding For encoding packets received from the IAD, The packets are TCP/IP packets encoded according to the TCP/IP protocol, each of which includes IP header information, and some of the TCP/IP packets contain voice data, and the encoder is composed and Adapting to determine whether a packet received from the IAD includes voice data, and converting the TCP/IP packet including the voice data into one or more corresponding packets of a second communication protocol, and the second communication protocol The TCP/IP protocol is different, wherein the encoder combination includes at least some of the information of the TCP/IP packets of the voice data to become a single corresponding packet of the second communication protocol, wherein the combination includes removing the voice data included. The IP header information of the plurality of TCP/IPs, and wherein the packet of the second communication protocol includes a header having a pair of talk period identifiers; and (b2) a decoder for decoding The satellite data machine receives the packet from the proxy server, the received packet is encoded according to the second communication protocol, and the decoder is composed and adapted to receive the received data from the satellite data machine Some of the packets are converted into TCP/IP packets, wherein the decoder decodes at least one packet of the second protocol into a plurality of corresponding TCP/IP packets containing voice data, and wherein the packets are not presented in the first protocol IP header information is added to these corresponding TCP/IP packets. The communication system of claim 8, wherein the encoder determines whether one or more TCP/IP packets received from the IAD represent a dual tone multi-frequency (DTMF) event, and based at least in part on the determination, The The encoder generates an event message indicating the DTMF event, the event message containing a packet of the second agreement. For example, in the communication system of claim 9, wherein the event message includes an indication of one or more of (a) a DTMF tonality, (b) a DTMF amplitude, and (c) a DTMF modulation. For example, the communication system of claim 8 of the patent scope, wherein the packet of the second communication agreement also includes the encoded payload information. For example, in the communication system of claim 8, wherein the packet of the second communication protocol includes a 4-bit conversation period identifier and a 4-bit sequence number one byte header. The communication system of claim 8, wherein the encoder is further configured and adapted to determine whether one or more TCP/IP packets received from the IAD indicate silence, and based at least in part on the determining, generating the silence One indicates that the indication includes a single packet of one of the second communication protocols. The communication system of claim 13, wherein the indication of the silence includes an indication of the length of the silence. A communication system comprising: (A) a proxy server; and (B) a satellite data machine, the satellite data machine comprising: (b1) a communication mechanism for communicating with a satellite; and (b2) an encoding And a device coupled to the communication device for encoding a packet received from a device connected to the data device, and for providing the encoded packet to the communication device, received from the device The packets are encoded into TCP/IP packets according to the TCP/IP protocol, each of which includes IP header information, and the encoder is configured and adapted to convert the TCP/IP packets containing the voice data. Forming a packet of a second communication protocol, the second communication protocol being different from the TCP/IP protocol, wherein the encoder combination includes at least some of the information of the TCP/IP packets of the voice data to become the second communication protocol One corresponding to a single packet, wherein the combination includes IP header information to remove the at least some of the TCP/IP packets; and (b3) a decoder for decoding received from the proxy server via the communication mechanism a packet, the received packet including a packet encoded according to the second protocol, the decoder being configured and adapted to convert the received packet encoded according to the second protocol into a corresponding TCP/IP Encapsulating, and providing at least a portion of the TCP/IP packets to the device connected to the data device, wherein the decoder decodes at least one packet of the second protocol to become more than one corresponding TCP/IP including voice data a packet, and IP header information of the packet not present in the second protocol is added to the corresponding TCP/IP packet; and the packet of the second protocol includes a pair of session identifiers A header, the pair identifier identifier identifies a communication session with one of the proxy servers. A communication system according to claim 15 wherein the encoder determines one or more TCP/IP seals received from a device connected to the data machine. Whether the packet represents a dual tone multi-frequency (DTMF) event, and based at least in part on the determination, the encoder generates an event message indicating the DTMF event, the event message containing a packet of the second protocol. For example, in the communication system of claim 16, wherein the event message includes an indication of one or more of (a) a DTMF tonality, (b) a DTMF amplitude, and (c) a DTMF modulation. For example, in the communication system of claim 15, wherein the packet of the second communication agreement also includes the encoded payload information. For example, in the communication system of claim 15, wherein the packet of the second agreement includes a 4-bit conversation period identifier and a 4-bit sequence number one byte header. The communication system of claim 15, wherein the encoder is further configured and adapted to determine whether one or more TCP/IP packets received by the device connected to the data device indicate silence, and based at least in part on The determination produces an indication of the silence that includes a single packet of the second communication protocol. The communication system of claim 20, wherein the indication of the silence includes an indication of the length of the silence.