WO2000045555A1

WO2000045555A1 - Escape sequence protocol for multiplexing real-time data with non-real-time data

Info

Publication number: WO2000045555A1
Application number: PCT/US2000/002263
Authority: WO
Inventors: David C. Oliver
Original assignee: Data Race, Inc.
Priority date: 1999-01-28
Filing date: 2000-01-28
Publication date: 2000-08-03

Abstract

A system and method for low latency multiplexing of real-time and regular data in the same data frame. Real-time data (such as digitized voice) is multiplexed with regular (non-real-time data) across a communications link (such as a modem connection) by inserting the real-time data as a capsule in the same frame with regular data. The real-time data capsule is introduced by an escape sequence. The link's existing packet protocol (such as V.42/HDLC) may be so extended to provide low latency for the real-time data, with minimal impact on existing data-transfer efficiency. Before each data frame is transmitted, the transmitter may determines if real-time data will become available for transmission. If the real-time data will become available before the data frame will have been completely transmitted, the real-time data may be embedded within the frame as a capsule introduced by an escape sequence. The receiver may monitor the data stream for the escape sequence to determine where to start interpreting the data stream as real-time data. After inserting the capsule, the transmitter may resume transmitting the regular data. This continues until the end of the frame is reached. Special escape sequences may be used to prevent regular data sequences equal in value to the primary escape sequences from falsely indicating the beginning of a real-time data capsule.

Description

TITLE: ESCAPE SEQUENCE PROTOCOL FOR MULTIPLEXING REAL-TIME DATA WITH

NON-REAL-TIME DATA

Field of the Invention The present invention relates to the simultaneous transmission of real-time data (such as voice data) and non-real-time data, and more particularly to multiplexing real-time data with non-real-time data in the same data frame

Description of the Related Art Traditionally, separate communication links have been employed to transmit real-time data and non-real time data For non-real-time data, a modem may have been connected to a telephone line used to transfer a data file from one computer, across the public switched telephone network (PSTN), to be received by another modem and downloaded into another computer A regular telephone connection is an example of transferring real-time voice data from one user, across the PSTN, to another user If a user desired to transfer both voice data and non- real-time data simultaneously, two telephone connections were required For example, to speak m real time to the recipient of data file being transferred from one computer to another, one telephone connection was required for the real-time conversation (voice data) and another connection for transferring the data file (non-real-time data). Thus, individuals desiπng the ability to simultaneously transmit real-time and non-real-time data were required to maintain at least two separate telephone connections The requirement of two telephone connections added expense and complexity

Recogmzmg the desirability of simultaneous transfer of voice and non-real-time data, several mechanism have been introduced to permit the transfer of voice and non-real-time data simultaneously on the same telephone connection A common use of such systems is in the area of collaborative work, such as a whiteboard application which allows two users to annotate a shared document, for example, while simultaneously speaking to one another about the annotations on the same telephone line Simultaneous or multiplexed voice and data transmission is also popular in gaming applications A brief description of some of the existing solutions follows

Digital storage and communication of voice or speech signals has become increasingly prevalent in modern society, m particular in telephony Digital communication of speech signals comprises generatmg a digital representation of the speech signals and then transmitting those digital representations to a receiver upon a communications path The receiver receives the digital representation of the speech and converts the digital representation of the speech signals back into the original speech, or at least an approximation of the original speech

Once the voice encoded speech has been generated it may be transmitted to a receiver The receiver receives the voice encoded speech and decodes it to produce an approximation of the original speech Devices which perform v oice encoding and decoding are commonly referred to as voice encoder/decoders, or vocoders Because the amount of digital information which represents the voice encoded speech is typically much less than that required for the original speech, the voice encoded speech is also commonly referred to as compressed speech One recent application of using compressed speech in digital communications is in Digital Simultaneous Voice and Data (DSVD) modems. DSVD modems employ techniques for multiplexing compressed speecn with digital data for transmission over a normal telephone line A first DSVD modem compresses, or encodes, a transmitting subscriber's speech, statistically multiplexes it in frames between data frames from the transmitting subscriber's digital device such as a computer, and transmits the separate speech and data frames upon a telephone line to a second DSVD modem The second DSVD modem receives the multiplexed speech and data frames, separates the speech frames from the data frames, and decompresses, or decodes, the compressed speech back into the original analog speech signal so that it can be provided to the receiving subscriber. The same process occurs in the opposite direction, thus enabling the two subscnbers at each end of the telephone line to speak to one another, while simultaneously transferring data over the same line.

DSVD modems transmit data in data frames. A data frame marks the beginning and end of a segment of data and may contain additional information about the data format, etc., in a header. Voice data is transmitted in separate data frames from regular data. The separate frames are multiplexed so that the bandwidth is statisncally divided between voice frames and regular data frames For example, a 28.8 Kbps modem may simultaneously transmit regular data at 19.2 Kbps and voice at 9.6 Kbps However, DSVD modems have several disadvantages. By inserting a substantial amount of regular data between each real-time (e.g. voice) frame, the latency between real-time transfers is increased. This latency may result in the real-time data appearing or sounding "jerkv" The size of the data frames my be reduced to decrease this latency, but that results m increased overhead due to the overall increase in the number of frames. Therefore, decreasmg frame size to improve latency, decreases the overall data throughput. Several ad hoc DSVD implementations exist from communication vendors and DSVD is addressed in the International Telecommunication Union (ITU) V 70 standard. However, all of these implementation suffer from the above noted disadvantages.

Another technique for simultaneous voice and non-real-time data transmission is integrated services digital network (ISDN). ISDN provides a digital interface to the public switched phone network. Increased transmission rates are provided due to the digital interface Latency and overall throughput is improved with ISDN. An ISDN connection provides low level time-division multiplexing of voice and regular data, using hardware to allocate a fixed part of the data bandwidth between voice and regular data This adds complexity and special hardware to the system A special ISDN service must be subscπbed to from the phone company and may not be available in all areas. An ISDN service is typically more expensive. Furthermore, if the amount of real- time data vanes dynamically, extra overhead is imposed on the regular data even when the full real-time data allocation is not needed.

Another technique to implement simultaneous real-time and non-real-time data transmission is to interrupt regular data frames in a modem connection by non-standard "abort" tokens m order to introduce realtime data. Using the suspend/resume tokens of the ITU V 76 recommendation is such an approach. How ever, using "abort" tokens has the disadvantage of requiring special hardware to create and detect the abort tokens. Furthermore, overhead is increased by the use of the tokens and additional frame information.

As descnbed above, all the existing solutions to provide simultaneous real-time and non-real-time data communication suffer because they either require special hardware (and have increased complexity and/or expense) or negatively impact latency and overhead, or both It is therefore desirable to provide a low latency technique to communicate real-time and non-real-time data over a conventional modem connection with minimal impact on performance

Summary of the Invention A mechanism for multiplexing real-time data with non-real-time data across a communication link such as a modem connection is provided The mechanism may provide an efficient communication protocol for transmitting real-time data capable of being delivered at frequent intervals such as digitized voice, telephony signaling, or mouse or sprite positioning information across a communications link transferring non-real-time data The mechanism may extend the communication links existing packet protocol such as V 42/HDLC to provide low latency for the real-time data with a minimal impact on existing data transfer efficiency

