JP2005045741A - Device, method and system for voice communication - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a device, a method and a system for voice communication which are capable of placing importance on any one of responsiveness and sound quality as necessary, when performing voice communication via the Internet. <P>SOLUTION: A VoIP client performs speech communication by transmitting/receiving an RTP packet storing transmission data to/from another VoIP client via the Internet. The client has a fluctuation absorbing buffer BF1 for absorbing fluctuations due to transmission, and a PCM buffer BF 2 for buffering uncompressed data before transmission. The capacity of the buffer BF1 is automatically adjusted in response to the transmission rate of a packet, and the capacity of the PCM buffer BF2 is variably set by a user operation. The user decreases the capacity of the buffer BF2 when placing importance on the responsiveness with low delay, and increases the capacity when wanting to place importance on the sound quality because the BGM is added, thereby enabling a prolonged time of requesting retransmission of missed packets, and maintaining the data quality. <P>COPYRIGHT: (C)2005,JPO&NCIPI

Description

  The present invention relates to a call device, a call method, and a call system that perform a so-called Internet telephone using, for example, VoIP (Voice over Internet Protocol), and is particularly suitable for exchanging real-time acoustic data composed of high-quality voice and sound. TECHNICAL FIELD The present invention relates to a simple call device, a call method, and a call system.

  VoIP is a technology that enables voice communication via an IP network by encapsulating voice in IP packets. In order to make a call by VoIP, it is necessary to exchange a series of information such as acquisition of information on the other party to be called, calling of the other party to be called, and response. For these purposes, SIP (Session Initiation Protocol) etc. A call control protocol is used.

  There are an increasing number of systems that transmit real-time data such as real-time audio data such as real-time moving image data and audio data using a communication network such as the Internet including such VoIP. In public line networks such as the Internet, since a plurality of users supply network bandwidth, a congestion control method, that is, a congestion avoidance method and a sedation method at the time of occurrence of congestion is a major issue. Therefore, with a change in the number of communication modes in which real-time property is important, congestion control techniques in real-time data communication have become important (see Patent Document 1 below).

  By the way, conventionally, in real-time voice communication using VoIP, the main information of human voice is included in the frequency band near 4 to 5 KHz, so the number of channels is 1 and the sampling frequency is 8 KHz. Although it is usual to set the frequency to ˜16 KHz, it is difficult to transmit background noise and atmosphere in such a narrow band.

  If the number of channels is set to 2 or more and the sampling frequency is raised to 44.1 KHz, which is the same level as CDDA (Compact Disk Digital Audio), background noise and atmosphere can be transmitted. In addition, existing music content can be used for voice communication. It is also possible to add a diverted high-quality BGM function or the like.

  Here, when the number of channels is set to 2 or more, the sampling frequency is raised to 44.1 KHz, which is the same level as CDDA, and uncompressed 16-bit Linear PCM (Phase Code Modulation) data is transmitted, The transmission bit rate becomes 1411.2 Kbps or more, and it is difficult to use it in an actual Internet environment. Therefore, it is necessary to use a high-efficiency encoding method at present, but with the recent improvement in CPU performance, it has become possible to adopt a high-efficiency encoding method even in real-time voice communication.

  There are several high-efficiency encoding methods. First, frequency decomposition is performed, the signal is divided into a plurality of subbands, and each block is encoded using the psychoacoustic characteristics. Most of them adaptively change and entropy code a predetermined frequency component with a minimum number of bits. With this high-efficiency encoding, the bit rate becomes variable according to the frequency component to be encoded.

  When such high-quality real-time acoustic data is transmitted / received via the Internet, the quality cannot be maintained if there are missing packets such as errors or lost packets in the received data packets. Therefore, such a lost packet is normally processed by sending a packet retransmission request from the receiving side to the transmitting side and having it transmitted again. At that time, a round trip propagation delay RTT (Round Trip Time) is measured, and based on this RTT, it is determined whether or not a packet requested for retransmission by the receiving side can be received by a scheduled time for reproduction processing on the receiving side. (Patent Document 2 below).

By the way, normally, in real-time voice communication, network fluctuation is caused by transmission of two packets P (i) and P (j) from the following formula described in RFC (Request for Comments) 1889. The difference D between arrival times at the time and at the time of reception is obtained, and thereby the jitter J can be calculated.
D (i, j) = (Rj−Ri) − (Sj−Si) = (Rj−Sj) − (Ri−Si)
J = J + (| D (i-1, i) | -J) / 16
As a result, calculation is performed in units of milliseconds and microseconds, and the capacity of the fluctuation absorbing buffer is automatically adjusted so that transmission fluctuation can be absorbed even if it slightly changes.

