New RTP Packet Payload Shrinking Method to Enhance Bandwidth Exploitation Over RTP Protocol

One of the pillars to run businesses is the telecommunications. Most of the institutions are migrating, if not already migrated, to Voice over Internet Protocol (VoIP) technology. However, VoIP still need some improvements, in terms of networks bandwidth exploitation and VoIP call quality, to meet the businesses expectations. Networks bandwidth exploitation, which is our concern in this paper, has been enhanced using different approaches and methods. This paper suggests a new method to enhance networks bandwidth exploitation Packet’s payload shrinking (compression) approach. The suggested method works with the RTP protocol and called RTP Payload Shrinking (RPS) method. As the name implies, the RPS method will reduce the size of the RTP packet payload, through shrinking it based on specific algorithm, which enhances the networks bandwidth exploitation. The RPS method utilizes the RTP fields to store the values that are needed to apply the shrinking algorithm at the sender and receiver sides. The effectiveness of the proposed RPS method has been examined in comparison to conventional RTP protocol without shrinking. The deployment result showed that the saved bandwidth ratio has reached up to nearly 17% in the tested scenarios. Therefore, enhancing the network bandwidth exploitation. Keywords—VoIP; RTP protocol; payload compression; bandwidth exploitation


I. INTRODUCTION
Telecommunication systems are critical for businesses nowadays. In the last decade, the current traditional telecommunication systems (public switched telephone network) has witnessed very high steep usage curve. This because they do not provide business with the needed features. These features include group calls, video calls, voice to text call conversion, and … etc. As an alternative, Voice over IP (VoIP) has emerged and propagated in all businesses because it supports most, if not all, the needed features [1,2]. As the name implies, unlike traditional telecommunication systems, VoIP works over IP networks and it does not need a separate installed network. This is definitely saves huge efforts of the IT departments in businesses because they are managing and maintaining one network, instead of a separate network for telecommunications and IP data [3,4]. Nevertheless, traditional telecommunication systems provide a better voice call quality than VoIP technology. This is because traditional telecommunication systems use a dedicated channel for the voice call while VoIP use shared channel over packet based networks. Therefore, VoIP packet might be delayed or lost which degrades the call quality. Apart from call quality, VoIP encounter a bandwidth efficiency utilization dilemma that needs to be dealt with and overcome [5,6].
There are three main strategies that have been followed by VoIP developer to handle this dilemma. The first one is VoIP packets concatenations, which is concatenate a number in one header instead of one header to each VoIP packet [7]. The second strategy is VoIP packet header compression, which is reduces the 40 bytes typical VoIP packet header to two or four bytes [8]. The third strategy is VoIP packet payload compression, which uses several tactics to reduce the payload size. One of the most used tactics is using a device or program, called codec, to compress the voice digital data based on some compression mechanisms [9]. Another tactic is using voice activity detection to unsend the silence of the call [10]. This paper proposes a new tactic to compress the VoIP packet payload and save the VoIP network bandwidth. The proposed tactic finds out the difference between the consecutive VoIP packets payload using certain algorithm. The proposed method does not cause any additional header to be added to the VoIP packet because it employs the existing unused VoIP packet header fields whenever needed.
There are several types of protocols that are used with VoIP technology. The IP, UDP, and RTP are typically forms the VoIP packet header. RTP is used with different media applications such as voice call, video call, multimedia conferencing, etc. Fig. 1 shows the 12-byte RTP protocol format. In case of voice call, many of RTP protocol header fields, such as the four bits contributing source (CSRC) count (CC) field, are unused and their values are zeros during the entire call. The proposed method in this paper uses this field (CC field) in its internal algorithm to achieve the payload compression and save the bandwidth. Therefore, as mentioned earlier, no additional header is added by the proposed method to the typical VoIP packet header [11,12]. 139 | P a g e www.ijacsa.thesai.org The rest of this paper is organized as follows. In Section 2, the existing VoIP bandwidth enhancement methods, which related to this work, will be discussed. In Section 3, the entities and procedures of the proposed method will be discussed. In Section 4, the proposed method will be implemented and evaluated. Finally, Section 5 concludes the paper.