Before each data frame is transmitted the transmitter determines if real-time data is expected for transmission when a real-time channel is open such as when a telephone is off hook If so, the frame is flagged as an escape sequence protocol frame and real-time data is inserted as follows A reserved bit value such as a DLCI (data link connection identifier) value of 33 within the header of the data frame may be used to indicate the frame may contain real-time data according to an escape sequence protocol Regular data may be transmitted within the frame until real-time data becomes available at which point a capsule of real-time data is inserted into the data stream introduced by an escape character, such as an ASCII "SUB" character (0x1 A) If the regular data contains a character equal in value to the escape character, the character is literalized by replacing it with a second type of escape sequence, such as "SUB 0x80" To avoid multiple occurrences of the escape character in the regular data causmg the transmitted data to double m size, pairs of the escape character may be replaced by another escape sequence, such as "SUB OxCO" Multiple sets of real time data may be transferred via logical "links" Each capsule may be structured such that its link may be determined by the receiver The lmk may indicated by including a link field m a header of the capsule A check may be performed on the accuracy of the capsule by including an error check code, such as cyclic redundancy check, within the capsule Depending upon the nature of the real-time data, the error check may be less rigorous than that performed for the regular data For example, a very occasional burst of noise may be acceptable m an audio application After inserting the real-time capsule, the transmitter resumes transmitting the regular data until further real-time data is present or the end of the frame is reached When real-time data is inactive, the transmitter may leave the reserved header bits with their default values to avoid any overhead to the regular data In some real-time data applications it is often necessary to transmit essentially empty data frames as timing place holders to indicate a synchronous absence of data as opposed to e g a lost or corrupted data frame In speech applications this would typically represent a period of silence (e g ITU-T standard G 729 B) To indicate such frames a special escape sequence or place holder escape sequence mav be used such as "SUB 0x00" As the sequence does not possess a CRC, this mechanism is only appropriate when misreception cannot cause significant errors, such as when spunous detection of silence is benign

When a capsule is received with an error, such as when the CRC check fails, the encompassmg data frame is also likely to be an error, and due to probable bit alignment failure subsequent capsules are likely to be corrupted To reduce the number of lost real-time capsules and to improve regular data performance, a special quick reject, or fast error recovery escape sequence such as "SUB 0x40", may be transmitted when an error is detected Upon receivmg a fast error recovery escape sequence, the transmitter may abort (HDLC terminate with error) transmission of the frame in error (unless it has already completed) and retransmit the frame Ordinary (V 42) processing may handle the retransmitted frame correctly (and more quickly than ordinary V 42 error recovery) and real-time data mav be restored quickly Together with real-time data (such as voice) it may be necessary to transmit small amounts of control data which must be delivered promptly and reliably (such as telephony signaling, e g hook flashes, dial tones, etc ) To enable this, a capsule may have a bit set in its header indicating that it contams a sequence of controls, small data sequences, demarcated by length fields, preceding the real-time data Controls have a small (e g. one bit) sequence number, which may be acknowledged by a sequence number in each capsule Until a set of controls have been acknowledged, they are retransmitted m each capsule sent This ensures prompt reliable delivery even in the presence of data errors

To ensure minimal latency in the transmission of the real-time data it is necessary to ensure that the realtime data is not significantly delayed by buffered regular data. This is simply achieved by minimizing buffers m the data path If minimizing buffers is not feasible the data stream should have data eked out to it based on the estimated speed of the communications link

A real-time data capsule is inserted into the data frame by the primary escape sequence The format of the real-time data capsule may begin with a header octet including a control acknow ledge sequence bit, a control mdicator bit, and a length field The control acknowledge sequence bit may be used for acknowledging correct receipt of control information The control indicator may indicate that control information is present m this capsule and the length field may be a six-bit value for mdicatmg the length of the capsule including CRC information A length value of zero may be reserved for special escape sequences If control information is included in the capsule, a control header octet may be provided including a control indicator bit, a control sequence bit and a length of control field The control indicator bit may indicate that further controls are present in the capsule The control sequence bit may be used to indicate that new control information is present so that the control sequence bit may only be significant on initial control information The length of control field may indicate the length of the control information included following the control header Following any control information real-time data, such as digitized voice data, is included in the capsule The capsule may conclude with a CRC octet.

A method for transmitting real-time data across a communications link transferring non-real-time data may include beginning transmitting a data frame comprising a header and a body of data A data stream withm the body of data may be transmitted, w here the data stream comprises non-real-time data. A first escape sequence may be inserted into the data stream The first or primary escape sequence indicates the beginning of a real-time data capsule in the data stream A real-time data capsule is inserted m the data stream following the pnmary escape sequence Non-real-time data may continue to be transferred after the real-time data capsule As real-time data becomes available, it may be inserted into the data stream as another real-time data capsule introduced by the first escape sequence Transmitting non-real-time data and inserting real-time data capsules introduced by the first escape sequence may be repeated until the end of the data frame is reached Thus, both real-time data and non-real-time data are multiplexed w ithm the same data frame A plurality of data frames may be transmitted Before each data frame is transmitted, the method mav determine if real-time data will be available for transmission during the next data frame. If real-time data will be available during the next data frame, the data frame may be flagged as containing real-time data. Determining if real-time data will be available may mclude checking whether or not a real-time data source is active, such as checking if a telephone device is off hook. Flagging the data frame as containing real-time data may include setting a value m the header of the data frame. Reserved bits in the header of the data frame may be used for flagging the data frame as possibly contammg realtime data. If no real-time data will be available during the data frame, the header reserved bits may be left with their default values.

The start of an escape sequence may be an eight-bit value (the "escape character"), such as the ASCII "SUB" character. The method may determine whether or not the non-real-time data contams a sequence or character equal in value to the escape character. If so, the data sequence equal in value to the pnmary escape sequence may be replaced with a second escape sequence. The second escape sequence may include the escape character followed by a special value, such as hex 80. The method may also determine if the non-real-time data contains a sequence of data equal in value to two consecutive escape characters If so, the sequence of data may be replaced with a third escape sequence. The third escape sequence may include the escape character followed by a different special value, such as hex CO

Another escape sequence, which may be referred to as a place holder escape sequence, may be inserted into the data stream to indicate an absence of real-time data. The place holder escape sequence may represent a penod of silence in an audio or voice application. The place holder escape sequence may include the escape character followed by a different special value, such as the hex value 00. The place holder escape sequence may be the only data transmitted to indicate absence of real-time data. For example, no CRC data may be included if spurious detection of silence is benign.

As mentioned above, the real-time data capsule may include a length field for indicating the length of the real-time data capsule and an error check field for checkmg the accuracy of the real-time data capsule The error check field may include a cyclic redundancy check (CRC) code. The length of the error check field may be adjusted according to the accuracy requirements of the real-time data application

The method may also include receiving a fast error recovery escape sequence sent from a device receiving a transmitted real-time data capsule. The fast error recover escape sequence may indicate that the realtime data capsule failed an error check when it was received. Upon receiving a fast error recovery escape sequence, the method may abort the current data frame that contained the erroneous real-time data capsule if the data frame has not yet completed transmission. The data frame may then be retransmitted. The fast error recovery escape sequence may include the escape character followed by a different special value, such as hex 40.

