Using the Packet Header Redundant Fields to Improve VoIP Bandwidth Utilization

—Timeworn telecommunication are progressively being substituted by a new one that run over IP networks, which is recognized as voice over internet protocol (VoIP). VoIP has a number of qualities (e.g., inexpensive call rate), which make it progressively widespread in the telecommunication domain. However, VoIP faces plentiful obstacles that slow its growth. One of the major obstacles is poorly utilizing the network bandwidth. A number of techniques have been offered to handle this obstacle, including packet multiplexing techniques. This paper designs an original multiplexing techniques, called packet multiplexing and carrier header (PM-CH), to decrease the quantity of the bandwidth consumed by VoIP. PM-CH protect the bandwidth by multiplexing the packets in a header and using the Timestamp field in the RTP header. The achievement of the PM-CH technique was examined depends on connection capacity and payload shortening. Simulation outcomes show that the PM-CH technique outperforms the contrast technique in the two factors. For instance, the PM-CH technique’s connection capacity outperforms the comparable technique by 58.9% when the connection bandwidth is 1000 kbps. Consequently, the PM-CH technique attains its objective of reducing the unexploited bandwidth caused by VoIP.


I. INTRODUCTION
The telecommunication sector has developed considerably. One of the latest and best development is carrying the voice data over IP networks, known as voice over IP (VoIP). VoIP technology is not projected for just the large companies, but small companies and start-ups are also utilizing it. Rather than paying for several telephone connections, VoIP users are only paying for Internet connections. This is because VoIP converts the voice data into digital and transfers it in forms of IP packets that can share the Internet connection. Beside, VoIP calls can be made from any smartphone, which enhances the productivity of its users [1,2,3,4]. Accordingly, the decision that should be taken by most organizations is not if they will adopt VoIP but when. Nevertheless, one obstacle that VoIP faces is the unstable call quality, which mainly depends on the load on the network. The other important obstacle is that VoIP poorly utilizes the network bandwidth. The reason behind that is the considerable size of the header that comes in front of the very small digital voice segments [2,5,6].
The header, which is used with the digital voice segments, contains the 20 bytes IP, 8 bytes UDP, and the 12 bytes RTP protocols. These 40 bytes (RTP/UDP/IP) come in front of the 10 to 30 bytes voice segments. The size of the voice segment is based on the type of the codec. Table I displays some of the common codecs. Assuming 10 bytes voice segment, then the packet header will consume 80% of the available bandwidth. Thus, a huge waste of IP network bandwidth [1,7,8]. Various range of multimedia applicant uses RTP to transfer their data. These applications include voice calls between only two ends, voice calls between multiends (more than two), video meetings, TV media, video broadcasting over the Internet, and … etc. As for UDP, it is used for realtime applications (e.g. multimedia applicants) and many other applications that require less reliable delivery. Finally, the IP protocol is used with all kinds of applications. Consequently, the UDP and IP protocols contain many fields that are superfluous for multimedia applicants. When it comes to the voice call between two ends even the RTP protocol has some superfluous fields. These fields are transferred via the network and consume a portion of the bandwidth with no valuable use for the voice calls between only two ends, which is our concern [9, 10, 11]. The VoIP developers have proposed some approaches to reduce the wasted bandwidth from the large header and the superfluous fields. One of the first approaches is reducing the size of the header by compress it. The compression mechanism is based on some basic properties of the header. These properties have been utilized to compress the 40 bytes RTP/UDP/IP to only 2 bytes. Another main approach is VoIP packet multiplexing. The packet multiplexing approach groups several packets and adds a single header to them, instead of adding a single header to each packet. The packet multiplexing approach has greatly saved the bandwidth, based on the number of grouped packets. Some other VoIP developers have created the 4 bytes IAX protocol to carry the voice data instead of the 12 bytes RTP protocol. This also has saved the network bandwidth to some extent [7,12,13]. For instance, assuming 10 bytes voice segment, then the packet header, when using 32 bytes IAX/UDP/IP, will consume 64% of the available bandwidth. Therefore, 16% of the wasted bandwidth is saved when using the IAX protocol instead of the 12 bytes RTP protocol.
In this paper, a new method will be designed under the packet multiplexing approach. Figure 1 presents the packet multiplexing approach. The VoIP gateway of LAN1 and LAN2 is the place in which the proposed method will be deployed. This is because it represents a gathering point for the VoIP packets. The sender gateway (e.g. LAN1 gateway) multiplexes the packets and the receiver gateway (e.g. LAN2 gateway) de-multiplexes the grouped packets. The designed method will be implemented at the transport layer; several packets will be grouped in one UDP/IP header while keeping the RTP header of each packet. In addition, the designed method will use the superfluous fields of the RTP header to carry all or portion of the voice segment of a packet. Moreover, dissimilar the current aggregation techniques, the proposed method adds no further header to the layout of the VoIP packets. That is, the suggested technique benefits from the redundant fields to accomplish aggregation/segregation. Henceforth, the expression multiplexed packet (M-pkt) will be used to denote several VoIP packets grouped in UDP/IP header. The term original packet (O-pkt) will be used to refer to the packet before multiplexing or after de-multiplexing. Figure 1 illustrates M-pkt and O-pkt.  The article is arranged as follows: Section II deliberates the bandwidth utilization approaches, specifically the multiplexing methods. Section III deliberates a detailed comprehensive look into the proposed design. Section IV deliberates the result of the executed simulations to validate the proposed method. Finally, we conclude in Section V.