II. RELATED WORKS
The dilemma of wasting the network bandwidth when using has addressed by great efforts of network researchers. To realize these efforts, this section explains some of the key method that promote the bandwidth usage by the VoIP applications.
The typical VoIP packet header contains 12 bytes RTP, 8 bytes UDP, and 20 bytes IP protocols, in total 40 bytes. Sandlund, K. et al realizes that several fields of these protocols are predetermined when start the call and not changing in all the same call packets. Therefore, these fields can be send at the beginning of the call and removed from all the call's packets. In addition, Sandlund, K. et al realizes that most of the other fields in these protocols are changing based on certain pattern. Therefore, this pattern can be calculated using certain mathematical equations. Thus, again, these fields can be removed from all the call's packets and retrieved at the receiver side using these equations. Based on these two facts, Sandlund, K. et al have managed to optimize the RTP/UDP/IP header from 40 bytes to two bytes. This method is known as RObust Header Compression (ROHC). Accordingly, when using ROHC method, the wasted bandwidth resulting from the 40 RTP/UDP/IP header has reduced by 95%, thus, very high bandwidth saving ratio [13].
Another strategy to address the dilemma of wasting the network bandwidth when using the VoIP applications is VoIP packets concatenations. Majeed, A. et al have suggested a VoIP frame concatenation method that works at the data link layer of the wireless network. The suggested method concatenates the VoIP frames in one RTP/UDP/IP/Ethernet header, rather than a standalone header to each packet, over multi-rate wireless LAN. To suit the multi-rate wireless LAN, the Majeed, A. et al based their method on two heuristics. First, the incoming VoIP frames are divided based into groups based on their transmission rate. Then, the VoIP frames within the same group only are concatenated. Second, permit the VoIP frames with a small margin of cross data rate between the VoIP frames groups to be concatenated. These heuristics have improved the number of synchronous VoIP calls by up to 200%, when using a single 802.11g Access Point, and lessens WLAN delays. Therefore, the suggested method has highly improved the bandwidth saving ratio [14].
The previous two strategies, VoIP packets concatenation and VoIP packets header compression, has been combined together in one method by Sze et al. At first, the only RTP protocol within the VoIP packet header is optimized from 12 bytes to two bytes. The new RTP protocol header is attached to a VoIP packet payload and forms a runt packet. Then, these runt packets are concatenated in one UDP/IP header at the transport layer. The proposed method works with the H.323 VoIP signaling protocol. Therefore, the process and steps that performed by H.323 to initiate the VoIP call have been modified, in order to inform the receiver about the new format of the arrived VoIP packets. The combination of the VoIP packets concatenation and VoIP packets header compression has highly improved the bandwidth saving ratio, where the results showed that the bandwidth utilization has been improved by up to 300% in the tested scenarios. [15] Similar to previous work, Abualhaj et al. have, also, combined two strategies to improve bandwidth saving ratio of VoIP applications. However, the proposed method on this work combined VoIP packets concatenation and VoIP packet payload compression. At the sender side, the incoming packet are separated into VoIP packet payload and VoIP packet header (RTP/UDP/IP). VoIP packet payload is compressed based on delta algorithm. The core idea of the delta algorithm is to find the difference of the successive VoIP packet payload to produce a small payload. After that, a new small header along with the RTP header are attached to the small payload to produce a small packet. Finally, several small packets are combined together in one UDP/IP header and the resulted packet is transmitted to its destination. At the receiver side, the opposite steps and processes are occurred to restore the original packet size and format. The evaluation result of the Delta-Multiplexing method showed that the bandwidth utilization was improved by up to 72% when using LPC Codec [16].
As mentioned earlier, one of the key strategies to lessen the network wasted bandwidth ratio caused by the VoIP applications is VoIP packet payload compression. In 2020, one of the key VoIP packet payload compression methods, called voice frame pruning (VFP), was proposed. The main idea of the proposed VFP method is to eradicate group of bits from the head or tail of the VoIP packet payload based on specific pruning algorithm. The pruning algorithm counts the bits (ones or zeros) at the head or tail of the VoIP packet payload and eradicate the higher number of bits. The VFP method make use of the unused fields of the RTP header to indicate the location and number of the eradicated bits. The receiver side restore the VoIP packet payload to its original size based on the value in these fields. Though it's simple, the proposed VFP method achieved a considerable bandwidth saving ratio by up to eight percent in the tested cases [11]. This paper proposes a novel payload compression method to improve bandwidth utilization over RTP protocol. Unlike the discussed payload compression methods, the proposed method focuses only on compact the voice frame without aggregation. In addition, no additional header is needed to restore the original size of the voice frame, because the proposed method reemploys and utilizes the current CC field of the RTP protocol header. The proposed method is called RTP Payload Shrinking (RPS). The details of the RPS method is discussed in the next section.