As mentioned above, the real-time data capsules may include control information. The control information may be retransmitted in subsequent real-time data capsules until receipt of the control information is acknowledged by the receiving device. The control information may include a field for indicating the sequence number of the control mformation The real-time data capsules may also mclude a header field for mdicatmg that control mformation is present in the real-time data capsule and a field for indicating the length of the control mformation. Both real-time data and control information may be transmitted in the same real-time data capsule. Control information may indicate telephony signaling including hook flashes or dial tones. The method mav also include selecting the size of a buffer for the non-real-time data to be transmitted such that the buffer size corresponds to the maximum acceptable real-time data latency for an application receiving the real-time data capsule, based on an estimated speed of the communication link Also, the amount of non-real-time data transmitted between real-time data capsules may be limited so that the latency between real- time data capsules does not exceed the maximum acceptable real-time data latency for an application receivmg the real-tune data capsules, based on an estimated speed of the communication link The communication lmk may be a modem connection and the real-time data may include voice or telephony data or mouse and or spnte positioning data

A method for receiving real-time data across a communication link transferring non-real-time data may include receiving a data frame having a header and a body of data as a data stream The data stream may be monitored for the escape character Upon detection of the escape character, the escape character and a portion of the data stream following the escape character may be interpreted as a pnmary escape sequence contammg a realtime data capsule A plurality of data frames may be received For each data frame received, it may be determined if real-time data is present in the current data frame This may done by checking a flag in a header of the data frame If no real-time data capsule is present in the current data frame, then the momtonng and removing may be avoided In other words, by checking the flag in the header, the method may dynamically determme whether or not to apply the escape sequence protocol

The data stream may also be monitored for a second escape sequence The second escape sequence may be replaced with non-real-time data equal m value to the escape character Similarly, a third escape sequence may be detected an replaced with non-real-time data equal in value to two consecutive escape character The data may also be monitored for a place holder escape sequence which when detected is interpreted as an absence of real-time data, such as a period of silence in an audio or voice application

The length of the portion of the data stream interpreted as a real-time data capsule may be determined from a length field in the capsule The accuracy of the capsule may be checked according to an error check field, such as a CRC, in the capsule The length of the error check field may be adjusted according to the accuracy requirements of the real-time data application

The receiving method may also include sending a fast error recovery escape sequence to the transmitting device if a received capsule fails the error check Also, for real-time data capsules including control mformation, correct receipt of the control information may be acknowledged by sending a real-time data capsule contammg an acknowledgement indication The receiving mechanism may determine if control information is present in a received real-time capsule according to a header field of the capsule Also, the length of the control information may be determined from control length header field m the capsule Both real-time data and real-time control information may be received in the same capsule

A modem may be provided having a transmitter configured for transmitting data across a communication lmk in data frames

ing a header and a body of data as a data stream The modem may also include a controller configured to provide real-time data and non-real-time data in the same data frame to the transmitter The controller may be configured to perform a transmit mechanism as descnbed abo\ e A modem may also have a receiver configured for receiving data across a communication link m data frames having a header and a body of data as a data stream The controller may be further configured to perform the receiving mechanism as descnbed above Also, a computer readable medium may be provided havmg program lnstrucnons The program instructions may be operable to transmit data across a communication lmk in data frames implementmg the transmitting and/or receiving mechanisms descnbed above. The computer readable medium may operate in conjunction with a modem in a computer to implement the afore described mechanisms. The present invention also contemplates a computer readable storage medium compnsmg program instructions that may be operable to implement the aforedescnbed methods and/or modem configurations. Such computer readable storage medium may include flash memory, ROM, EPROM, DRAM, magnetic storage such as hard drive or floppy disk, andOr CD-ROM, or any other readable medium for storing program instructions.

Brief Description of the Drawings

A better understanding of the present invention can be obtained when the following detailed descnption of the preferred embodiment is considered in conjunction with the following drawings, m which:

Fig. 1 is a block diagram of a communications system according to an embodiment of the present invention; Fig. 2 is a block diagram of a modem of Fig. 1 ,

Fig. 3 is a flow diagram illustrating a mechanism for transmission of real-time and regular data multiplexed in the same data frame;

Fig. 4 is a more detailed flow diagram illustrating a mechanism for transmission of real-time and regular data multiplexed in the same data frame; Fig. 5 is an illustration of a data frame with multiplexed real-tune and regular data;

Fig. 6 is a flow diagram illustrating a mechanism for handling the case when a regular data sequence is equal in value to one or more escape characters;

Fig. 7 is an illustration of data streams showing the replacement of regular data characters according to the mechanism of Fig. 6, Fig 8 is an illustration of a data streams showing how periods of absence of real-time data may be mdicated;

Fig. 9 is a flow diagram illustrating a fast error recovery mechanism,

Fig. 10 is a flow diagram illustrating a mechanism for reliable transmission of control information withm a real-time data capsule; Fig. 11 is a flow diagram illustrating receiving a data frame with real-time and non-real-time data multiplexed in the data frame;

Fig. 12 is a more detailed flow diagram illustrating receivmg a data frame w ith real-time and non-realtime data multiplexed in the data frame,

Fig. 13 is a flow diagram illustrating replacement of special escape sequences w ith corresponding regular data values;

Fig. 14 is a flow diagram illustrating acknowledging correct receipt of control mformation; and

Fig. 15 is an illustration of a possible capsule format introduced by an escape sequence

While the invention is susceptible to vanous modifications and alternative forms, specific embodiments are shown by way of example in the drawings and will herein be described in detail It should be understood however, that drawings and detailed description thereto are not intended to limit the mvention to the particular form disclosed. But on the contrary the invention is to cover all modifications, equivalents and alternative following withm the spint and scope of the present invention as defined by the appended claims.

Detailed Description of the Preferred Embodiment

Refernng now to Figure 1, a block diagram of a telecommunications system 10 compnsmg modems according to the prefened embodiment of the present invention is shown The term "modem" used herein is intended to refer to any of various types of communication devices, including analog modems, DSVD modems, ISDN terminal adapters, and ADSL devices, among others. The system 10 comprises a first modem 12, comprised within a first computer 17, m communication with a second modem 16, compnsed withm a second computer 19, via a communications path 14. Preferably, the communications path 14 comprises a first telephone line coupled to the first modem 12 and a second telephone line coupled to the second modem 16, wherein the two telephone lines are coupled together via and/or compnse part of the public switched telephone network (PSTN). In another embodiment, portions of the communications path compnse wireless communications means For example, the first modem 12 may be compnsed withm a notebook computer and the first modem 12 performs wireless communications with the PSTN via a wireless communications system.

Preferably, the first modem 12 is further coupled to a real-time data device 13, such as a telephone handset, which is used by the first user to speak with a second user. Preferably, the second modem 16 is coupled to another real-time data device 15, such as another telephone handset. Note that the real-time data devices may be any device for transmitting and/or receiving real-time data. Telephones and other real-time audio devices connected to the modem by a PBX or the PSTN by a telephone line are examples of real-time data devices. Alternatively, the real-time data device could be another computer or a subsystem of computers 17 and/or 19. Real-time data from a computer subsystem may include sprite or mouse positioning information. Preferably, the computers 17 and 19 may be any type of data access device, including a general purpose computer, a personal digital assistant (PDA), a network computer, or television or other viewing device configured as an Internet access device or information access device. The computer 17 is capable of controlling the first modem 12 to perform data transfers with the second computer 19. The modem 12 may be an mtemal modem or an external modem, i.e., may be comprised within or external to the first computer 17. Likewise, the second modem 16 may be comprised within or external to the second computer 19.