Japanese Patent Application Laid-Open No. 2001-3200430 JP 2003-169040 A

  However, with such a buffer capacity that is automatically adjusted by this method, there is a possibility that the sound may be cut off when a packet is largely dropped at a specific period or when the arrival interval fluctuates suddenly. In particular, when performing real-time voice communication for exchanging high-quality real-time acoustic data obtained by synthesizing voice data and additional data such as BGM, as described above, the sound quality deteriorates if there are missing packets. There is a limit to the time for which retransmission can be requested, and quality may not be maintained.

  On the other hand, for example, when exchanging real-time acoustic data of only voice, the amount of information is small and it is not always necessary to request retransmission, so the capacity of the fluctuation absorbing buffer may be relatively small. Thus, conventionally, it has been difficult to satisfy a user who desires low delay and a user who faces high sound quality at the same time.

  The present invention has been proposed in view of such a conventional situation, and when making a call via the Internet, the call device and the call that can cope with either responsiveness or sound quality as necessary. It is an object to provide a method and a call system.

  In order to achieve the above-described object, a communication device according to the present invention includes a compression encoding unit that compresses and encodes real-time acoustic data including voice in a communication device that transmits and receives real-time acoustic data via the Internet. A data packet generating means for generating a data packet storing data compressed and encoded by the compression encoding means, and a control packet generating means for generating a control packet storing at least management information for managing transmission / reception of the data packet Transmitting means for transmitting the data packet and the control packet to one or more other call devices via the Internet; and receiving means for receiving the data packet and control packet from the one or more other call devices Decoding / decompressing the compressed / encoded data stored in the received data packet And having a stage, a buffer for buffering the data the decoded stretching, and control means for controlling on the basis of the capacity of the buffer to the user's instructions.

  In the present invention, the user can determine the capacity of the buffer for buffering the decoded and decompressed data, and the buffer capacity is increased in order to maintain the sound quality when transmitting and receiving high sound quality data with a large amount of transmission information. However, in a normal call such as a voice-only call, it is possible to receive data that meets the user's needs, such as reducing the buffer for the purpose of low delay.

  In addition, the control means can store at least buffer information indicating the capacity of the buffer in the control packet, and is determined by a user using the call device with respect to another call device as a call partner. The size of can be notified.

  Furthermore, the control means can control the transmission rate of the data packet based on the buffer information stored in the control packet from the other call device, and can match the buffer capacity of the other call device as the call partner. The transmission rate can be made variable by changing the compression coding rate of the real-time acoustic data to be transmitted.

  Furthermore, it has a fluctuation absorbing buffer for buffering the received data packet, and the capacity of the fluctuation absorbing buffer can be automatically adjusted based on the transmission rate of the received data packet. A buffer with a minimum capacity can be secured according to the transmission rate for a buffer with a variable capacity. May be.

  Further, the control means may measure the transmission rate of the data packet from the other call device and notify the user, and the user determines whether or not to increase the buffer capacity in order to improve sound quality. You may determine based on this transmission rate.

  Further, the control means can generate retransmission request instruction information for instructing a retransmission request for a missing data packet generated according to the capacity of the buffer and store the retransmission request instruction information in the control packet. If the variable buffer is made larger, the time required for retransmission can be increased, and high-quality data can be maintained.

  The call method according to the present invention is a call method for transmitting and receiving real-time acoustic data between two or more call devices via the Internet, and a compression encoding step for compressing and encoding real-time acoustic data including speech; A data packet generating step for generating a data packet storing the data encoded by the compression encoding step, and a control packet generating step for generating a control packet storing at least management information for managing transmission / reception of the data packet A transmission step of transmitting the data packet and the control packet to one or more other communication devices via the Internet, and a reception step of receiving a data packet and a control packet from the one or more other communication devices. A decoding / decompressing step for decoding / decompressing the compressed and encoded data stored in the received data packet; Characterized by a control step of controlling, based the capacity of the buffer for buffering the decoded decompressed data to the user's instructions.

  The call system according to the present invention is a call system in which two or more call devices transmit and receive real-time acoustic data via the Internet, and each of the call devices compresses and encodes real-time acoustic data including voice. Generating means, data packet generating means for generating data packets storing data encoded by the compression encoding means, and control for generating control packets storing at least management information for managing transmission / reception of the data packets A packet generating means; a transmitting means for transmitting the data packet and the control packet to one or more other communication devices via the Internet; and a data packet and a control packet from the one or more other communication devices are received. Receiving means, and decoding and decompressing the compressed encoded data stored in the received data packet. Decoding / decompressing means, a buffer for buffering the decoded / decompressed data, and control means for controlling the capacity of the buffer based on a user's instruction. The control means stores at least buffer information indicating the capacity of the buffer in the control packet, and the control means of the other call device is based on the buffer information stored in the control packet from the one call device. The transmission rate of the data packet transmitted to the telephone apparatus is controlled.

  In the present invention, the capacity of a buffer for buffering uncompressed data that has been decoded and expanded can be determined in accordance with a user operation, and the buffer capacity determined by the user can be determined by a call that is a communication partner in a control packet. Upon receiving the notification, the call device can execute processing according to the buffer of the call partner, for example, processing such as changing the compression encoding method and variably setting the transmission rate.

  According to the communication device according to the present invention, in the communication device that transmits and receives real-time acoustic data via the Internet, the compression encoding means that compresses and encodes real-time acoustic data including voice, and the compression encoding means Data packet generating means for generating a data packet storing compression-encoded data, control packet generating means for generating a control packet storing at least management information for managing transmission / reception of the data packet, the data packet and the data packet Transmitting means for transmitting a control packet to one or more other communication devices via the Internet; receiving means for receiving data packets and control packets from the one or more other communication devices; and receiving data packets Decoding / decompressing means for decoding / decompressing the stored compressed encoded data, and the decoding / decompressing unit A buffer for buffering data and a control means for controlling the capacity of the buffer based on a user's instruction. For example, if the buffer is enlarged, the amount of time required for retransmission of missing packets is lengthened and the amount of transmission information is large. The quality of such high sound quality data can be maintained. On the other hand, the user needs such as reducing the buffer size in normal calls where only voice is used and low delay and responsiveness is important. It is possible to receive data in accordance with.

  In the communication system according to the present invention, the user of each communication device can receive data according to user needs by setting the buffer capacity to a desired capacity. The buffer capacity can be known from the control packet, and data transmission according to the needs of the other party can be performed.

  Hereinafter, specific embodiments to which the present invention is applied will be described in detail with reference to the drawings. The present invention is applied to a VoIP client as a call device in which two or more call devices make a call by VoIP over the Internet and a VoIP system as a call system including the VoIP client. The VoIP client according to the present embodiment allows the user to select a case where high sound quality audio data to which BGM is added and importance is attached to sound quality, and a case where importance is attached to low delay as in a normal call. It is something that can be done.

  First, an outline of a VoIP system that performs network communication using VoIP in the present embodiment will be described. FIG. 1 is a schematic diagram showing an example of a VoIP system in the present embodiment. The VoIP system according to the present embodiment realizes high-quality voice communication that can share not only a call but also various sound effects and BGM, for example, between two or more channels and between users. Note that the VoIP system in the present embodiment is performed between two call devices (hereinafter referred to as VoIP clients). However, the number of VoIP clients constituting the VoIP system is not limited to two. Of course, there are two or more participants who can participate in network communication.

  As shown in FIG. 1, the VoIP system 100 includes a VoIP client 111 such as a PC (Personal Computer), for example, and a VoIP client 121 connected thereto via the Internet 130.

  In the VoIP system 100, the user 110 of the VoIP client 111 and the user 120 of the VoIP client 121 are VoIP applications (soft phones), which will be described later, installed in their VoIP clients 111 and 121, for example. A headset composed of a microphone and headphones or a handset composed of a microphone and a receiver is used to communicate with a communication partner via the Internet 130.

  The Internet 130 is a network environment that is spread all over the world by connecting a plurality of communication lines such as general public lines and information communication networks. Currently, broadband transmission is enabled by the widespread use of broadband and high-speed communication lines. A network is configured with a communication line of 500 kbps or higher using an optical fiber, an asymmetric digital subscriber line, radio, or the like.

  Connected to the Internet 130 are a VoIP server 131 for controlling VoIP communication, a web server 134 for managing data such as sound source data 132 and download user information 133, and the like. Each VoIP client 111, 121 stores sound source data 113, 123 downloaded from the web server 134 by the web browser 112, 122 or the like included in each VoIP client 111, 121, or purchased or edited by itself. Yes.

  The sound source data 132 stored in the database of the web server 134 and the sound source data 113 and 123 possessed by the user by downloading, for example, are music used for BGM (Back Ground Music) or the like, or sound of waves -Various sound effects such as clapping sound, thunder, bell sound, etc. These sound source data can be used in network communication between users.

  Next, the VoIP client will be described. FIG. 2 is a block diagram showing the functions of the VoIP client constituting the VoIP system. As shown in FIG. 2, the VoIP client 20 for performing such Internet communication receives the data from the calling party and the transmission means 21 for transmitting data to the participants participating in the communication, that is, the calling party. Receiving means 41.

  The transmission means 21 is connected to a microphone, and is compressed into a microphone capture (MIC capture) 22 that catches the external (user) voice and, for example, MP3 (MPEG (Moving Picture Experts Group) 1 audio Layer 3) or MPEG4 Sound effect file storage section 23 storing sound source files of various sound effects (SE), BGM file storage section 24 storing sound source files of various compressed BGM, sound effect files and BGM files Decoders 25 and 26 that respectively read and decode the sound, gain adjustment units 27 to 29 that adjust the volume by controlling the gain of the sound, sound effect, and BGM captured by the microphone, and the synthesis unit 30 that synthesizes these three sounds An encoder 31 for compressing and encoding the synthesized sound, and a data packet for the encoded data. A packetize unit 32a serving as a data packet generating means for storing data in an RTP (Real-Time Transport Protocol) packet, and a PCM buffer (not shown) for buffering data decoded by a decoder 46 described later Control unit 34 for managing various control information stored in RTCP (Real-Time Control Protocol) packets and management information for controlling RTP packets, and storing control information and management information in RTCP packets An RTCP packetizing unit 32b as a control packet generating unit, and a transmitting unit 33 that transmits an RTP packet, an RTCP packet, and the like. The RTP packet sent from the sending unit 33 is sent via the Internet 130 to another VoIP client to be communicated.

  On the other hand, the receiving means 41 for receiving data sent from the transmitting means 21 of the communication partner via the Internet 130 includes a receiving section 42 for receiving RTP packets and RTCP packets, and an RTP depacketizing section for depacketizing the received RTP packets. (Depacketize) 43a, an RTCP depacketizing unit (depacketize) 43b for depacketizing an RTCP packet, a dejitter unit (de-jitter) 44 for correcting the arrival time of the RTP packet, and a portion where an error has occurred in the sent RTP packet Alternatively, a packet compensator 45 that compensates for missing parts such as a lost part during transmission, a decoder 46 that decodes and decompresses data from the packet compensator 45, and an incoming call that is compressed to MP3, MPEG4, etc. Ring tone file (Ring Tone) that stores sound source files File) storage unit 47, decoder 48 that reads and decodes the ringtone file, gain adjustment units 49 and 50 that adjust the gains of decoders 46 and 48, and synthesis unit 30 in transmission means 21 described above. PCM data for transmission, that is, a gain adjusting unit 52 that adjusts the gain of the transmitter's own sound source, and a combining unit that combines the gain-adjusted transmission data, data transmitted from the communication partner, and ringtone data 53, an output unit 54 that outputs the data synthesized by the synthesis unit 53 to the headphones (HP), a gain adjustment unit 51 that adjusts the gain of the ringtone separately from the ringtone output to the synthesis unit 53, And a speaker (SP) 55 for outputting a gain-adjusted ring tone to the outside.

  Next, a data transmission / reception method of the VoIP client will be described. First, on the transmission side, the microphone capture 22 catches the user's voice input by the microphone and sends it to the gain adjustment unit 27. The gain adjusting unit 27 multiplies the audio data by a gain coefficient k1 in accordance with a user instruction or automatically, and adjusts the gain to a desired magnitude.

  The sound effect file storage unit 23 and the BGM file storage unit 24 store, for example, a hard disk drive (HDD), a ROM (read only memory), or a magneto-optical device in which a sound source file compressed in advance by a compression technique such as MP3 or MPEG4 is stored. It consists of a disc, and the decoders 25 and 26 read out these compressed encoded data, and convert the read compressed encoded data into PCM data. Furthermore, the decoders 25 and 26 send the converted PCM data to the gain adjustment units 28 and 29, respectively, and the gain adjustment units 28 and 29 respectively send the received data according to a user instruction or automatically. Multiply the gain coefficients k2 and k3 to adjust the gain to a desired size.

  The sound, BGM, and sound effect that have been gain-adjusted by the gain adjusting units 27 to 29 are supplied to the synthesizing unit 30, and the synthesizing unit 30 adds the outputs of the gain adjusting units 27 to 29 while performing saturation processing, and the addition result Is output to the encoder 31. The encoder 31 encodes, for example, MPEG4 in order to transmit the addition result through the network. The encoded data is supplied to an RTP packetizing unit 32 that packetizes the data according to a real-time transport protocol (RTP).

  The RTP packetization unit 32a packetizes the encoded data into RTP packets, and the packetized data is transmitted from the transmission unit 33 to the VoIP client of the communication partner via the Internet 130.

  The control unit 34 controls the capacity of the PCM buffer provided in the subsequent stage of the decoder 46 based on a user operation. Then, according to the PCM buffer capacity changed by the user operation, control information such as a retransmission request of a lost packet in which an error occurs or is lost during transmission is generated. Further, this buffer capacity is stored in the extended portion of the RTCP packet. Furthermore, in the extended portion of the RTCP packet transmitted and received by the VoIP client in the present embodiment, the capacity of the fluctuation absorbing buffer for canceling the jitter of the packet received by the RTCP receiver 42 can be described. The control unit 34 can manage various management information stored in the report block of the RTCP packet, and can also generate other control information stored in the extended portion of the RTCP packet. Other control information includes a capacity of a PCM buffer for storing uncompressed PCM data before reproduction. Compression of real-time acoustic data stored in an RTP packet transmitted by another VoIP client serving as a communication partner. For example, there is information such as the encoding band and the number of subband divisions that specifies the rate.

  The RTCP packetizing unit 32b packetizes the control information and management information into RTCP packets, and the packetized data is also transmitted from the transmitting unit 33 to the VoIP client of the communication partner via the Internet 130.

  In a VoIP call, before transmitting an RTP packet, the control unit 34 performs call signaling to another VoIP client to be communicated via the transmission unit 33 using a call control protocol such as SIP. Then, after the RTP / RTCP session is established between other VoIP clients, the transmission unit 33 can transmit the RTP packet and the RTCP packet. Details of the RTP / RTCP packet will be described later.

  On the other hand, on the receiving side, the receiving unit 42 receives RTP packets, RTCP packets, and the like sent via the Internet 130. Then, the RTCP depacketization unit 43b disassembles the received RTCP packet, and the control unit 34 extracts the above-mentioned PCM buffer information stored in the extended portion of the RTCP packet and can change the transmission rate according to this information. Process.

  Also, after the RTP packet received by the receiving unit 42 is depacketized by the depacketizing unit 43, the dejitter unit 44 corrects data whose arrival times are unequal due to delays in reception due to, for example, network conditions And equal intervals. This correction is performed based on the RTP time stamp and sequential number that are depacketized and decomposed from IP and UDP (User Datagram Protocol). Thereafter, the packet compensator 45 ensures the packet that is lost or cannot be received in the transmission / reception of the network, specifically, the same packet as the previous or subsequent packet is used instead of the lost packet. The packet loss is compensated by requesting retransmission of the lost packet or receiving the lost packet again. The compressed data such as MPEG4 obtained in this way is decoded by the decoder 46, and the gain adjustment unit 49 multiplies the gain coefficient k5 by the user or automatically adjusts the gain.

  The decoder 48 generates a ring tone sound source file including a ring tone for calling or a music used for calling when a call is signaled from another VoIP client, that is, when a call is received. Read from the ringtone file storage unit 47. The ring tone data from the file storage unit 47 is selected in advance according to the user's request, and is decoded by the decoder 48 while being read into a RAM (not shown) according to the timing of the incoming call. The sound file of the ringtone is also compressed to MP3, MPEG4, etc., like the sound file of BGM, etc., and is stored in the file storage unit 47 for a plurality of files as ringtone data for each file. Then, the decoder 48 decodes the read sound source file, and gain adjustment is performed by the gain adjusting units 50 and 51 multiplying the decoded sound source data by a user instruction or automatically by gain coefficients k6 and k7, respectively.

  The synthesizer 53 adds the received data received from the call partner and the transmission data output from the gain adjuster 52, which is transmitted from the ring tone and the communication partner and gain-adjusted by the gain adjuster 49. . The gain adjusting unit 52 multiplies the transmission data by a gain coefficient k4 that is a loopback volume level set by the user in order to share the transmission data to be transmitted with the other party.

  Then, the data synthesized by the synthesizing unit 53 is output via the headphones 54 and transmitted to the user. In addition, the ring tone data read from the ring tone file storage unit 47 is configured to be output from the speaker 55 separately from the headphones 54.

  In such a VoIP client, the capacity of the PCM buffer can be variably set according to user operation. Therefore, when exchanging high-quality real-time acoustic data with BGM or the like according to user needs, Increases the capacity of the PCM buffer so as to maintain the high sound quality for a long period of time that can be requested for retransmission of missing packets. When exchanging real-time acoustic data only for voice, for example, the capacity of the PCM buffer is set to zero. Emphasis can be given to responsiveness.

  Furthermore, by widening the dynamic range as compared with a general telephone, it is possible to transmit and receive a synthesized sound in which a high-quality sound such as stereo and sound composed of BGM and sound effects are synthesized. Even if is added, conversation (voice) is not masked. In addition, since the sound read from the sound source file such as the sound effect and BGM and the sound spoken by the communication person, that is, the microphone sound can be adjusted separately, the sound effect and the volume of the BGM can be set to desired levels. The user can adjust the user's feelings, for example, to the communication partner.

  In addition, by outputting the ringtone separately from the headphone 54 and the speaker 55, for example, the user temporarily leaves the VoIP client 20 during VoIP communication using the headphone 54, or even after the call ends. Even when 54 is left set, the ringtone can be output from the speaker 55 to the outside.

  Next, software used for the VoIP client will be described. FIG. 3 is a diagram illustrating a software module including a general VoIP client application for a PC. The VoIP client performs the function shown in FIG. 2 by executing the software module 1 corresponding to the protocol of each layer based on the open system interconnection (OSI) architecture shown in FIG. Achieve.

  In FIG. 3, each layer will be described from the lower layer to the upper layer. First, the functions as the physical layer 2 include a universal serial bus (USB) camera driver 2a, a USB audio driver 2b, and various drivers 2c. This is a layer that matches the physical conditions of the transmission conditions of video data from the camera driver 2a and audio data from the audio driver 2b.

  Next, the function as the data link layer includes an operating system (OS) 3. This is for executing data transmission without error between adjacent nodes.

  The network layer function includes an Internet Protocol (IP) control unit 4. The network layer selects a communication path used for data transmission / reception and performs communication control such as flow control and quality control. IP, which is a connectionless packet transmission protocol that does not pursue reliability, leaves the reliability assurance function, flow control function, and error recovery function to the upper layers (transport layer and application layer).

  The function as the transport layer includes a transport control protocol (TCP) / user datagram protocol (UDP) control unit 5.

  In the transport layer, end-to-end transmission is performed using an IP address. Regardless of the type of network, flow control and sequence control are performed according to the required quality class. TCP has a reliability guarantee function, attaches a sequence number to each byte of transmitted data, and retransmits the data if no acknowledgment (Acknowledgment: ACK) is sent from the receiving side. UDP provides a function for transmitting datagrams between applications. When streaming an audio / video using an IP network, generally, a transport protocol such as TCP that retransmits when an error occurs cannot be used. TCP is a protocol for one-to-one communication, and information cannot be transmitted to a plurality of partners. Therefore, UDP is used for such applications. In other words, when performing highly reliable communication such as requiring retransmission control, TCP packets are generated as TCP communication, and communication with high real-time properties such as transmission of audio and video data and SIP described later is performed. When performing, UDP communication is generated as UDP communication.

  UDP is designed to allow application processes to transmit data to other application processes on a remote machine with minimal overhead. Therefore, the information entered in the UDP header is only the source port number, destination port number, data length, and checksum, and there is no field for entering the number indicating the order of packets in TCP. When the order of the packets is changed due to transmission through the network, processing for returning the order to the correct state cannot be performed. Also, there is no field for inputting time information such as a time stamp at the time of transmission in TCP or UDP.

  The function as the session layer 6 includes a session initiation protocol (SIP) control unit 11, an RTP / RTCP control unit 12, a codec (codec) 13, a speech sound and BGM and / or sound effect synthesis processing There is a holding tone control unit 14, a BGM synthesis unit 15, and a ring tone control unit 16 that constitute software. The session layer 6 controls information transmission. Manage conversation modes between applications and control conversation units.

  The SIP control unit 11 performs call control using a signaling protocol of the application layer 6 (standardized by RFC3261) for establishing, changing, and terminating a multimedia session on the IP network.

  Of the RTP / RTCP control unit 12, RTP is a protocol for transmitting transmission data in which BGM and sound effects are combined with audio data and compressed and encoded. Time information and order information are added to the transmission data. And has a function of transmitting and receiving voice data through the network. RTCP is a control protocol for controlling RTP, and has functions of performing RTP flow control, clock synchronization, data reproduction time recognition, information source recognition, and the like.

  The codec 13 has a function of compressing and decoding the transmission sound (transmission data) described later with high efficiency.

  The TCP / UDP control unit 10 generates a TCP packet as TCP communication when performing highly reliable communication, for example, requiring retransmission control, and transmits audio and video data, and SIP described later, etc. When communication with high real-time property is performed, UDP communication is generated as UDP communication, and the IP control unit 11 has a function of converting a TCP packet or a UDP packet into an IP packet.

  The function as the presentation layer includes VoIP call control 7. The presentation layer manages the expression format of information transmitted and received by the application, and performs data conversion and encryption. The VoIP call control unit 7 is a control unit that controls the entire VoIP call function.

  As a function of the uppermost application layer, there is a graphical user interface (GUI) 8 for visually operating a computer. The application layer is a layer for managing external specifications of communication functions used in the user program and exchanging information based on the external specifications. The GUI 8 provides an interface for user operation and handles user input information. .

  FIG. 4 is a schematic diagram illustrating an example of a GUI. As shown in FIG. 4, the GUI 8 includes an application control unit 61 that performs termination processing of the VoIP client application 1, an information display unit 62, a dial unit 63, a headset volume unit 64a, a speaker volume unit 64b, and a sound. It has an effect selection display unit 65, a sound effect control unit 66, a BGM selection display unit 67, a BGM control unit 68, and a PCM buffer adjustment unit 69.

  The information display unit 62 displays a dial number when the user dials the number of the other party to be communicated, a partner state such as whether or not the communication partner is busy, and the like. The dial unit 63 includes a numeric keypad for dialing a VoIP counterpart. The headset volume 64a adjusts the volume output from the headset, and the speaker volume unit 64b adjusts the volume output from the speaker. The sound effect selection unit 65 displays a sound effect sound source data file that can be used by the user. For example, a gunshot sound, lightning sound, applause sound, cheering sound, etc. can be selected. Play and stop sound, and adjust volume. Thereby, a user can express feelings to the other party with various sound effects.

  Further, the BGM selection display unit 67 displays a BGM sound source data file such as a sound of a Tahiti wave that can be used by the user. Further, the BGM control unit 68 further plays and stops the BGM and the volume of the BGM. By performing the adjustment, the user's mood and the atmosphere of the place can be communicated to the communication partner by the volume selected and adjusted by the user himself, like the sound effect.

  As described above, the PCM buffer adjustment unit 69 is an operation unit provided to allow the user to adjust the capacity of the PCM buffer that buffers PCM data after decoding processing and before reproduction output. For example, when exchanging high-quality real-time acoustic data, the buffer capacity is increased, and when exchanging real-time acoustic data for the purpose of low delay, adjustment is made such as reducing the buffer capacity.

  Next, the hardware configuration of the VoIP client that executes the software module 1 will be described. FIG. 5 is a block diagram showing a hardware configuration of the VoIP client. As shown in FIG. 5, in the VoIP client 20, a CPU (Central Processing Unit) 221 includes various programs constituting the software module stored in a ROM (Read Only Memory) 222 or a RAM (Random) from the storage unit 228. Access Memory) 223 executes various processes in accordance with various programs constituting the software module 1 described above. In addition, a timer (not shown) performs time counting operation and supplies time information to the CPU 221. The RAM 223 also appropriately stores data necessary for the CPU 221 to execute various processes.

  The CPU 221, ROM 222, and RAM 223 are connected to each other via a bus 224. An input / output interface 225 is also connected to the bus 224.

  The input / output interface 225 includes an input unit 226 including a keyboard and a mouse, a display including a CRT and an LCD, an output unit 227 including a headphone and a speaker, a storage unit 228 including a hard disk, a modem, a terminal A communication unit 229 composed of an adapter or the like is connected.

  The communication unit 229 performs communication processing via the Internet (not shown). Data provided from the CPU 221 is transmitted. The communication unit 229 outputs data received from the communication partner to the CPU 221, RAM 223, and storage unit 228. The storage unit 228 communicates with the CPU 221 to store and delete information. The communication unit 229 also performs analog signal or digital signal communication processing with other clients.

  A drive 230 is connected to the input / output interface 225 as necessary, and a magnetic disk 241, an optical disk 242, a magneto-optical disk 243, a semiconductor memory 244, or the like is appropriately mounted, and a computer program read from these is loaded. It is installed in the storage unit 228 as necessary.

  Next, a method of executing a VoIP call by executing various programs constituting the software module 1 shown in FIG. 2 by the VoIP client having such a hardware configuration will be described.

  FIG. 6 is a diagram for explaining the RTP / RTCP packet transmission / reception function controlled by the VoIP call control unit 7 in the general PC software module shown in FIG. As shown in FIG. 6, the control of the VoIP call control unit 7 can be divided into threads 1 to 5. The thread 1 is a process until the sender transmits an RTP packet, that is, a process of transmitting a data packet containing data including voice uttered by the sender, and the threads 2 and 3 transmit the transmitted RTP packet. Processing until reception and reproduction, that is, processing until the sender hears data including the voice of the other party with whom communication is made.

  The thread 4 is automatically generated by a thread library attached to the operating system (OS) 3. The thread library performs calculation resource allocation, that is, scheduling, on the main processor (CPU 221 shown in FIG. 5) of the thread 1, thread 2, and thread 3 according to priority.

  The thread 5 is a main thread of the GUI 8 that is an application. The thread 5, the thread 2, and the thread 3 are generated and destroyed, and the thread 1, the thread 2, and the thread 5 are generated according to a programmed algorithm or a user operation. The thread 3 is controlled.

  In the thread 1 which is the transmission processing of the RTP / RTCP packet, the user's voice is captured from the microphone and PCM data is received (Capture). If necessary, the BGM synthesizing unit 5 etc. The sound effects and BGM and sound are synthesized (Effect or Mixing), and the codec 13 compresses and encodes the data (encode). Then, the RTP / RTCP control unit 12 converts the compression-encoded data into an RTP packet (packet) and transmits the packet (send).

  In addition to the RTP packet transmission process, an RTCP packet transmission process that stores control information for controlling the codec compression encoding method in the communication target communication device is performed.

  On the other hand, in the RTP packet receiving process, a fluctuation absorbing buffer provided before and after the decoding process provided on the receiving side of the VoIP client, that is, a fluctuation absorbing buffer (Forward Jitter buffer) BF1 for storing the encoded byte stream PCM, and a decoding A fluctuation absorbing buffer (Backward Jitter buffer) (hereinafter referred to as a PCM buffer) BF2 that stores data that is provided after processing and is decoded and converted into uncompressed linear PCM is used.

  Here, as will be described later, the fluctuation absorbing buffer BF1 is automatically adjusted to a capacity required to absorb transmission fluctuation according to the reception state of the RTP packet with the other party. The capacity of the PCM buffer BF2 for storing the compressed data can be manually input by the user, and the user operates this when exchanging high-quality sound data to which BGM or the like is added. In addition, the capacity of the PCM buffer BF2 can be set large. On the other hand, the capacity of the PCM buffer BF2 can be set to zero, for example, when importance is placed on responsiveness with low delay, such as when making a call with only normal voice.

  First, in the RTP / RTCP packet reception function, in the thread 2, the RTP / RTCP control unit 12 receives the RTP packet (Receive), and data loss occurred on the network, data error of the transfer packet, and the like are missing. Processing to supplement the packet, for example, a packet retransmission request is performed (parse), and the packet is stored (push & pop) in the fluctuation absorbing buffer BF1 provided before the decoding processing. This is decoded and decompressed by the codec 13 (decode) and stored as uncompressed data in the PCM buffer BF2 provided after the decoding process (push).

  In the thread 3, the USB camera driver 2a, USB audio driver 2b, and various drivers 2c read unpopulated data from the PCM buffer BF2 (pop), and reproduce the read data (sound device). Here, if the PCM buffer BF2 is large, the time from when data is buffered to the PCM buffer BF2 until it is read out becomes long. That is, it is possible to make room for the scheduled reproduction time of the received packet, and it is possible to request retransmission of the lost packet and receive it before the scheduled reproduction time.

  Further, the effect effect and effect or mixing of BGM and sound performed in the thread 1 may be performed after the data is read from the PCM buffer BF2 in the thread 3 and before the reproduction.

  Here, the capacity (buffer size) of the fluctuation absorbing buffer BF1 provided before the decoding process can be obtained as follows. FIG. 7 is a diagram showing exchange of RTP packets between a VoIP client UAS as an RTP packet sender (RTPSender) and a VoIP client UAR as an RTP packet receiver (RTPReceiver), which is a round using RTCP. It is a sequence diagram which shows the calculation method of Trip Time.

  In FIG. 7, Si and Sj are the transmission times of the RTP packets P (i) and P (j) sent from the transmission side VoIP client UAS at the time i and j (Si = 10 Nov 1995 11: 33: 25.125, Sj = 10 Nov 1995 11: 33: 25: 145), Ri and Rj are the arrival times (Ri = 10) of the RTP packets P (i) and P (j) received by the receiving-side VoIP client UAR at times i and j. Nov 1995 11: 37: 23.235, Rj = 10 Nov 1995 11: 37: 24.002).