III. THE PROPOSED RPS METHOD
This section shows the detailed process of the proposed RPS method. RPS method is designed to handle the poor network bandwidth exploitation of the VoIP technology. As the name implies, the RPS method will achieve this by reducing the size of the RTP packet payload through 140 | P a g e www.ijacsa.thesai.org shrinking. In general, the RPS method treats the data of the RTP payload as a numerical value. Doing so allows making mathematical calculation on the RTP payload. Based on that, the RPS method will calculate the difference of the sequences RTP payload through subtraction. Knowingly, the result of the subtraction operation produces smaller value that the minuend value. Therefore, performing subtraction on the sequences RTP payload produces a smaller payload and, thus, achieves better bandwidth exploitation. To demonstrate, denote to one RTP payload as i and the other RTP payload as j. The size of payload i is fifteen bits "111001100110101" and the size of payload j is fifteen bits "110011101001001". Then, the difference between payload i and payload j (i -j) is thirteen bits 101111101100, which is smaller than the normal payload size (110011101001001), thus improves the bandwidth exploitation. Please note that the value of payload i and j are not real and only for demonstration purpose. The real value of an RTP packet payload could reach 240 bits or even more deepening on the use Codec. Therefore, the bandwidth saving resulting from the subtraction operation is considerable. Section 3.1 and section 3.2 demonstrate the RPS method process at the sender and receiver side, respectively.

A. RPS Method Processes at Sender Side
At the sender side, the RPS method shrinks the size of the RTP packet payload by performing several processes. First, the RTP payload is dissociated from the header. Second, the difference between the RTP payloads that are following each other is found. For example, suppose the packet n payload is i, the packet n+1 payload is j, and the result of the subtraction is k. Then, k is equal to i -j shall j less than i, otherwise, k is equal to j -i. If k is less than j, then j= k, otherwise, j= j. Third, modify the value of the Contributing Source (CSRC) Count (CC) field in the RTP header of the RTP packet header. The CC value will be used to recover the RTP payload initial format as generated by the codec at the sender side. Modifying the CC field will be discussed below. Finally, associate the new payload (new value of j) to the RTP packet header and dispatch the resulted new RTP packet to the destination. Fig. 2 demystify the internal process of the proposed RPS method at sender side.
As discussed in point three above, the CC field of the RTP header will be modified by the RPS method. The CC field of the RTP filed is only used for certain situations such as group call or video conferencing. It's unused on other situations such VoIP calls which are the concern in this paper. Therefore, the CC field can be reemployed to perform other functions [11]. The proposed RPS method will be using it to recover the initial format of RTP payload at the receiver side. The RPS method requires i) a value to indicate which of the successive RTP payloads is greater (payload i or payload j in the example above) and ii) another value to indicate whether the RTP payload has been replaced with new value (subtraction result) or remain unchanged. Accordingly, each of these two indicators have got two possibilities and, thus, two bits is required. The RPS method will employ only the leftmost two bits of the 4 bits CC field. The first leftmost bit indicates which of the successive RTP payloads is greater (payload i or payload j). The value of one indicates i is greater than j while the value of zero indicates j is greater or equal to i. The second leftmost bit indicates whether the RTP payload has been replaced with the subtraction result or remain unchanged. The value of one indicates that the RTP payload has been replaced with the subtraction result while the value of zero indicates that the RTP payload remain unchanged. Fig. 3 shows the subtraction algorithm (Second process) and modifying the CC fields of the RTP header (Third process).