Also, the second computer 19 may function as a data source server for transferring data to or from the first computer 17. For example, if the second computer 19 is compnsed as a server within an ISP, the server 19 may be coupled to the Internet and transfer data between the first computer 1 and the Internet The second computer server 19 may enable the client computer 17 to "surf the net " In another example, the second computer server 19 may be compnsed within a remote office coupled to a PBX which enables the first user to enjoy a "virtual presence" withm the remote office even though the client resides at a remote location, such as on the road or at home. In this embodiment, the remote client is enabled to access PBX functions and access a local area network (LAN) withm the office as if present in the office. Preferably, each of the modems 12 and 16 are operable to perform simultaneous real-time and non-real tune data communications, such as transmitting voice data from real-time data device 13 and regular data (like a file) from first computer 17 The modems 12 and 16 may transmit data to each other upon the communications path 14 as descnbed hereinbelow Preferably, the data transmitted on the communications path 14 compnses frames of compressed speech data (or other real-time data) multiplexed with other regular digital data, such as Internet data, computer files, video data, digital audio data, or other types of data, where the real-time data and regular data are multiplexed in the same frame. Computers 17 and 19 may include computer readable storage media 11a and l ib which may include computer program instructions operable to implement or assist in implementing simultaneous real-time data and regular data transmissions as described hereinbelow. Modems 12 and 16 may be configured to perform simultaneous real-time data and regular data transmissions as described hereinbelow. The modems may be so configured either through hardware (e.g circuitry), software (e.g. computer program instructions), or a combination of both.

Refemng now to Figure 2, a block diagram of one embodiment of the modem 12 or 16 of Figure 1 is shown. The modem 12 comprises a data pump 20 coupled to the communications path 14 Data pumps are well known in the art of modem design The data pump 20 may be a Lucent Technologies M-1634 The data pump may perform the functions, among others, of modulating digital data to produce modulated signals for transmission on the communications path 14 to the second modem 16 and demodulating modulated signals received from the second modem 16 to produce digital data. Preferably, the data pump 20 compnses a synchronous senal interface for transferring data frames between a synchronous senal interface compnsed in a controller 24.

The controller 24 performs various control functions of the modem 12. As descnbed below, the controller 24 multiplexes/demultiplexes data simultaneously transmitted withm a frame, I e , multiplexed, speech and data withm the same frame transmitted to or received from another modem operating as descnbed below. When receivmg, the controller 24 may receive from the data pump 20 real-time data such as compressed speech data or voice encoded speech multiplexed in the same frame with regular data The real-time data may be inserted in the regular data as real-time data capsules In the example of voice data, the controller separates the voice encoded data capsules from the regular data in each frame and provides the capsules to a vocoder (not shown) coupled to the controller 24. Continuing with the example of voice data, the controller 24 may receive compressed speech data from a vocoder 28, encapsulate the compressed speech data and multiplex them with regular data in a data-frame, and provide the data frame to the data pump 20 In one embodiment, the controller 24 is operably coupled to the computer 17 by an expansion bus, such as an Industry Standard Architecture (ISA) or Peripheral Component Interconnect (PCI) bus, through bus interface circuitry The controller 24 receives data from and sends data to the computer for exchange with the user

To further illustrate one possible application of the present invention, the following is presented A user at the first modem 12, speaks into a handset (13), to converse with a second user, who is connected through real- tune device 15 (possibly another handset) A vocoder m the first modem 12 encodes, I e , compresses, the first user's speech The modem 12 encapsulates the speech data and multiplexes the compressed speech data with regular data in the same frame and transmits the speech and data frame across the communications path 14 to the second modem 16. Such multiplexed frames are repeatedly transfened until all data has been communicated. The second modem 16 receives the stream of frames and demultiplexes the speech and data frames in each frame. The compressed speech capsules are then provided to a vocoder in the second modem 16 which decompresses the compressed speech data to produce a speech signal, preferably an analog speech signal The speech signal is provided on the telephone line 18 to the device 15 Device 15 preferably compnses a speaker for transducing the analog speech signal into sound pressure waves which are audible to the second user The regular data is provided to the computer 19, which may provide the data to a data source such as a LAN or the Internet or store it for later use by the second user.

Similarly, real-time speech data may received by the vocoder in the second modem and compressed mto compressed real-time data capsules The compressed speech capsules are multiplexed with regular data m a frame and transmitted by the second modem 16 to the first modem 12. The first modem 12 receives the frames and demultiplexes the speech capsules from the regular data. The first modem 12 decompresses the received speech capsules to produce a speech signal. The speech signal may transduced into speech which the client hears on the handset 13 speaker and the regular data may be stored in computer 17 or sent on to a network. Thus, the hereindescnbed communication mechanism allows the simultaneous transfer of real-time data and non-real-time data on a single communication link. As will be seen from the following discussion, this mechanism provides improved latency. Furthermore, in some embodiments, the mechanism may be implemented usmg conventional modem hardware. Such embodiments may involve the use of a computer program as descnbed below. Furthermore, the communication mechanism descnbed herem does not require special telephone service such as ISDN.

The controller 24 comprises any processor device which is capable of executing a stored program of instructions or embedded controller device. Preferably, the controller 24 compnses a processor, such as a microprocessor core, and peripheral devices, such as the synchronous serial interface. In one embodiment, the controller 24 may be a Zilog Z80182 microcontroller. The stored program instructions which the controller 24 may execute may be comprised w ithm a computer readable medium 30, such as a read-only memory (ROM), programmable ROM (PROM), erasable PROM (EPROM), FLASH memory, dynamic random access memory (DRAM), static random access memory (SRAM), among others, or a combination thereof. The memory may be used to store programs instructions and data executed by the controller 24 to implement the hereindescnbed communication mechanism. The memory 30 may comprises buffers used to buffer data received from real-time data device 13 before being provided to the data pump 20

Vocoders are well known m the art of voice encoded speech Preferably, a vocoder that may be used in a voice data regular data embodiment may comprise an AT&T 1635 The vocoder may encode speech signals received from a telephone ( 13) and provides the compressed speech data to the controller 24 The vocoder may also receive compressed speech data from the controller 24 and decodes the compressed speech frames back to produce analog voice signals which are provided to the telephone line for reproduction to the user.

It is noted, however, that compressed speech data and the use of vocoders is just one example of a realtime data application that may be used with the present invention The present invention is not limited to any specific real-time data application Any real-time data may be multiplexed with regular data accordmg to the present invention

Turning now to Figure 3. a flow diagram is shown of the communication mechanism for multiplexing real-time data with non-real-time data across a communications link Figure 3 illustrates a method for transmitting real-time data and non-real-time data (regular data) within the same data frame. This method may extend a communication links existing packet protocol (such as V 42/HDLC) to provide low latency for the realtime data, with a minimal impact on existing data transfer efficiency Transmission of a data frame is begun as shown at 40 Regular data may be transmitted within the frame until real-time data becomes available, as shown at 42. As real-time data becomes available a capsule of real-time data is inserted into the data stream withm the frame The real-time data capsule is introduced by an escape character as indicated at 44 The escape sequence marks the beginning of the real-time data capsule withm the data stream If the end of the data frame has not yet been reached, this process is repeated as shown at 46 As real-time data becomes available, real-time data capsules marked by the escape character are inserted into the data stream with regular data being transmitted between real-time data capsules Once the end of the data frame is reached, the process may be repeated for a new data frame as shown at 46 Note that if real-time data is available at the beginning of a frame, the real-time data capsule introduced by the escape character may be immediately inserted in the frame before any regular data is transmitted In a buffered system, preparation of one data frame may occur concurrently with the transmission of another data frame. If the real-time data device supplying the real-time data is inactive, then normal regular data frames may be transmitted, such as V 42/HDLC data frames The real-tune data may include voice or telephony data or may mclude mouse or spnte positioning data