Then, the VoIP call control unit 7 uses the time stamp of the RTP packet and calculates the arrival interval at the time of transmission and reception of the two packets P (i) and P (j) from the following calculation formula described in RFC1889. The difference D is obtained, and thereby the jitter J can be calculated.
D (i, j) = (Rj−Ri) − (Sj−Si) = (Rj−Sj) − (Ri−Si)
J = J + (| D (i-1, i) | -J) / 16
Thereby, the capacity of the fluctuation absorbing buffer BF1 for buffering the reception data in the encoded state shown in FIG. 6 can be calculated in units of milliseconds and microseconds.

  Then, if necessary, the capacity of the fluctuation absorbing buffer BF1 is automatically adjusted, and RTP packets are processed in the order of insertion and extraction with respect to the automatically adjusted fluctuation absorbing buffer BF1 (push & pop of thread 2).

  Then, as described above, the byte stream taken out from the fluctuation absorbing buffer BF1 is decoded, and if necessary, written to the sound device and reproduced. Here, before writing to the sound device as necessary, the decoded data is inserted into the PCM buffer BF2.

  Next, the RTP / RTCP packet in the VoIP system in the present embodiment will be described more specifically.

  The RTP / RTCP packet is transmitted / received after the RTP / RTCP session is established by the call control of the SIP control unit 11 shown in FIG. FIGS. 8A and 8B are diagrams showing the configuration of the RTP packet and the format of the header. FIGS. 9A to 9C show the configuration of the RTCP APP packet that can be expanded by the application and its header. It is a figure which shows the example of a format of (RTCP APP Application-defined Header) and a transmission report.

  RTP is a transport protocol for transmitting / receiving voice and moving images in real time in an IP network such as the Internet, and is recommended by RFC1889. RTP is located in the transport layer and is generally used with RTCP over UDP.

  And as shown to Fig.8 (a), an RTP packet consists of an IP header, a UDP header, an RTP header, and RTP data. In the RTP header, as shown in FIG. 8B, from the top, a version information storage unit (V: version, for example, V = 2) F1, a padding storage unit (P: padding) F2, an extension bit storage unit (X: extension) F3, CSRC (contributing source) count storage unit (CC) F4, marker information (M: marker) storage unit F4, marker bit storage unit (M: maker) F5, payload type information storage unit (PT : Payload type) F6, sequence number information storage unit (sequence number) F7, time stamp storage unit (time stamp) F8, SSRC identifier storage unit (synchronization source identifier) F9, and CSRC identifier storage unit F10 are provided to store CSRC identifiers. Real-time acoustic data is added behind the part F10.

  The version information storage unit F1 stores information indicating the RTP version. For example, when indicating RTP2, the version information indicating that is stored.

  The count storage unit F4 indicates the number of CSRCs (contributing transmission source identifiers) indicated in the header.

  The payload type information storage unit F6 stores information indicating the type of real-time acoustic data, for example, information indicating video or audio.

  The sequence number information storage unit F7 counts up every time an RTP packet is transmitted / received in an RTP session, and stores a sequence number for recognizing the order of the RTP packets to be transmitted / received.

  The time stamp storage unit F8 stores time stamp information related to the date and time when real-time acoustic data is created and updated.

  Information for identifying the source on the data transmission side in the RTP session is stored in the SSRC identifier storage unit F9 and the CSRC identifier storage unit F10. The SSRC identifier is a synchronous transmission source identifier, is an identifier assigned so that a plurality of streams to be handled in combination by the same user share the same value, and the CSRC identifier is a contributing transmission source identifier, indicating a stream source . This is used when a plurality of streams are mixed and provided as one stream data.

  When transmitting real-time acoustic data according to RTP, the RTP / RTCP control unit 8 shown in FIG. 3 stores various types of information in the storage units and recognizes the various types of information stored in the storage units. Process to extract acoustic data.

  While RTP is a protocol that transmits / receives audio / video data itself, RTCP periodically evaluates line quality such as packet loss, delay jitter, and round trip, and matches the bandwidth. A protocol for transmitting / receiving information to realize real-time communication.

  By using this RTCP, it is possible to perform dynamic processing such as changing the transmission rate by estimating the network state or the like based on information fed back from the other party. In addition, since information indicating who is currently sending data and who is receiving it is also sent at the same time in the RTCP packet, it is possible to know the current participant information.

  As shown in FIG. 9A, the RTCP packet includes an IP header, a UDP header, an RTCP header, and RTCP data. Then, in the header of the RTCP APP packet that is an expandable RTCP packet, as shown in FIG. 9B, the version information storage unit (V: version, for example, V = 2) F11, the padding storage unit ( P: padding) F12, subtype storage unit F13, packet type (PT) storage unit F14, report length storage unit (length) F16, SSRC / CSRC identifier storage unit F17, ASCII (American Standard Code for Information), A Name storage unit F18 described in US standard code for information exchange) is provided, followed by a data storage unit (Application-Dependent Data) F19 in which application-specific data is stored.

  The type of RTCP packet is recorded in the packet type PT storage unit F14, and in this embodiment, this packet type PT = APP (Application: application specific information) = 204 (packet type value) is described. APP indicates that it is a packet for notifying application-specific control information outside the RTCP standard.

  As described above, the RTP / RTCP control unit 8 shown in FIG. 3 uses the RTCP packet as a RTCP APP packet, and as described above, the fluctuation for receiving the RTP packet used to absorb the jitter when the RTP packet is received as the retransmission request for the missing packet. The capacity of the absorption buffer can be described and transmitted in the data storage unit F19. At the same time, according to an instruction from the VoIP call control unit 3, it is possible to describe and transmit information on frequency components to be compressed in transmission data to be transmitted by the communication partner.

  Here, the RTCP packet includes an RTCP SR (Sender Report,) packet of a type sent from the sender of the RTP data and an RTCP packet RTCP RR (Receiver Report,) of a type sent from the receiver of the RTP data. is there.

  The SR packet is transmitted from a terminal that is transmitting a stream to another terminal. Transmission information (sender info) that is information regarding a stream transmitted by the own device and reception of the stream for each received stream Including a report block (reception report block) for reporting the state (packet discard rate, jitter, etc.) to the transmitting device, and the RR packet is for notifying information on the stream received from the other communication device, Similarly, each received stream includes a report block for reporting the reception status of the stream to the transmitting apparatus.

  As shown in FIG. 9C, this report block includes a synchronization source (SSRC) identifier of a packet sender, an RTP loss rate, the number of lost RTP packets, a reception sequence number, and jitter of an arrival time interval. The average value, the transmission time of the last received SR (LSR: Last SR timestamp), and the time (DLSR: Delay since Last SR) from when the SR was last received until this RR is sent are entered.

  Therefore, the transmission side manages the number of transmission RTP packets and the number of transmission RTP bytes when transmitting RTP data, and the reception side receives the number of received RTP packets when receiving RTP data. Management information such as the number of lost RTP packets and jitter of arrival time is managed.

  FIG. 10 is a diagram showing messages exchanged when exchanging RTCP APP messages in the present embodiment. In the RTCP APP packet including SR (Sender Report) and the RTCP APP packet including RR (Receiver Report) exchanged between UA1 and UA2 which are both RTP Sender and Receiver, as shown in FIG. As data, the encoding bandwidth (Encode Bandwidth), the number of subband division blocks (sub band Numbers), the fluctuation absorption buffer capacity (Forward and Backward Jitter Buffer size) before and after the decoding processing unit, and the data queued in the absorption buffer The size (Buffer queued size) and retransmission request information (Re-Request: sequence number) of the RTP packet can be described. The sequence number is used for the RTP packet retransmission request.

  The capacity of the fluctuation absorbing buffer BF1 before the decoding process, the PCM buffer BF2 which is the fluctuation absorbing buffer after the decoding process, and the data size queued in these buffers can be converted into time.

  Here, as described above, the VoIP client in the present embodiment can change the buffer size (buffer capacity) of the PCM buffer BF2 based on a user operation. When the buffer capacity of the PCM buffer BF2 is changed, for example, the buffer adjustment unit 69 of the GUI 8 shown in FIG. 4 may be used so that the user adjusts appropriately as necessary. Further, the RTP packet reception side can measure (calculate) the reception bit rate of the RTP packet constantly or periodically, and the user adjusts the capacity of the PCM buffer BF2 according to the calculated reception bit rate. You may do it. For example, the VoIP client notifies the reception bit rate to the user, and the user may change the capacity of the PCM buffer BF2 based on the reception bit rate.

  Then, by using this RTCP APP packet, the adjusted buffer capacity of the PCM buffer BF2 is notified to the other VoIP client as the other party of communication, so that the other VoIP client changes the transmission rate of transmission data according to the buffer capacity. be able to. Furthermore, based on the data size queued in the absorption buffer (data occupancy buffered in the fluctuation absorption buffer BF1 and PCM buffer BF2), the free capacity of the buffer can be accurately recognized, and transmission is performed based on this. You can change the rate.

  In addition, the VoIP client subtracts DLSR (Delay since Last Sender Report) from the time from when the RTCP packet including the SR (Sender Report) block is transmitted until the RTCP packet including the RR (Receiver Report) block is received. By measuring the calculated RTT (Round Trip Time) and making a retransmission request for the missing packet based on this and the capacity of its own fluctuation absorbing buffer BF1 or PCM buffer BF2, it is particularly affected by the missing packet such as BGM. It is possible to maintain the quality when transmitting and receiving easy data.

  That is, since the time information until the retransmission requested packet is retransmitted can be obtained by the RTT, the scheduled decoding start time of the packet or the reproduced reproduction time for reproducing the decoded data from the time when the retransmission requested packet arrives When the packet is late, it is possible to request retransmission of the missing packet.

  Accordingly, by making the capacity of the PCM buffer BF2 variable by a user operation, it is possible to adjust the period from when a packet arrives until the scheduled reproduction time at which the data stored in the packet is reproduced, that is, the period during which retransmission can be requested. For example, when a voice-only call is performed, that is, when it is not necessary to request retransmission again when it is important that the delay is smaller than a slight deterioration in sound quality, the capacity of the PCM buffer BF2 is reduced. Or it may be set to zero.

  On the other hand, when additional data such as BGM is synthesized and transmitted and received, that is, when it is important that the sound quality is higher than some delay, if the capacity of the PCM buffer BF2 is increased, It is possible to request retransmission of missing packets, and the user can reproduce and output data free from errors and losses.

  Further, the VoIP client of the communication partner that has received the notification of the buffer capacity of the fluctuation absorbing buffer BF2 increases the transmission bit rate according to the capacity of the buffer BF2, that is, when the capacity of the PCM buffer BF2 is large. When the transmission data is small and the capacity of the PCM buffer BF2 is small, the transmission rate can be made variable, for example, by transmitting only the voice without adding BGM and thereby reducing the transmission bit rate. .

  In addition to the control information such as the buffer capacity of the fluctuation absorbing buffers BF1 and BF2 before and after the decoding process, the information on the amount of data occupying the fluctuation absorbing buffers BF1 and BF2, and the retransmission request of the missing packet, as the application specific information APP The VoIP client on the receiving side specifies the compression encoding method of the communication partner by describing the information specifying the encoding bandwidth and the number of subband division blocks of the transmission data of the VoIP client on the transmitting side. It is also possible to control the transmission rate of the received stream.

  In the present embodiment, a fluctuation absorbing buffer BF1 that can automatically secure a capacity corresponding to a jitter value calculated using the header of an RTP packet is prepared before a decoding processing unit that decodes compressed audio data. By providing a fluctuation absorbing buffer BF2, which is a PCM buffer for the capacity manually input by the user, after the decoding processing unit, both the needs of users who desire low delay and the needs of users who face high sound quality can be satisfied. it can.

  That is, by providing a PCM buffer BF2 that can be adjusted manually by the user in addition to the fluctuation absorbing buffer BF1, which is an automatic adjustment buffer that emphasizes low delay, the width on the time axis that makes retransmission requests for lost packets effective. In the case where it is desired to record in a high sound quality state, reception with an emphasis on sound quality becomes possible, and the trade-off between low delay and high sound quality can be left to the user operation.

  Thus, when the VoIP client is the reception side, the reception state of low delay or high sound quality can be selected, and when it is the transmission side, the buffer capacity of the fluctuation absorbing buffer BF1 and the PCM buffer BF2 of the communication partner Accordingly, transmission data having a transmission rate according to the needs of the communication partner can be transmitted.

