Keywords

1 Introduction

VoIP service is known to mankind since the end of the 20th century. Initially, its purpose was to reduce the high cost of telephone calls by means of data transmission networks. However, over time it began to supplant the classic services offered by mobile phones (i.e. smartphone, pocket, etc.). At the present time, anyone can use it anywhere, anytime thanks to the popularization of access to the Internet by a number of hotspots, cheaper desktop Internet and data packets added “free of charge” to telephone services. It has a lot of advantages: low costs for registering into operator gate, benefits resulting from the use of IP (for example, restricting data transmission when subscribers “silent”) and high mobility. Furthermore, compared with traditional telephony, VoIP introduces the independence of phone operators, free calls within the operator’s network, full mobility, low cost infrastructure and possibility to send image or data at no additional cost.

With VoIP is inseparably linked the selection of appropriate codecs for data transmission. The message before send must be compressed to reduce the bandwidth needed to make a connection due to the limitations. It is the most important during VoIP calls using smartphones, where access to the internet data packet is limited and accountable, and signal coverage is not the same strong. Often in poor urban areas it is available only 2G systems. By changing the compression ratio VoIP codec it becomes possible seamless conversation even in those areas where the signal-to-noise ratio is low. Therefore, the choice of the codec is a compromise between high quality of the transmitted voice, the size of data transferred and the device computing power needed to compression. These parameters are very important when the VoIP calls are used in small mobile devices on pre-paid cards like smartphones. The most popular codecs standardized by ITU-T are G.711 in different varieties and G.726 [1]. Each of them has different operating parameters. G.711 provides the best quality of speech however, at the expense of the relatively wide bandwidth resulting from sampling frequency 8 kHz with a resolution of 8 bits per sample. While the codec G. 726 uses encoding at 16, 24 and 36 kbps at a much lower quality. Custom codecs for the purpose of this publication have been named A and B. They are described in the “concept of the research.” However, not all VoIP gateways operators provide the ability to establish voice calls using any codec despite the availability the same codecs setting in VoIP terminals. In addition not standardized packet stream may be deleted by intermediate devices while establishing VoIP call using own codec. No less important is the security of transmitted information during a VoIP call. Just like during normal conversations in analog telephony, Internet telephony, there is a risk of call interception and eavesdropping. Custom compression codec significantly increases the level of security (confidentiality) transmitted data due to the fact that its only users know the parameters. The transmission of data in VoIP can be protected using encrypted VPN tunnels (Virtual Private Network), their evolution DMVPN (Dynamic Multipoint Virtual Private Network) and additional components such as virtual Tor (The Onion Router) network [2]. An additional security mechanism, tested in this paper is codec change to not standardized format during a VoIP call so that the person eavesdropping was not able to understand the content transmitted on the basis of the encoded information. There are two mechanisms presented in Sect. 2. In Sect. 3 it will be served research environment. The survey will be described in Sect. 4, along with its detailed analysis. While in Sect. 5 will be a summary.

2 Payload Change Mechanism During a VoIP Call

The global VoIP provider gateways and intermediate devices may interfere with the content of data transferred in UDP (User Datagram Protocol)/RTP (Real-time Transport Protocol) packets. When in the PT (Payload Type) appears unknown value indicating the A or B codec there is the chance that entire data stream may be rejected and this will result in a lack of connection. One of the ways of research will be an attempt to change the standardized by the ITU-T codec on not standardized codec during the established VoIP call. This change can take place in two ways [3].

The first one uses the REINVITE VoIP message, signaling the remote site connection desire to change the format of data transmitted in the UDP/RTP stream. This method is recommended in the standards describing the VoIP signaling (RFC3261). It allows you to inform the remote site and all intermediaries in transport of data (transit) network devices, which can interfere in the transmitted UDP/RTP packets as VoIP servers, proxy servers, routers, NAT (Network Address Translation), IDS (Intrusion Detection System), IPS (Intrusion Prevention System), NAC (network access control) and NAP (Network Access Protection), firewall the purposive change the format of transmitted data.