The escape character allows a capsule of real-time data to be distinguished from regular data withm the same data frame. Preferably, a value for the escape character is chosen such that the value occurs infrequently as regular data. In one embodiment the ASCII "SUB" character is chosen as the escape character The ASCII "SUB" character has a hex data value of 1 A This character may be infrequently used in ASCII applications Turning now to Figure 4. a more detailed embodiment for transmitting real-time data and regular data according to the present communications mechanism is illustrated Before each data frame is transmitted, the transmitter determines if real-time data is expected for transmission Real-time data may be expected for transmission when a real-time channel is open such as when a telephone is off hook Checking whether or not a real-time data source is active to determine whether or not real-time data is expected is illustrated at 50 If real- time data is not expected for the data frame then a regular data frame may be transmitted as shown at 52 In this case, the reserved header bits of the regular data frame may be left at their default values If real-time data is expected, the data frame may be flagged for the escape sequence protocol, as shown at 54 Flaggmg the data frame for escape sequence protocol indicates that the data frame may include at least one real-time data capsule The data frame may be flagged by setting a value m the header of the data frame A reserved bit value, such as a DLCI (data link connection identifier) value of hex 33, within the header of the data frame may be used to flag the data frame for the escape sequence protocol Regular data may then be transmitted m the data frame until real-tune data becomes available, as indicated at 56 After real-time data is available, an escape character is inserted in the data stream as shown at 58 A capsule of real-time data is then inserted into the data stream following the escape character Preferably, the length of the real-time data capsule is indicated within a header of the real-time data capsule. Alternatively, the real-time data capsule may be of a predetermined length. The real- tune data capsule may also mclude an error check code, such as a cyclic redundancy check (CRC) code. The escape character, header, real-time data and CRC may comprise the pnmary escape sequence. After insertion of a real-time data capsule, regular data may then be transmitted until another real-time data capsule is ready to be inserted, as shown at 62. At that time another pnmary escape sequence is inserted, as shown at 64, continuing the new real-time data capsule. This process may be repeated until the end of the frame as shown at 68.

Turning now to Figure 5, a simplified illustration of a data frame 70 is provided. The data frame 70 includes frame boundary/header information 72 A special sequence of bits may be used to indicate the beginning of a frame. The frame boundary/header information 70 also may include the flag bit to indicate that the escape sequence protocol is applied to this data frame. Regular data 74 may be transmitted between the end of the frame boundary. eader 72 until a real-time data capsule 78 is inserted, introduced by escape character 76 forming pnmary escape sequence, 77 Alternatively, pnmary escape sequence 77 may be immediately inserted in the frame after frame boundary/header 72 The data frame may alternate between regular data 74 and pnmary escape sequences 77 until the end of the frame. Turning now to Figure 6, a mechanism for dealing with a situation where regular data contammg a character equal in value to one or more escape characters is illustrated. As mentioned above, the escape character to introduce real-tune data capsules withm the data frame is preferably chosen such that the character will infrequently occur withm the regular data. However, if a value equal to the escape character does occur within the regular data, a mechanism is needed for distinguishing it from the escape character so that the following regular data is not mismterpreted as a primary escape sequence. The mechanism determmes if the non-real-time data contains a sequence of data equal m value to the escape character or to a pair of escape characters, as shown at 80. If the regular data includes a sequence equal in value to a smgle escape character, then that regular data sequence is replaced with a second type of escape sequence, as shown at 82. The second escape sequence may mclude to pnmary escape sequence followed by a different escape sequence. In one embodiment, the different escape sequence is the hex value 80. such that the second escape sequence is "SUB 80" or hex 1A80. If a regular data sequence equal to a pair of escape characters is present, the regular data sequence is replaced with a third type of escape sequence as shown at 86 The third escape sequence may include the escape character followed by a different escape sequence, such as hex CO, such that the third escape sequence may be "SUB CO" or hex 1AC0. The purpose of using a third type of escape sequence to replace regular data sequences equal to a parr of pnmary escape sequences is to prevent doubling in size of the data stream for strings of the pnmary escape sequence in the regular data. If the regular data does not include characters equal in value to the escape sequence then the regular data may be transmitted unmodified as indicated at 84.

Turning now to Figure 7, data streams are provided illustrating the replacement of regular data characters according to the mechanism of Figure 6. A regular data stream is shown at 90 The data stream 90 includes characters equal m value to the primary escape sequence hex 1A Note that while the value hex 1A is shown for the pnmary escape sequence (the ASCII SUB character), any value may be used as the escape character as long as the value is known to the transmitting and receiving devices. As shown in data stream 92, the regular data sequences equal to the primary escape sequences are replaced with the second or thud type of escape sequence before the data stream is transmitted. Single occurrences of the escape character are replaced with the second escape sequence hex 1AS0, and double occurrences of the escape character are replaced with the third escape sequence hex 1AC0 The recei ing de ice receives the data stream 94 contammg the substituted second and third escape sequences The receiv mg dev ice replaces the second escape sequence with a data value equal to the escape character hex 1A and replaces the third escape sequence with a data value equal to a pair of the escape character hex 1A1A, as shown m the data stream 96 Data stream 96 is then used as the received data stream

In some real-time data applications, it may be necessary to transmit essentially empty data frames or real-time data capsules as timing place holders to indicate a synchronous absence of real-time data as opposed to, e g , a lost or corrupted data frame Some real-time data applications may expect to receive real-time data at regular intervals Thus if no real-time data is present, it may be necessary to insert a place holder to indicate the lack of data while maintaining synchronization In speech applications this would typically represent a penod of silence (e g ITU-T standard G 729 B) To indicate such frames or capsules, a special place holder escape sequence may be used The place holder escape sequence may include the primary escape sequence followed by a different sequence, such as hex 00, so that the place holder escape sequence may be hex 1 A00 Of course, any sequence may be chosen for this function Preferably, no other information is included with the place holder escape sequence Since the place holder escape sequence does not possess a CRC, this mechanism may only be appropriate when misreception can not cause significant enors For example, use of the place holder escape sequence with no CRC may only be appropriate when spurious detection of silence is benign

Figure 8 illustrates a data stream 102 with synchronous penods of silence mdicated at 104 The data stream may include regular data 74 Data stream 102 may be withm a data frame flagged as an escape sequence protocol data frame Place holder escape sequences 106 are penodically inserted withm the data stream as indicated in data stream 108 to synchronously indicate absences of real-tune data Also, if no regular data is available to be transmitted, an escape sequence protocol data frame may be transmitted to indicate penods of silence or absence of real-time data where the frame body contains only a place holder escape sequence The place holder escape sequence provides an efficient mechanism to indicate absences of real-time data A mechanism is also provided for fast enor recovery when transmitting real-time data capsules When a capsule is received with an error, e g bad CRC, the encompassing data frame is most likely also in enor Due to probable bit alignment failure, subsequent capsules are also likely to be corrupted To reduce the number of lost real-time data capsules and improve regular data performance, a special fast error recover escape sequence may be transmitted when an error is detected by the receiving device The fast error recovery escape sequence may include the escape character followed by a different sequence, such as hex 40, so that the fast error recovery escape sequence may be hex 1 A40 Upon receiving a fast error recovery escape sequence, the transmitting device aborts (HDLC terminate with error) transmission of the frame in error (unless it has already completed), and retransmits the frame Figure 9 illustrates this mechanism for the transmitter When the transmitter receives a fast error recovery escape sequence as shown at 1 10, the frame mav be aborted as shown at 112 and then retransmitted as shown at 114 Ordmary (V 42) processing may be used to retransmit the frame This retransmission of frame upon receiving a fast error recovery escape sequence mav be faster than ordmary V 42 error recovery and quickly restores real-time data transmission

