Voice Over IP-Computer Sciences Applications-Project Report, Study Guides, Projects, Research of Applications of Computer Sciences

Download Voice Over IP-Computer Sciences Applications-Project Report and more Study Guides, Projects, Research Applications of Computer Sciences in PDF only on Docsity! i Table of Contents 1 INTRODUCTION ........................................................................................................... 1 1.1 VOICE OVER IP (VOIP) ............................................................................................. 1 1.1.1 VoIP Parameter ................................................................................................... 1 1.2 SPEECH COMPRESSION ............................................................................................. 1 1.3 LINEAR PREDICTIVE CODING ................................................................................... 2 1.3.1 Description of LPC .............................................................................................. 2 2 REAL TIME TRANSMISSION PROTOCOL ............................................................ 3 2.1 RTP PAYLOAD .......................................................................................................... 4 2.2 RTP HEADER ............................................................................................................. 4 2.3 RTP PACKET ............................................................................................................. 4 2.4 RTCP PACKET........................................................................................................... 4 2.5 RTP SESSION ............................................................................................................. 4 3 RTP HEADER FORMAT .............................................................................................. 5 3.1 VERSION (V) ............................................................................................................. 5 3.2 PADDING (P) ............................................................................................................. 5 3.3 EXTENSION (X) ......................................................................................................... 5 3.4 CSRC COUNT (CC) .................................................................................................. 6 3.5 MARKER (M) ............................................................................................................ 6 3.6 PAYLOAD TYPE (PT) ................................................................................................ 6 3.7 SEQUENCE NUMBER ................................................................................................. 6 3.8 TIMESTAMP ............................................................................................................... 6 3.9 SSRC ........................................................................................................................ 6 3.10 CSRC LIST ................................................................................................................ 7 4 RTP HEADER COMPRESSION .................................................................................. 7 4.1 ALGORITHM .............................................................................................................. 7 4.2 DIFFERENTIAL CODING ............................................................................................. 8 4.3 SESSION CONTEXT .................................................................................................... 9 4.4 UN-COMPRESSED HEADERS .................................................................................... 10 4.4.1 IPv4 Header ....................................................................................................... 10 4.4.2 UDP Header....................................................................................................... 11 4.4.3 RTP Header ........................................................................................................ 11 4.4.4 Payload .............................................................................................................. 11 4.5 COMPRESSED HEADER ............................................................................................ 11 4.5.1 Full header ......................................................................................................... 11 4.5.2 Compressed UDP ............................................................................................... 12 4.5.3 Compressed RTP ................................................................................................ 12 docsity.com ii 4.5.4 Context state ....................................................................................................... 13 5 PROJECT SCHEDULE ............................................................................................... 15 5.1 PROJECT TASKS ...................................................................................................... 15 5.1.1 Task 1 ................................................................................................................. 15 5.1.2 Task 2 ................................................................................................................. 15 5.1.3 Task 3 ................................................................................................................. 15 5.1.4 Task 4 ................................................................................................................. 15 5.1.5 Task 5 ................................................................................................................. 15 5.1.6 Task 6 ................................................................................................................. 15 5.1.7 Task 7 ................................................................................................................. 15 5.1.8 Task 8 ................................................................................................................. 16 docsity.com 1 1 Introduction This document is based on RTP header compression. RTP is related to real time data communication such as in VoIP. A brief description of VoIP along with the RTP header compression details is given below. The RTP header compression is basically the coding part of the project. The present document lists the basic concept of the compression part. 1.1 Voice over IP (VoIP) VoIP (voice over IP - that is, voice delivered using the Internet Protocol) is a term used in IP telephony for a set of facilities for managing the delivery of voice information using the Internet Protocol (IP). 1.1.1 VoIP Parameter As the IP network was primarily designed to carry data, it does not provide real-time guarantees but only provides best effort service, which is inadequate for voice communication. The major issues governing transfer of a voice stream over the Internet or using Internet protocols are listed below.  Bandwidth  Mean Opinion Score  Delay 1. Serialization delay 2. End-to-End delay  Jitter  Echo Cancellation  Reliability  Interoperability  Security 1.2 Speech Compression Speech compression is concerned with obtaining compact digital representation of voice signals to reach more efficient transmission or smaller data size. The objective is to represent speech signal with minimum number of bits yet maintain the perceptual docsity.com 2 quality. Therefore, this involves sampling and quantization. The advantages with coded speech signals are: 1. Lower sensitivity to channel noise. 2. Easier to error-protect, encrypt, multiplex and packetize. 3. Efficient transmission over bandwidth constrained channels due to lower bit rate. 1.3 Linear Predictive Coding Linear Predictive Coding is a method of predicting a sample of a speech signal based on several previous samples. The method of looking at speech as two parts which can be separated is known as the Source Filter Model of Speech. 1.3.1 Description of LPC LPC technique will be utilized in order to analyze and synthesize speech signals. This method is used to successfully estimate basic speech parameters like pitch, formants and spectra. A block diagram of an LPC vocoder can be seen in Figure-3. The principle behind the use of LPC is to minimize the sum of the squared differences between the original speech signal and the estimated speech signal over a finite duration. This could be used to give a unique set of predictor coefficients. These predictor coefficients are normally estimated every frame, which is normally 20 ms long. The predictor coefficients are represented by ak. Another important parameter is the gain (G) [1]. Figure 1: Block diagram of LPC vocoder The transfer function of the time-varying digital filter is given by: docsity.com 3    kz k a G zH 1 )( 1.3.1.1 LPC Analysis Phase The LPC analysis of each frame also involves the decision-making process of concluding if a sound is voiced or unvoiced. If a sound is decided to be voiced, an impulse train is used to represent it, with nonzero taps occurring every pitch period. A pitch-detecting algorithm is employed to determine the correct pitch period / frequency. We used the autocorrelation function to estimate the pitch period. However, if the frame is unvoiced, then white noise is used to represent it and a pitch period of T=0 is transmitted. 1.3.1.1.1 Autocorrelation method Autocorrelation (correlating a signal with itself) can be used to extract a signal from noise. Since;  Random noise has a distinctive 'spike' autocorrelation function.  A sine wave has a periodic autocorrelation function  So the autocorrelation function of a noisy sine wave is a periodic function with a single spike which contains all the noise power. The separation of signal from noise using autocorrelation works because the autocorrelation function of the noise is easily distinguished from that of the signal. 2 Real time transmission protocol RTP which provides end-to-end delivery services for data with real-time characteristics, such as interactive audio and video. Those services include payload type identification, sequence numbering, time stamping and delivery monitoring. Applications typically run RTP on top of UDP to make use of its multiplexing and checksum services [1]. RTP does not provide any mechanism to ensure timely delivery or provide other quality-of-service guarantees, but relies on lower-layer services to do so. It does not guarantee delivery or prevent out-of-order delivery, nor does it assume that the underlying network is reliable and delivers packets in sequence. The sequence numbers included in RTP allow the receiver to reconstruct the sender's packet sequence, but sequence numbers might also be used to determine the proper location of a packet. To guarantee the delivery the data transport is docsity.com 6 3.4 CSRC Count (CC) It takes 4 bits. The CSRC count contains the number of CSRC identifiers that follow the fixed header. 3.5 Marker (M) It takes 1 bit. The interpretation of the marker is defined by a profile. It is intended to allow significant events such as frame boundaries to be marked in the packet stream. 3.6 Payload Type (PT) It takes 7 bits. This field identifies the format of the RTP payload and determines its interpretation by the application. A profile specifies a default static mapping of payload type codes to payload formats. 3.7 Sequence Number It takes 16 bits. The sequence number increments by one for each RTP data packet sent, and may be used by the receiver to detect packet loss and to restore packet sequence. The initial value of the sequence number is chosen randomly for security reasons. 3.8 Timestamp It takes 32 bits. The timestamp reflects the sampling instant of the first octet in the RTP data packet. The sampling instant is derived from a clock that increments monotonically and linearly in time. The resolution of the clock must be sufficient for the desired synchronization accuracy and for measuring packet arrival jitter. The clock frequency is dependent on the format of data carried as payload and is specified statically in the profile or payload format specification that defines the format, or may be specified dynamically for payload formats defined through non-RTP means. If RTP packets are generated periodically, the nominal sampling instant as determined from the sampling clock is used, not a reading of the system clock. The initial value of the timestamp is random. 3.9 SSRC It takes 32 bits. The SSRC field identifies the synchronization source. This identifier is chosen randomly, with the intent that no two synchronization sources within the same RTP session will have the same SSRC identifier. docsity.com 7 3.10 CSRC List It contains 0 to 15 items, 32 bits each. The CSRC list identifies the contributing sources for the payload contained in this packet. The number of identifiers is given by the CC field. CSRC identifiers are inserted by mixers, using the SSRC identifiers of contributing sources [3]. 4 RTP Header Compression In recent years voice-over-IP and other streaming media applications in the Internet has grown at a phenomenal rate. As such services become more widely deployed the limitations of best-effort IP transport are becoming apparent, and it is clearly necessary to provide these media streams with some protection from the worst effects of packet loss. 4.1 Algorithm The compression algorithm defined in this document draws heavily upon the design of TCP/IP header compression. The design of this algorithm is based on a combined TCP/IP header compression scheme, which reduces the number of bits in the headers by exploiting the fact that for the duration of the connection, half the bytes in the headers remain unchanged. The remaining compression is then achieved by differential encoding of the changing fields between headers of successive packets. In the CRTP scheme, a further gain is achieved from the fact that the difference of several fields between successive packets is constant, thereby representing a second- order difference of zero. This means that the transmitter need only transmit an initial uncompressed header and first order differences, followed by indications of which fields in subsequent packets have zero second-order differences. The de-compressor must therefore maintain a context consisting of the most recent uncompressed header received, which it combines with each received compressed RTP/UDP/IP header to reconstruct the original headers. For RTP header compression, some of the same techniques may be applied with some extension. However, the big gain comes from the fact that although several fields change in every packet, the difference from packet to packet is often constant and, therefore, the second-order difference is zero. By noting this and passing the first docsity.com 8 order difference with first packet, the fields may also be ignored in subsequent packets. By maintaining both the uncompressed header and the first order differences in the session state shared between the compressor and the de-compressor, all that must be communicated is an indication that the second-order difference was zero. In that case, the de-compressor can reconstruct the original header without any loss of information, simply by adding the first-order differences to the saved, uncompressed header as each compressed packet is received. Just as TCP/IP header compression maintains shared state for multiple, simultaneous TCP connections, this IP/UDP/RTP compression must maintain state for multiple session contexts. 4.2 Differential coding The basic idea of differential coding algorithm is taken from the TCP/IP compression scheme which is described as: TCP/IP datagram header consists of 40 bytes: 20 bytes of IP and 20 of TCP. Unfortunately, since the TCP and IP protocols were not designed by a committee, all these header fields serve some useful purpose and it's not possible to simply omit some in the name of efficiency. However, TCP establishes connections and, typically, tens or hundreds of packets are exchanged on each connection. How much of the per- packet information is likely to stay constant over the life of a connection? So, if the sender and receiver keep track of active connections and the receiver keeps a copy of the header from the last packet it saw from each connection, the sender gets a factor- of-two compression by sending only a small connection identifier together with the 20 bytes that change and letting the receiver fill in the 20 fixed bytes from the saved header. One can scavenge a few more bytes by noting that any reasonable link-level framing protocol will tell the receiver the length of a received message so total length (bytes 2 and 3) is redundant. But then the header checksum (bytes 10 and 11), which protects individual hops from processing a corrupted IP header, is essentially the only part of the IP header being sent. It seems rather silly to protect the transmission of information that isn't being transmitted. So, the receiver can check the header checksum when the header is actually sent (i.e., in an uncompressed datagram) but, for compressed datagrams, regenerate it locally at the same time the rest of the IP header is being regenerated. This leaves 16 bytes of header information to send. All of these bytes are likely to change over the life of the conversation but they do not all docsity.com 11 transmitted. The packet ID usually increments by one or a small number for each packet. 4.4.2 UDP Header In the UDP header, the length field is redundant with the IP total length field and the length indicated by the link layer. The UDP check-sum field will be a constant zero if the source elects not to generate UDP checksums. Otherwise, the checksum must be communicated intact in order to preserve the loss-less compression. 4.4.3 RTP Header In the RTP header, the SSRC identifier is constant in a given context since that is part of what identifies the particular context. For most packets, only the sequence number and the timestamp will change from packet to packet. If packets are not lost or disordered upstream from the compressor, the sequence number will increment by one for each packet. 4.4.4 Payload In most of audio and video packets the second-order difference of the sequence number and timestamp fields is zero, so the next packet header can be constructed from the previous packet header by adding the first-order differences for these fields that are stored in the session context along with the previous uncompressed header. When the second-order difference is not zero, the magnitude of the change is usually much smaller than the full number of bits in the field, so the size can be reduced by encoding the new first-order difference and transmitting it rather than the absolute value. 4.5 Compressed Header In order to communicate packets in the various compressed forms, this protocol depends upon the link layer being able to provide an indication of four new packet formats in addition to the normal IPv4 packet formats. The following are the headers in compressed forms. 4.5.1 Full header It communicates the uncompressed IP header plus any following headers and data to establish the uncompressed header state in the de-compressor for a particular context. The full header packet also carries the 8- or 16-bit session context identifier and the 4- docsity.com 12 it sequence number to establish synchronization between the compressor and de- compressor. 4.5.2 Compressed UDP It communicates the IP and UDP headers compressed to 6 or fewer bytes which is often 2 if UDP checksums are disabled, followed by any subsequent headers possibly RTP in uncompressed form, plus data. This packet type is used when there are differences in the usually constant fields of the RTP header. The RTP header includes a potentially changed value of the SSRC field, so this packet may redefine the session context. The format is shown below. Figure 4: Format of compressed UDP 4.5.3 Compressed RTP It indicates that the RTP header is compressed along with the IP and UDP headers. The size of this header may still be just two bytes or more if differences must be communicated. This packet type is used when the second-order difference (at least in the usually constant fields) is zero. It includes delta encoding for those fields that have changed by other than the expected amount to establish the first-order differences after an uncompressed RTP header is sent and whenever they change. The format is shown below. docsity.com 13 Figure 5: Format of compressed RTP 4.5.4 Context state It indicates a special packet sent from the de-compressor to the compressor to communicate a list of context IDs for which synchronization has or may have been lost. This packet is only sent across the point-to-point link so it requires no IP header. The format is shown below [6]. docsity.com 16 5.1.8 Task 8 The last task is measuring the transmission time over various networks. And finally the out come of the project. Figure 7: Project Time Line docsity.com 17 References [1] Study of LPC Speech http://www.student.chula.ac.th/~47704705/index.html [2] Casner S., and Jacobson V., RTP: A Transport Protocol for Real-Time Applications, RFC 1889, January 1996 http://www.faqs.org/rfcs/rfc1889.html [3] Anand Muthukrishnan, “RTP Header Format”, 2003-03-10 http://networks.ecse.rpi.edu/~anand/voip/reports/3stage/html/node52.html [4] Jacobson V., “Compressing TCP/IP Headers for Low-Speed Serial Links Serial Links”, RFC 1144, February 1990. http://www.faqs.org/rfcs/rfc1144.html [5] Helpdesk PC-Data-Support, “VOIP Bandwidth Consumption”, 29.3.2001 https://pbxweb.aastra.com/extra/support/attachments/KnowledgeBase/00874/au20 00020_en_a0.pdf [6] Casner S., and Jacobson V., Compressing IP/UDP/RTP Headers for Low-Speed Serial Links, RFC 2508, February 1999 http://www.faqs.org/rfcs/rfc2508.html docsity.com