It is a schematic diagram which shows an example of the VoIP system in embodiment of this invention. It is a block diagram which shows the principal part which consists of the VoIP client 111 and the internet 130 among the VoIP systems in embodiment of this invention. It is a figure which shows the VoIP client application at the time of using general PC as a VoIP client which the VoIP system in embodiment of this invention has. It is a schematic diagram which shows an example of GUI in the said VoIP client application. It is a block diagram which shows the hardware constitutions of the VoIP client (VoIP client) in the VoIP system in embodiment of this invention. It is a functional block diagram which shows the process which transmits / receives an RTP / RTCP packet among the VoIP client applications shown in FIG. It is a sequence diagram which shows the calculation method of Round Trip Time using RTCP. (A) And (b) is a figure which shows the structure of a RTP packet, and the format of a header, respectively. (A) thru | or (c) is a figure which shows the format example of the structure of the RTCP APP packet expandable by an application, its header (RTCP APP Application-defined Header), and a transmission report. It is a figure which shows the message exchanged at the time of the exchange of RTCP APP message in the VoIP system in this Embodiment.

Explanation of symbols

1 VoIP client application, 21 transmission means, 22 microphone capture, 23 sound effect file reading unit, 24 BGM file reading unit, 25, 26, 31 decoder, 27, 28, 29 gain adjustment unit, 30 synthesis unit, 31 encoder, 32 Packetizing unit, 33 transmitting unit, 41 receiving means, 42 receiving unit, 43 depacketizing unit, 44 dejittering unit, 45 packet compensating unit, 46 decoder, 47 reading unit, 48 decoding unit, 49, 50, 51, 52 gain adjusting unit , 53 synthesis unit, 54 output unit, 55 speaker, 100 VoIP communication system, 111, 121 VoIP client, 110, 120 user, 112, 122 web browser, 134 web server, 113, 123 sound source data, 130 interface Tsu door