II. RELATED WORK
This section discusses the key multiplexing techniques associated with the current work. One of the fundamental multiplexing techniques introduced by Hoshi et al [14]. In this technique i) the gateway at the caller end accumulates several packets in one Mpkt, and ii) it was intended for application with the PSTN/PBX systems and in cellular access systems that are related to VoIP gateways. The technique introduced by Hoshi et al. performs the aggregation at the transport layer (UDP header), rather than the network layer. Therefore, the several packet's voice data along with an RTP header are aggregated in one UDP/IP header. This eliminates the need for positioning a runt header ahead of each packet's voice data. The assessment of the presented technique exhibits that the wasted bandwidth has been saved by 40% when using G.723.l Codec.
More recently, another multiplexing technique (Delta-Multiplexing [D-Mux]) was designed, to make the best use of the specified bandwidth [15]. Unlike the above technique, this technique lessens the lavished bandwidth consequential from i) the preamble of the packet and ii) the voice payload. The bandwidth of the preamble is reduced by accumulating many packets in one preamble. While the bandwidth of voice payload is lessened by calculating and transferring only the difference between the subsequent payload of the packets. The D-Mux put 2-byte header in front of the RTP header before accumulating the packets in one M-pkt. This to facilitate the de-multiplexing process at the callee side. The examination of the D-Mux technique proved that it reduces the consumed bandwidth by 72% with certain codecs.
Roay [16] designed and patented a robust multiplexing technique. The important foundation of the designed technique is comparable to that of the former techniques in which many VoIP packets are accumulated in one M-pkt. The Roay technique carries out the multiplexing at the network layer in which an RTP/UDP preamble is placed to each payload and then one IP preamble is placed to the complete M-pkt. The caller gateway needs to check the capability of the callee gateway to handle the Mpkt. If so, the caller gateway puts a multiplexing flag to the first M-pkt to inform the callee if the expected packet is a M-pkt or the customary O-pkt packet. If M-pkt, it is de-multiplexed to create the O-pkt packet. Otherwise, the expected packet is tackled as a standard O-pkt packet. Visibly, 20 bytes of the IP header is conserved for each multiplexed packet within the M-pkt packet.
The above multiplexing techniques cut the bandwidth share by accumulating several packets in a preamble at the different layers. However, neither of them investigates the extra fields in the header. This paper introduces a technique of reducing the apportioned bandwidth, namely, packet multiplexing and carrier header (PM-CH). As the name indicates, the PM-CH technique accumulates the packets in one header and investigates the extra fields in the header to carry the packet data. Additionally, unlike the present multiplexing techniques, the designed technique puts no extra preamble to the packets because the technique uses the preamble fields to extract and re-create the O-pkt packet. The following section explains the PM-CH technique in great detail.

III. PM-CH METHOD
The essential objective of the suggested PM-CH method is to maintain the bandwidth of the IP networks when conveying VoIP traffic from one end to another. The PM-CH method accomplishes this objective by accumulating VoIP packets and utilizing the repetitive fields in the packet preamble. For packet accumulation to show the leading performance, it ought to be adopted in a system with a lot of VoIP packets. Figure 2 presents a network diagram for a proposed (X) organization. The X organization has four branches, as shown in Figure 2. The users in the organization are using IP phones to make calls among the branches. The call traffic passes through the network gateway to the other branches. Thus, this gateway could be an appropriate location for installing the PM-CH method because a sizable volume of VoIP traffic passes through it. The PM-CH method contains a module installed at the caller (sender) gateway, called PM-CHs, and another installed at the callee (receiver) gateway, called PM-CHr. PM-CHs executes two primary tasks: multiplexing the packets and reposition part of the payload in the packet's preamble. PM-CHr executes two primary tasks: de-multiplexing the M-pkt packets and reposition the payload in the packet's preamble as a normal payload. Sections III-B and III-C explain the PM-CHs and PM-CHr modules, respectively. Figure 3 shows the position of the PM-CHs and PM-CHr modules.

