Utilizing Voip Packet Header’s Fields to Save the Bandwidth

Abstract

Voice over IP (VoIP) is widely utilized by organizations, schools, colleges, and so on. Nevertheless, VoIP numerous challenges that hinder its spread. One of the significant challenges is the poor exploit of the VoIP technology network bandwidth (BW), caused by the huge preamble of the VoIP packet. This paper suggests a novel methodology to manage this huge preamble overhead challenge. The proposed methodology is named runt payload VoIP packet (RPV). The core principle of the RPV methodology is to reemploy and exploit the VoIP packet preamble’s data (fields) that are superfluous by VoIP technology, especially for unicast IP voice calls. Generally, those fields will be used to convey the VoIP packet payload. Consequently, diminish or zero the length of the payload and, therefore, spare the BW. The results of the investigation into the suggested RPV methodology indicated significant enhancement in the BW exploitation of VoIP technology. For instance, the saved BW in the examined environment with the LPC codec came to up to 25.9%.

An innovative approach for enhancing capacity utilization in point-to-point voice over internet protocol calls

“…However, VoIP packet merging methods cause numerous dilemmas. In general, i) VoIP call quality is deteriorating, ii) packet merging methods need a good number (a high number) of simultaneous VoIP sessions to work, and iii) the merging process might make network devices work harder because of the processing that comes from merging [1], [13], [14].…”

“…However, the packet header compacting methods cause numerous dilemmas. Generally, i) the compacting methods encompass a variety of operations and processes that affect and decrease the efficiency of the network devices, and ii) the compacting methods are undesirable in situations where multiple packets are lost, as the header values of the subsequent packets will be incorrect [1], [14], [18].…”

“…The TLen element keeps the size of the entire IP packet, equivalent to the length of the unchanged 40-byte RTP/UDP/IP header and the size of the codec voice segment. In a VoIP call, the utilized codec is determined at the outset of the P-P call and does not change throughout the whole call packet [14], [21], [22]. As a result, the D-VSC unit can maintain the size of the codec segment in the ST table.…”

“…The P-P call packet sizes are usually extremely small (less than 80 bytes). Hence, the P-P call packets are not segmented because their size is smaller than the existing layer 2 technologies' maximum transmission unit (MTU) [14], [21], [23]. Therefore, the ID element is unnecessary for P-P calls and can be deemed a buffering element.…”

“…The Prt is another unnecessary element in the IP header to move the P-P call conversation. The Prt element specifies the transport layer protocol in the packet, which is always the UDP protocol with a value of 17 in the case of P-P calls [14], [21]. As a result, the R-VSC unit can assign the Prt element the number 17 before dispatching it to the call addressee.…”