Together with real-time data (such as voice) it may be necessarv to transmit small amounts of control data which must be deliv ered promptly and rehablv (such as telephonv signaling, e g , hook flashes, dial tones, etc ) To enable reliable transmission ot control data, a real-time data capsule mav hav e a bit set in its header mdicatmg that it contains a sequence of control data The control data may be a small data sequence preceding the real-time data m the real-time data capsule A length field may be used in the capsule to indicate the length of the control information To ensure reliable transmission of the control information, the control informanon may be repeated or retransmitted in each capsule until receipt of the control information is acknowledged by a device receiving the control information A control sequence number may be included m the control information for indicating whether the control information is new or retransmitted control information Preferably, the control sequence number is a one bit field that is simply toggled when new control information is transmitted The realtime data capsule header may include a control acknowledge field, preferably a one bit field, for use by the receiving device to acknowledge receipt of control information This mechanism is illustrated in Figure 10 Control information may be included in a real-time data capsule, as indicated at 120 The control informanon is retransmitted in the next real-time data capsule until acknowledgement of receipt is received, as indicated at 122 If new control information is available it may then be transmitted in the next real-time data capsule after the previous control information has been acknowledged, as indicated at 124 If no new control information is available then transmission of real-time data capsules proceeds as descnbed above

To ensure minimal latency in the transmission of a real-time data it is necessary to ensure that it is not delayed by buffered regular data This may be achieved simply by minimizing buffers in the data path When minimizing buffers in the data path is not feasible, the data stream may have data eked out to it based on the estimated speed of the communication lmk Thus, the mechanism may select the size of a buffer for the non-real- time data to be transmitted such that the buffer size corresponds to the maximum acceptable real-time data latency for an application receivmg the real-time data capsule based on an estimated speed of the communication lmk. Alternatively, the mechanism may limit the amount of non-real-time data transmitted between real-tune data capsules so that the latency between real-time data capsules does not exceed the maximum acceptable real-time data latency for an application receiving the real-time data capsules based on an estimated speed of the communication link

The afore described mechanisms provide a communications protocol for efficiently transmitting both real-time and non-real-time data across a communication link in the same data frame The communication lmk may include a modem connection and the real-time data may include voice or telephony data or mouse or sprite positioning data Turning now to Figure 1 1 , the communication mechanism from the perspective of the receiving device is illustrated A receiving device receives a data frame, as indicated at 130 The data of the data frame is monitored for the escape character as indicated at 132 If no escape character is found, the data is interpreted as regular or non-real-time data as indicated 134 If an escape character is found then a portion of the data stream following the escape character is interpreted as a real-time data capsule, as indicated at 136 This process is repeated for all the data withm the data frame and repeated for each data frame received, as indicated at 138

Turning now to Figure 12, a more detailed flow diagram of a receiving mechanism is illustrated The receiver begins receiving a data frame, as indicated at 140 The frame is checked to see if it is flagged for the escape sequence protocol, as indicated at 142 If the frame is not flagged for the escape sequence protocol, then the frame is interpreted as a regular data frame, as indicated at 146 If the frame is flagged for the escape sequence protocol, then the data within the data frame is monitored lor the primary escape sequence, as indicated at 148 Data before an escape character is found is interpreted as regular data, as indicated at 150 and 152. After a escape character is found, it is removed from the data stream, as indicated at 150 and 154, and a portion of the data stream following the location of the escape sequence is interpreted as a real-time data capsule as indicated at 156. The receiver may determine the length of the real-time data capsule by a length field within the capsule. This length field may be located in a header portion of the capsule The capsule may also contain an error check field such as a CRC field so that the receiving device may check the real-time data capsule for errors. If the end of the frame has not yet been reached, the afore descnbed process is repeated until the end of the frame, as indicated at 158 In this manner, a receiver is able to distinguish regular data from real-time data withm the data stream of a data frame.

Turning now to figure 13, a flow diagram is provided illustrating a mechanism for replacing the second and third types of escape sequences with the corresponding regular data values. As discussed above with regard to Figures 6 and 7, if the regular data contams data values equal to one or more escape sequence characters, then the regular data characters must be replaced with a different escape sequence so that the regular data is not misinterpreted as a real-time data capsule A second type of escape sequence is used to indicate a regular data value conesponding to the value of the escape character, and a third type of escape sequence is used to indicate a regular data value equal to a pair of the escape characters. The receiving mechanism monitors the data stream for the second and third type of escape sequences, as mdicated at 160 If the second type of escape sequence is detected it is replaced with a regular data value equal to the primary escape sequence, as indicated at 162. If the third type of escape sequence is detected it is replaced with a regular data value equal to a pair of the pnmary escape sequences, as mdicated at 164. The data stream may be continuously checked for the second or third type of escape sequences as the data stream is received.

The receivmg mechanism may also include momtonng the data stream of a data frame for a place holder escape sequence and interpreting a place holder escape sequence as an absence of real-time data. Referring back to Figure 8, penods of silence or other absences of other real-time data may have been marked in the data stream, or m the data frame by the transmitting device to mamtain a synchronous indication of real-tune data. The receiving device may note these absences of real-time data by monitoring the data stream for the place holder escape sequence. The receiving device may then notify the application for receiving the real-time data of the absence of real-time data. The receiving mechanism may also include checking the accuracy of a real-time data capsule received accordmg to an error check field in the real-time data capsule. The error check field may include a cyclic redundancy check code. If the CRC indicates an error m the real-time data capsule, then it is likely that the entire data frame is an enor. In order to quickly recover from such an enor, the receiving device may mclude in its next transmission to the device that transmitted enoneous real-time data capsule, a fast error recovery escape sequence The fast enor recovery escape sequence may include the pnmary escape sequence followed by a different escape sequence, such as the value hex 40, so that the fast enor recovery escape sequence may be hex 1A40. When the device that transmitted the enoneous real-time data capsule receives the fast enor recover escape sequence, it will retransmit the entire data frame that mcluded the enoneous real-time data capsule. In this manner, a fast recovery from enoneous data transfers is made As descnbed above, a real-time data capsule may mclude control information Turning now to Figure 14, a mechanism is illustrated for acknowledging the conect receipt of control information It may be important to ensure that control information is conectly received, whereas enors in the real-time data may be tolerated. Real-time data capsules may be marked, such as in a header field, to indicate whether or not the real-time data capsule includes control information The receiving device determmes if a real-time data capsule includes control information, as indicated at 170 If so, the receiving mechanism checks to see if the control mformation has been receiv ed conectly, such as by checking the CRC field of the real-time data capsule, as indicated at 172. If the control information has not been received conectly then the control information may be ignored as indicated at 174 If the control information has been received conectly the receiving device will acknowledge the control information, as indicated at 176 The receiving device may acknowledge the control information by transmitting a real-tune data capsule to the device that transmitted the control information, wherem a header field of the realtime data capsule has a control acknowledgement sequence field set appropriately As described above in regard to Figure 10, the transmitting device will continue to transmit the control information until this acknowledgement is received. In this manner, reliable transmission and reception of control information may be achieved. Turning now to Figure 15. a format for the real-time data capsules is illustrated. This format is merely an example of one embodiment Any format may be utilized in accordance with the above disclosed communication mechanism. The exact formatting of bits is not cntical to the mechanism. The example of Figure 15 shows a real-time data capsule 78 introduced by a primary escape sequence 76 The real-time data capsule may begin with a header 182. The header may be of an octet size, as shown at 182. The header may include a control acknowledgement field, a control indicator field, and a length field. The control acknowledgment field is used by a receiving device to indicate conect reception of control information in a received real-time data capsule. The control indication field is used by a transmitting device to indicate that the real-time data capsule mcludes control information The length field may be used to indicate the length of the real-time data capsule. Alternatively, the length of real-time data capsules may be predetermined between the transmitting and receivmg devices If control mformation is present in the real-time data capsule, a control header 184 may be mcluded The control header may include an additional control indicator field, a control sequence field, and a length field, as mdicated at 184A. This control indicator field may be used to indicate if further control information is present. The control sequence field may be used by a transmitting device to indicate that new control information is present as opposed to retransmitted control mformation. The length field m the control header may be used to indicate the length of the control information In a prefened embodiment, the control acknowledgement, control mdicators, and control sequence fields of headers 182A and 184A, may be one-bit values and the length fields may be six-bit values Following control header 184 may be control information 186 Control information may include controls such as telephony signaling or hook flashes, dial tones, etc.