Claims (12)

In a communication device that transmits and receives real-time acoustic data via the Internet,
Compression encoding means for compressing and encoding real-time acoustic data including speech;
Data packet generation means for generating a data packet storing data compressed and encoded by the compression encoding means;
Control packet generating means for generating a control packet storing management information for managing at least transmission and reception of the data packet;
Transmitting means for transmitting the data packet and the control packet to the one or more other communication devices via the Internet;
Receiving means for receiving data packets and control packets from the one or more other communication devices;
Decoding and decompressing means for decoding and decompressing the compressed and encoded data stored in the received data packet;
A buffer for buffering the decoded decompressed data;
And a control unit configured to control the capacity of the buffer based on a user instruction. The call device according to claim 1, wherein the control means generates retransmission request instruction information for instructing a retransmission request of a missing data packet according to the capacity of the buffer, and stores the retransmission request instruction information in the control packet. The call device according to claim 1, wherein the control means stores at least buffer information indicating a capacity of the buffer in the control packet. The call device according to claim 3, wherein the control means controls the transmission rate of the data packet based on buffer information stored in a control packet from the other call device. The communication apparatus according to claim 1, further comprising a fluctuation absorbing buffer for buffering the received data packet, wherein the capacity of the fluctuation absorbing buffer is automatically adjusted based on a transmission rate of the received data packet. The call device according to claim 1, wherein the control means measures a transmission rate of a data packet from the other call device and notifies the user. In a call method that transmits and receives real-time acoustic data via the Internet,
A compression encoding process for compressing and encoding real-time acoustic data including speech;
A data packet generating step for generating a data packet storing the data compressed and encoded in the compression encoding step;
A control packet generation step of generating a control packet storing management information for managing at least transmission and reception of the data packet;
A transmission step of transmitting the data packet and the control packet to one or more other communication devices via the Internet;
Receiving a data packet and a control packet from the one or more other communication devices;
A decoding and decompressing step for decoding and decompressing the compressed and encoded data stored in the received data packet;
And a control step of controlling a capacity of a buffer for buffering the decoded and decompressed data based on a user instruction. 8. The call according to claim 7, further comprising: a retransmission request generation step of generating retransmission request instruction information for instructing a retransmission request of a missing data packet generated according to the capacity of the buffer and storing the information in the control packet. Method. The call method according to claim 7, further comprising a buffer information generation step of storing at least buffer information indicating a capacity of the buffer in the control packet. The call method according to claim 9, further comprising a transmission rate control step of controlling a transmission rate of the data packet based on buffer information stored in a control packet from the other call device. The call method according to claim 7, further comprising a step of measuring a transmission rate of a data packet from the other call device and notifying the user. In a call system in which two or more call devices transmit and receive real-time acoustic data via the Internet,
Each of the above communication devices
Compression encoding means for compressing and encoding real-time acoustic data including speech;
Data packet generation means for generating a data packet storing data compressed and encoded by the compression encoding means;
Control packet generating means for generating a control packet storing management information for managing at least transmission and reception of the data packet;
Transmitting means for transmitting the data packet and the control packet to the one or more other communication devices via the Internet;
Receiving means for receiving data packets and control packets from the one or more other communication devices;
Decoding and decompressing means for decoding and decompressing the compressed and encoded data stored in the received data packet;
A buffer for buffering the decoded decompressed data;
Control means for controlling the capacity of the buffer based on a user instruction,
The control means of one of the communication devices of at least two call devices stores at least buffer information indicating a capacity of the buffer in the control packet,
The control unit of the other call device controls a transmission rate of a data packet to be transmitted to the one call device based on buffer information stored in a control packet from the one call device. .

Images