A. Timestamp Field
Besides packet multiplexing, the PM-CH technique uses the Timestamp in the RTP protocol to protect the apportioned bandwidth to the VoIP application. The PM-CH technique achieves that by keeping part of the packet payload in the Timestamp. Then, the original value of the Timestamp can be derived from the Sequence-number field of the RTP header at the PM-CHr module. The Timestamp and Sequence-number fields are augmented by constant values for a series of packets [7,8,17]. For instance, assume the Sequence-number a series of packets is 2, 4, 6, 8 and, 10. For the same series of packets, the Timestamp is 6, 11, 16, 21, and 26. Accordingly, the Timestamp can be inferred from its corresponding Sequence-number based on the numerical conjunction of the Timestamp and Sequence-number fields. The values of the Timestamp and Sequence-number of only the first packet of a call ought to be kept by the PM-CHr module. The destination socket (D.Sck) alongside the difference (De) between the Timestamp and Sequence-number fields are kept by the PM-CHr module, as shown in Table II

B. PM-CHs Module
The PM-CHs module make specific tasks to protect the bandwidth apportioned for the VoIP applications. Task 1: the voice payload extracted from the VoIP packet. Task2: 4 bytes of the voice payload are kept in the Timestamp field of the RTP header. This creates a runt voice data (Rvd). Task 3: an identifier (ID) is assigned for a call and kept in a table (ID Table). The need for this ID is presented in Section III-D. Task 4: The RTP header is attached to the Rvd payload, which makes a runt packet (Rpkt). Task 5: The Rpkts are accumulated in an UDP/IP header, which makes the M-pkt. The number of Rpkts accumulated within the M-pkt is decided based on certain variables, as clarified in Section III.E. Task 6: The value of the SSRC of RTP and its corresponding destination socket is kept in the ID Table at both PM-CHs and PM-CHr modules. Task 7: The M-pkt is transferred to the callee side. Figure 4 presents the PA-CHs module tasks.

M-pkt
Reserve a Unique Call ID  Table  The PM-CHr module ought to reestablish the O-pkt including its D.Sck. The PM-CHr module utilizes the SSRC field in the RTP header. The SSRC is selected arbitrarily to distinguish the synchronization source [8,17]. The PM-CHe module excerpts the values of the SSRC and D.Sck fields at the beginning of the call (first packet) and keeps them in the ID table at both PM-CHe and PM-CHr modules. The PM-CHr module matches the SSRC value of the Rpkt with the SSRC values in the ID table and reestablishes the O-pkt UDP/IP header appropriately. The PM-CHe module ought to be arranged for SSRC collision among diverse calls. This is achieved by keep incrementing the SSRC value by one until the collision is solved. Table III presents the ID table at the PM-CHs and PM-CHe modules. In addition, Table III presents that the ID table keeps the size of the payload throughout the call arrangement. This value is then applied by the PM-CHr module to calculate the value of the length field of the UDP protocol and the value of the total length field of the IP protocol.

E. M-pkt Size
The PM-CH technique protects the network bandwidth by packet multiplexing and the use of the Timestamp field. Clearly, the larger the M-pkt packet is, the better the bandwidth is protected [2,18,19]. However, the PM-CH technique ought to compromise between the length of the M-pkt packet and the forced delay to maintain a good call quality or protect the bandwidth. The multiplexing period and the M-pkt packet differ depends on the scenario and the environment's nature.

IV. PERFORMANCE ANALYSIS
The PM-CH technique was mimicked to examine the bandwidth exploitation enhancement in contrast with the conventional method (no multiplexing [No-Mux]) and Roay technique [16]. The mimicked network contains the PM-CHs (at the caller end) and PM-CHr modules (at the callee end), as explained in Sections III. The two modules are linked via a connection that represents a FIFO queue. The length of the payload for each packet is 14 because the LPC codec is supposed to be used [20]. The multiplexing time is set to 10 ms, which is comparable to numerous of the current works [8,21]. Two metrics were used to examine the success of the PM-CH technique in dropping the wasted bandwidth in contrast with the No-Mux technique. These metrics are the connection capacity and payload shortening.

A. Connection Capacity
This section discusses the connection capacity of the PM-CH technique. Ten experiments with ten dissimilar connection bandwidths (between 100 kbps and 1000 kbps) were executed on the mimicked network. Starting losing the packets by the queue means the connection is saturated. Hence, connection capacity is the number of calls just before packet losing starts. Figure 6 displays the assessment of the connection capacity of the PM-CH technique and those of the No-Mux technique and Roay technique. Conspicuously, the PM-CH method prospers in exploiting the connection capacity compared with the No-Mux technique and Roay technique. Additionally, the distinction in the connection capacity grows with the connection bandwidth. Accordingly, the bandwidth exploitation is enhanced by means of the PM-CH technique. G.26 codecs. The resulting shortening is due to moving a portion of the speech sample in the 4-byte Timestamp field. Furthermore, the shortening ratio is higher when using the G.28 codec versus the G.26 and LPC codecs. This is because the speech sample of the G.28 codec is shorter than the speech sample of the G.26 and LPC codecs. Thus, the shorter the speech sample of a codec, the more the shortening ratio.