RPS Method Processes at Receiver Side
The receiver of the VoIP call must recover the initial format of RTP payload as it produced by the codec at the sender side. This is will be achieved by the help of the CC fields values, which have been set by the RPS method algorithm at sender side. Initially, the RTP payload and the RTP packet header are split up. Then, the values of the CC field in the RTP packet header are inspected to decide the operation to be performed on the RTP payload. If the second leftmost bit of the CC field is equal to one, then no operation is performed on the RTP payload and it kept as it is. However, if the second leftmost bit of the CC field is equal to zero, then the first leftmost bit of the CC field need to be inspected. The value of zero of the leftmost bit of the CC field causes the two RTP payloads, of the current RTP packet and the previous RTP packet, to be added. The value of zero of the leftmost bit of the CC field causes the RTP payload of the current RTP packet to be subtracted from the RTP payload of the previous RTP packet. Performing any of the last two operations will produce the initial format of RTP payload of the current RTP packet. Before the final step, the CC field values must be erased (set to zero) to avoid any misinterpretation by the receiver. Fig. 4 shows the restoring operation of the RTP payload. Finally, reattach the resulted RTP payload to the RTP packet header. Fig. 5 demystify the internal process of the proposed RPS method at receiver side. Payload-Size= J + I 10 else if (FLC is equal to 1) 11

IV. RPS METHOD RESULTS AND PERFORMANCE EVALUATION
In this section, the effectiveness of the proposed RPS method will be estimated. The proposed RPS method intended to provide a better consuming of the network bandwidth when the VoIP applications are running. The three measures that are going to be used to estimate the proposed RPS method are number of eliminated bits, saved bandwidth, and the capacity of the RTP flows running at the same time in a specific bandwidth.

A. Eliminated Bits Per RTP Payload
This subsection will show the effectiveness of the proposed RPS method by investigating the number of bits that have been removed from the RTP payload. The number of removed bits have been investigated for 5 different flows. The investigation was performed on a small sample of 7 RTP packets of each flow. The size of the RTP payload after removing the bits (P_New) was compared with the size of the RTP payload before removing the bits (P-Old). Fig. 6 shows the removed bits of RTP payload when using the proposed RPS method. Clearly, the more the number of removed bits, the better the effectiveness of the proposed RPS method. Please note that the first packet of each flow was not affected, and remain with the same size, because there are no packets preceded it. However, the size of the other RTP payloads were reduced by some (different) values. These values are different from RTP payload to another depends on the bits distribution pattern within the RTP payload.

B. Saved Bandwidth
This subsection will show the effectiveness of the proposed RSP method by examining the saved bandwidth ratio. The saved bandwidth ratio was examined for seven different flows. Fig. 7 shows the saved bandwidth ratio of the proposed RPS method. The saved bandwidth ratio has been enhanced by up nearly between 12.1% and 17%. This is, to some extent, a considerable saved bandwidth ratio by the proposed RPS method, which enhances the bandwidth exploitation. The values of the saved bandwidth ratio are different from RTP flow to another because of the different in the bits distribution pattern within the RTP payload.

C. Capacity Improvement
This subsection will show the effectiveness of the proposed RPS method by examining capacity concurrent RTP flows. The capacity improvement ratio was examined with ten different flows. Fig. 8 shows the capacity improvement ratio of the proposed RPS method. The capacity improvement ratio has been enhanced by up nearly between 2.2% and 4.9%. Thus, the bandwidth exploitation is enhanced when using the proposed RPS method. Again, the values of capacity improvement ratio are different from RTP flow to another because of the different in the bits distribution pattern within the RTP payload.

V. CONCLUSION
Telecommunication system is one of the key pillars for businesses evolution. Due to its various features, VoIP technology is dominating the business telecommunication nowadays. The developers are exerting high efforts to enhance network bandwidth exploitation when using VoIP technology. This paper has contributed to these efforts by proposing a new RTP packet's payload shrinking method, called RPS that reduces the RTP packet's payload size. The RPS method's algorithm reduces the RTP packet's payload size by calculating and transmitting the different between the successive RTP packet's payloads, instead of the full RTP packet's payload. The RPS method's algorithm utilizes the RTP fields to store the values that are needed to apply the shrinking algorithm at the sender and receiver sides. The effectiveness of the proposed RPS method has been examined in comparison to conventional RTP protocol without shrinking. The deployment result showed that the saved bandwidth ratio has reached up to nearly 17% in the tested scenarios. Therefore, enhancing the network bandwidth exploitation. The future work will deploy the proposed RSP method with other network bandwidth exploitation methods, such as VoIP packets multiplexing methods.