Real-time data 188 may be included withm the real-time data capsule The real-time data may conespond to digitized v oice data or other audio data or mouse or spnte positioning data The real-time data capsule may conclude with an enor check field 190 A cyclic redundancy check code may be used as the error check. Depending upon the nature of the real-time data the enor check may be less rigorous than that performed for regular data. For example, a very occasional burst of noise may be acceptable in an audio application Therefore the enor code or CRC for the real-time data capsule may be a single eight-bit, or one octet, code A 16-bit CRC may used if the real-time data application requires a more πgorous enor check Therefore, the afore descnbed mechanism may mclude adjusting the length of the enor check field accordmg to the accuracy requirements of the real-time data application

As mdicated in Figure 15. the real-time data capsule may include both control information and real-time data Alternatively, real-time data capsules may include only control mformation or only real-tune data. As descnbed above, the real-time data capsules are introduced by an escape sequence 76 which allows them to be distmguished withm a data frame from regular or non-real-time data This may provide an efficient communication mechanism that does not require the additional overhead of an entire data frame for distinguishing between regular and real-time data Also, the latency between real-time data may be closely controlled according to the present mechanism This may be accomplished by limiting the size of regular data buffers or by controlling the rate of regular data provided for transmission

Therefore, the hereindescnbed communication mechanisms provides a system and method for low latency multiplexing of real-time and regular data in a data frame The mechanisms may be applied to applications such as transmitting telephony audio and control information between modems The mechanisms descnbed may be applied as an extension to standards such as the V 42 standard

Although the system and method hereindescnbed have been described m connection with the preferred embodiment, it is not mtended to be limited to the specific form set forth herein, but on the contrary, it is intended to cover such alternatives, modifications, and equivalents, as can be reasonably mcluded withm the spint and scope of the mvention as defined by the appended claims.

Claims

1. A method for transmitting real-tune data across a communication link transferring non-real-time data, compπsmg. begin transmitting a data frame comprising a header and a body of data, transmitting a data stream withm said body of data, said data stream comprising non-real-time data. inserting a first escape sequence into the data stream, wherein said first escape sequence indicates the beginning of a real-time data capsule in the data stream; and inserting the real-time data capsule in the data stream following said first escape sequence

2. The method as recited in claim 1 , further compnsmg contmuing to transmit non-real-time data after said inserting the real-time data capsule; as real-tune data becomes available, inserting into the data stream another said first escape sequence followed by another real-time data capsule; and repeating said continuing to transmit non-real-time data and said inserting another one of said first escape sequence followed by another real-time data capsule until the end of the data frame is reached.

3. The method as recited in claim 1 or 2, further compnsmg' transmitting a plurality of data frames; before each data frame is transmitted, determining if real-time data will be available for transmission dunng the next data frame; and if real-time data will be available during the next data frame, flagging the data frame as contammg real time data.

4. The method as recited in claims 3, wherein said determmmg compnses checkmg if a telephone device is off-hook, wherein said telephone device sources the real-time data

5. The method as recited in claim 3 or 4, wherem said flagging comprises setting a value in the header of the data frame wherein reserved bits in the header of the data frame are used for said setting a value, and wherem the method further comprises transmitting the reserved bits with their default values if no real-time data will be available during the next data frame.

6. The method as recited in any of claims 1-5, further comprising determining if the non-real-time data contains a sequence of data equal in value to said first escape sequence; and if the non-real-time data contams a sequence of data equal in value to said first escape sequence, replacing the sequence of data equal in value to said first escape sequence with a second escape sequence.

7 The method as recited in claim 6, further compπsmg determining if the non-real-time data contains a sequence of data equal in value to two consecutive said first escape sequences; and if the non-real-time data contains a sequence of data equal in value to two consecutive said first escape sequences, replacing the sequence of data equal in value to two consecutive said first escape sequence with a third escape sequence

8 The method as recited in any of claims 1-7, further compnsmg inserting a place-holder escape sequence into the data stream to indicate an absence of real-time data

9 The method as recited in claim 8, wherein no other data except said different escape sequence is inserted mto the data stream to indicate said absence of real-time data.

10 The method as recited in any of claims 1-9, further compnsmg: receiving a fast enor recovery escape sequence sent from a device receiving said real-time capsule mdicatmg that the real-time data capsule failed an enor check; aborting the data frame that contamed the enoneous real-time data capsule if the data frame has not yet completed transmission; and re-transmitting the data frame that contamed the erroneous real-tune data capsule

11. The method as recited m any of claims 1-10, wherem said real-time data capsule includes control mformation, the method further comprising re-transmitting said control information in subsequent real-time data capsules until receipt of the control information is acknowledged by a device receiving the control information.

12. The method as recited in claim 1 1 , wherem said control information includes a field for indicating whether the control information is new control information or re-transmitted control information

13. The method as recited in claim 1 1 or 12, further comprising transmitting both real-time data and said control mformation in the same real-time data capsule.

14. The method as recited in any of claims 1-13, further compnsmg selecting the size of a buffer for the non- real-time data to be transmitted such that the buffer size conesponds to the maximum acceptable real-time data latency for an application receiving the real-time data capsule based on an estimated speed on the communication link.

15. The method as recited m any of claims 1-13, further compnsmg limiting the amount of non-real-time data transmitted between real-time data capsules so that the latency between real-time data capsules does not exceed the maximum acceptable real-time data latency for an application receiving the real-time data capsules based on an estimated speed on the communication link

16 A method for receiving real-time data across a communication link transfemng non-real-time data, compnsmg: receiving a data frame compnsmg a header and a body of data as a data stream; monitoring the data stream for a first escape sequence; and upon detection of said first escape sequence, removing said first escape sequence from said data stream and interpreting a portion of the data stream following said first escape sequence as a real-tune data capsule