In the second way of change the transmitted data type takes place only in a UDP/RTP layer below the application layer (VoIP signaling). Terminal equipment perform codec switch by changing the codec format transmitted in already established UDP/RTP data packets stream without any VoIP signaling messages. Signaling of codec change is performed by assigning new value to the PT field in RTP headers of data packets in the transmitted UDP/RTP stream. In this scenario, it is assumed that the devices which are parties of connection are monitoring the PT field value of RTP header of received packets and supports the case in which this value may change during a call by changing its receiver and transmitter to handle the new data format. This method allows skipping or passing transparently through some network devices acting as a transit for established VoIP session like VoIP servers, routers, NAT, some firewalls but not for checking the packet content devices such as IDS, IPS, NAC, NAP and proxies.

According to the VoIP standards like SIP and H.323 endpoints while switching codec using one of the above methods may operate only on data formats agreed during INVITE—OK—ACK call setup messaging. This introduces the risk that if the first scenario mode switching operation, using REINVITE message does not work due to the removal of these messages about non-standard data formats for transit devices the information will be also removed in the phase of a call setup messages INVITE—OK. According to VoIP standards endpoint devices can’t change the data type in the UDP/RTP stream to not agreed format during the exchange of INVITE—OK—ACK setup messaging. Such a change in the type of data in the UDP/RTP stream can be interpreted by devices such as IDS, IPS, NAC, firewalls, as an attempt to attack and the data stream will be blocked. That is the reason why not standardized codecs will be presented during call initialization.

3 Environmental Research Concept

The test system was located in the capital of Poland—Warsaw. Used VoIP gateways were localized in different countries around the world. For the selection criteria served to server activity and own server infrastructure possession by the operators.

Devices, used for the implementation of the research were software and equipment from renowned manufacturers i.e. Drytek Access Point, Cisco routers and firewalls, LANForge generates stateful network traffic and monitors packets for throughput and correctness, Hewlett Packard servers, 3Com switches, Wireshark and JPerf software.

Many VoIP providers do not have their own servers, by renting them from other VoIP providers and leasing pool accounts. It was not making sense to use them for tests because the results were being the same. The figure below (Fig. 1) illustratively shows the locations of selected gateways.

Fig. 1
figure 1

Examples of routes validating VoIP service with custom codecs

Full size image

The test system was consisted of two identical domains connected to the public network—Internet by two public, static IPv4 addresses. Private network addressing (172.168.x.0/24) differed only in the third octet (100 or 200). Each of the domains consisted of a VoIP terminal, work stations which function was monitoring network traffic and also acting as a log server at IPv4 address 172.168.x.10 and the default gateway providing NAT, DHCP and DNS in these networks which address was 172.168.x.1. Equipment used by the operators like VoIP gateways and other IP network devices act as ‘black boxes’ (their configuration, manufacturer, model, software and version are not known). This description has been given on the picture (Fig. 2).

Fig. 2
figure 2

Testbed for custom codecs

Full size image

For the research purpose there are used standard codecs like G.711 and G.726-16 k and custom payload types described as A and B codecs. The first of these codecs will offer high data compression influencing on bandwidth reduction at intelligible voice quality and low overhead information. The second one is to provide identical features but for video calls. For the research purpose in both domains there are two pseudorandom generators initiated by the same seed. This solution allows generating a specific payload, which enables the assessment of established calls parameters and distortions between source and destination (in VoIP operator network infrastructure and mediate devices) by comparing the data received with sent.

4 Research

These tests are divided into two stages—the first stage consists on selecting public VoIP providers whose servers are active and have their own server infrastructure. Then, it was made an attempt to create subscriber accounts in all of the chosen operators. If the operator make available several VoIP servers and each account can be set up independently there were undertaken such an attempt. After subscriber accounts were created for the indicated servers, an attempt to terminals registration and the trial VoIP connection between the terminals was made. All data were registered during tests for further analysis of cases, when attempting to register or call establishing was unsuccessful.

The first test concerned the establishing of VoIP calls using preferred initiator codec G.711 A-law defined by the ITU-T and IANA. Then the connection attempts were made using G.726 audio codecs, and custom payload types A and B (described in Sect. 3) using the dynamic range (Dynamic Payload Type) value for the PT field of the RTP header. The aim of the tests carried out in the first stage was to select active public VoIP operators with their own server infrastructure, then check how it is possible to establish connections that use non-standard data formats, using the infrastructure provider.

The second phase of tests were performed only on the VoIP server group selected in the first stage for which the configuration of the subscriber’s accounts were successful, VoIP terminals registered on servers as indicated VoIP users, established calls using standard (G.711 A-law) and custom (A and B) codec formats. Further research consisted in call establishing and then changes the codec during its lifetime using both methods described above of codec changing during the VoIP calls by using VoIP REINVITE message and changing the format of the data in the UDP/RTP stream and updating the PT field of the RTP header of transmitted packets. A description of each step of the test procedure is as follows:

VoIP terminals were configured for every VoIP server in order to proper register for the indicated subscriber account and use this server and credentials during call setup messaging.

  1. Test 1:

    Connection between VoIP terminals is establishing using the G.711 A-law codec, then it is used VoIP signaling REINVITE command to subsequently change codec to the G.726-16 k and then to custom A and B formats.

  2. Test 2:

    Connection between VoIP terminals is establishing using G.711 A-law codec. Next by changing the data format in the UDP/RTP packets stream and updating the PT field value of RTP header successively codec is changed to G.726-16 k and then to custom A and B formats.

  3. Test 3:

    Connection between VoIP terminals is established using a G.726 16 k codec, then codec is changed to custom A format using a REINVITE VoIP signaling message.

  4. Test 4:

    Starting from the connection status obtained in Test 3 return to the basic codec (G.726 16 k) is performed using REINVITE VoIP signaling message.

  5. Test 5:

    Connection between VoIP terminals is established using a G.726 16 k codec. Next codec is changed to custom A format using the mechanism of changing the data format in the UDP/RTP stream and updating the PT field value of the RTP header.

  6. Test 6:

    Staring from the connection status obtained in Test 5 return to the basic codec is performed by changing the data format to audio codec G.726 16 k, using the mechanism of changing the data format in the UDP/RTP stream and updating the PT field to appropriate value in RTP header.

Results of this study are presented in the following tables (Tables 1 and 2) (Fig. 3).

Table 1 Test results no. 1
Full size table
Table 2 Test results no. 2
Full size table
Fig. 3
figure 3

Test results

Full size image

Research results presented above show that the only 1/3 VoIP providers allow for connection with the use of the SIP protocol. Other VoIP gateways do not allow for account setup (8), registration (17), call establishment (16) or voice was one-way (4). Most of the VoIP gateways (20/26) is sufficiently flexible that does not investigate the structure of network traffic and VoIP signaling and does not reject packets with unknown field value shows the type of data compression codec. Method of changing the codec (by change on-the-fly payload) works for one time more than just a REINVITE. This means while changing codecs during VoIP call you can use any data compression codec depending on the prevailing network conditions.

For 26 working servers the payload change using both methods success 19 times on ITU-T codecs, and on the custom data formats (A and B codecs), 18 times using the REINVITE message and 20 times using a switching codec by changing PT field value within UDP/RTP packets. An additional mechanism to return to the previously used codec worked 15 times after using REINVITE switching and 16 times for the use of changing PT field value within UDP/RTP packets. For some gateways calls were established in different codec than declared in setup messaging G.711 or attempt to switch codec during a call resulted in loss of audibility at one or both parties of connection which indicates an incorrect handling of codec switching mechanism by the VoIP operator’s server. During the research tested codecs and switching mechanisms behave in a fully consistent and predicable manner. This demonstrates the high reliability of tested mechanisms. After conducting these tests, it can be assumed that the implementation of new codecs in the field of VoIP technology will not entail the need for changes to the signaling standards, which determine the future work direction. This research and the tested mechanisms will be served into better use of available bandwidth during VoIP calls using low bit rate connections. It will be used by subscribers of VoIP using the Internet on mobile devices running on the pre-paid card where signal coverage is varied, amount of data is limited and the amount of data transferred is important.

5 Conclusions

A study carried out on the pages of this paper was aimed to check the possibility of using custom codecs to establish VoIP call. For this purpose it was used two mechanisms for changing the codec during a call.

The first one use REINVITE VoIP message, it signals remote connection party desire to change the format of transmitted data in the UDP/RTP stream. The second one changes the value of the PT (Payload Type) field in the RTP headers of packets transmitted within UDP/RTP stream. Packet transmission tests with not standardized codecs with compression were conducted using the VoIP operators servers located around the world.

The results show that establishing VoIP calls using not standardized codec is possible and that the used mechanisms fulfill their functions. That can be achieved by time-continuous identification of network environment functionality. Therefore, using the available knowledge and programming tools, one of the numerous, possible to be specified, mathematical dependencies characterized by transparency was presented. It is obvious that its components can be specified for other topologies taking into account the adjustment of weights for the next network architecture tested [9].