17 The method as recited in claim 16, further comprising: receiving a plurality of data frames; for each data frame received, determining if a real-time data capsule is present in the cunent data frame; and wherein said monitoring and said removing are not performed if said determining mdicates that no realtime data capsule is present in the cunent data frame.

18. The method as recited in claims 16 or 17, further comprising' monitoring the data stream for a second escape sequence; and replacing said second escape sequence with non-real-time data equal in value to said first escape sequence.

19. The method as recited in any of claims 6, 7, or 18, wherein said second escape sequence compnses said first escape sequence followed by a different sequence.

20. The method as recited in claim 18, further compnsmg: momtonng the data stream for a third escape sequence; and replacing said third escape sequence with non-real-time data equal in value to two consecutive said first escape sequences

21. The method as recited in claim 7 or 20, wherein said third escape sequence comprises said first escape sequence followed by a different sequence.

22. The method as recited in claim 1, further compnsmg: monitoring the data stream for a place-holder escape sequence: and interpreting said place-holder escape sequence as an absence of real-time data

23. The method as recited m claim 8 or 22, wherein said place-holder escape sequence represents a period of silence m an audio or v oice application

24. The method as recited in claim 8 or 22. wherem said place-holder escape sequence compnses said first escape sequence followed by a different sequence

25 The method as recited in claim 56, further comprising: checking the accuracy of the real-time data capsule according to an enor check field in the real-time data capsule: and sending a fast enor recovery escape sequence sent to a device transmitting said real-time capsule if the real-time data capsule failed said checking

26. The method as recited in claim 10 or 25, wherein said fast enor recovery escape sequence compπses said first escape sequence followed by a different sequence.

27 The method as recited in claim 16, wherein said real-time data capsule includes control information, the method further compnsmg acknowledging receipt of said control information to a device that transmitted said control information if said control information is conectly received

28. The method as recited in claim 27, further comprising receiving both real-time data and said control mformation in the same real-time data capsule.

29. The method as recited in any of claims 1 1-13, 27 or 28, wherein said control information indicates telephony signaling including hook flashes or dial tones.

30. The method as recited in any of claims 1-29, wherein said first escape sequence comprises the ASCII

"SUB" character.

31. The method as recited in any of claims 1-30, wherem the communication link comprises a modem connection.

32. The method as recited in any of claims 1-31, wherem the real-time data includes voice or telephony data.

33. The method as recited in any of claims 1-31, wherein the real-time data includes mouse or sprite positioning data.

34. A modem, compnsmg: a transmitter configured for transmitting data across a communication link in data frames compnsmg a header and a body of data as a data stream; and a controller configured to provide real-time data and non-real-time data in the same data frame to said transmitter, wherein said controller is further configured to: insert a first escape sequence into the data stream, wherem said first escape sequence indicates the beginning of a real-time data capsule in the data stream; and insert the real-time data capsule in the data stream following said first escape sequence

35. The modem as recited in claim 34. wherein said controller is further configured to: contmue to provide non-real-time data after inserting the real-time data capsule; as real-time data becomes available, insert into the data stream another said first escape sequence followed by another real-time data capsule; and continue to provide non-real-time data and insert another said first escape sequence followed by another real-time data capsule until the end of the data frame is reached.

36. The modem as recited in claim 34 or 35, wherein said controller is further configured to. provide a plurality of data frames to said transmitter; before each data frame is provided, determine if real-time data will be available for transmission durmg the next data frame; and if real-tune data will be available during the next data frame, flag the data frame as contammg real time data.

37. The modem as recited in any of claims 34-36, wherein said controller is further configured to: determine if the non-real-time data contains a sequence of data equal in value to said first escape sequence; and if the non-real-time data contains a sequence of data equal in value to said first escape sequence, replace the sequence of data equal in value to said first escape sequence with a second escape sequence.

38. The modem as recited in claim 37, wherein said controller is further configured to determine if the non- real-time data contains a sequence of data equal in value to two consecutive said first escape sequences; and if the non-real-time data contains a sequence of data equal in value to two consecutive said first escape sequences, replace the sequence of data equal in value to two consecutive said first escape sequence with a third escape sequence.

39. The modem as recited in any of claims 34-38, wherein said controller is further configured to insert a place-holder escape sequence into the data stream to indicate an absence of real-time data.

40. The modem as recited in any of claims 34-39, wherein said controller is further configured to- receive a fast error recovery escape sequence sent from a device receiving said real-time capsule indicating that the real-time data capsule failed an enor check, abort the data frame that contamed the enoneous real-time data capsule if the data frame has not yet completed transmission; and re-send the data frame that contained the enoneous real-tune data capsule

41 The modem as recited in any of claims 34-40, wherein said real-time data capsule includes control information and wherein said controller is further configured to re-send said control information in subsequent real-time data capsules until receipt of the control information is acknowledged by a device receiving the control information

42 The modem as recited m any of claims 34-41, wherein said controller is further configured to provide both real-time data and real-time control information m the same real-time data capsule

43. The modem as recited in any of claims 34-42, wherein said controller is further configured to select the size of a buffer for the non-real-time data to be transmitted such that the buffer size conesponds to the maximum acceptable real-time data latency for an application receivmg the real-time data capsule based on an estimated speed on the communication link

44 The modem as recited in any of claims 34-42, wherein said controller is further configured to limit the amount of non-real-time data provided between real-tune data capsules so that the latency between real-time data capsules does not exceed the maximum acceptable real-time data latency for an application receiving the real- tune data capsules based on an estimated speed on the communication lmk.

45. A modem, compnsmg: a receiver configured for receiving data across a communication link m data frames compnsmg a header and a body of data as a data stream, and a controller configured to interpret real-time data and non-real-time data in the same data frame from said transmitter, wherein said controller is further configured to monitor the data stream for a first escape sequence, and upon detection of said first escape sequence, remove said first escape sequence from said data stream and interpret a portion of the data stream following said first escape sequence as a real-time data capsule

46 The modem as recited in claim 45, wherein said controller is further configured to receive a plurality of data frames, for each data frame received, determine if a real-time data capsule is present m the cunent data frame, and wherein said controller does not monitor for said first escape sequence if said controller determines that no real-time data capsule is present m the cunent data frame

47 The modem as recited in claim 45 or 46, wherein said controller is further configured to monitor the data stream for a second escape sequence, and replace said second escape sequence vv ith non-real-time data equal in v alue to said first escape sequence

48 The modem as recited in claim 47 herein said controller is further configured to monitor the data stream for a third escape sequence, and replace said third escape sequence with non-real-time data equal in value to two consecutive said first escape sequences

49 The modem as recited in any of claims 45-48, wherein said controller is further configured to monitor the data stream for a place-holder escape sequence, and interpret said place-holder escape sequence as an absence of real-time data

50 The modem as recited in any of claims 45-49, wherem said controller is further configured to check the accuracy of the real-time data capsule according to an enor check field in the real-time data capsule, and wherem said controller is further configured to send a fast enor recovery escape sequence to a device that transmitted said real-time capsule if the real-time data capsule failed said enor check

51 The modem as recited in any of claims 45-50, wherem said real-time data capsule includes control information, and wherein said controller is further configured to acknowledge receipt of said control information to a dev ice that transmitted said control information if said control information is conectly received

52 The modem as recited in claim 51 , wherem said controller is further configured to acknowledge receipt of said control information by providing a real-time data capsule containing an acknowledgement indication

53 The modem as recited in any of claims 45-52, wherem said controller is further configured to receive both real-time data and control information in the same real-time data capsule