|
1. 1 The Motivation
|
| bet | 7/32 | | Sana | 22.07.2021 | | Hajmi | 0,89 Mb. | | #15652 |
4 DESIGN DECISIONS
The following section describes the design decisions involved during the development of the VoIPv6 application. Alternate solutions where possible are discusses for any encountered problems and the solutions are evaluated to find the optimum solution.
4.1 Problem of Data Loss during Transmission
There are a number of different approaches which could be implemented to try and cope with lost packets during transmission. Unfortunately the most intuitive solution such as using a reliable protocol such as TCP which resends packets until the packet arrives successfully is not possible due to the temporal characteristic of this real time application.
A technique which could be implemented which tries to avoid data loss, than attempt to cope with its after affects is to transmit two copies of each audio block in separate packets. One such method which implements this technique is to within each packet, transmit four consecutive high quality audio blocks with interleaved a lower quality smaller copy of the blocks sent in the previous packet. This way if one packet is lost there will be a lower quality copy of the audio within the next packet to fall back on. Diagram 2 below illustrates the packet structure.
Diagram 2, shows how lower quality audio block copies could be interleaved into packets to attempt to decrease audio outages due to lost packets.
The main advantage of this method is that when the occasional packet is lost as long as the next consecutive packet arrives then the system can utilize the lower quality copy of the data within the next incoming packet reducing the chance of an audio outage.
This method has a number of disadvantages specifically if consecutive packets are lost, then both high quality and low quality copies of the data will be lost resulting in an outages of audio where the receiving system has been starved of audio blocks to play.
Implement this method successfully requires adequate buffering of incoming packets on the receiving system, such that, audio blocks are available which can be played, whilst the application waits for the next packet to arrive with the replacement blocks within. This extra buffering adds extra delay, however it usually normal practice to have extra buffering on the receiving system as a jitter buffer, to allow the system to re-sort out of order incoming packets, so packets are not classed as lost if they simply arrive out of order.
Encoding the audio twice to create both the higher quality audio copy and the lower quality audio copy is a major disadvantage to the application since, reducing the delay caused by processing is a main requirement and this method would increase the delay cause by compression by possible twice or more.
An alternative method of coping with data loss is to try and split the possible loss over time, such that say if 100ms of sound was lost within a lost packet it would sound better to have that loss split over 400ms such that four consecutive blocks of 25 ms are not lost. This helps to maintain the flow of voice exiting the system with just small blocks missing; this can be more easily ignored by the user than longer outages which can result in having to repeat words which can break up the flow of the user’s conversation which can be very annoying.
This method has been taken from the Robust Audio Tools (RAT) within the MBONE multicasting tools developed at University College London. Sixteen audio blocks are placed into four packets in packet order rather than block chronological order, this makes sure blocks within packets are not in consecutive ordering. The order of the blocks within the packets is important since this allows for the splitting of the outage of audio due to lost packets over time. The ordering of blocks consists of placing block one within packet one, block two in packet two, block three in packet three, block four in packet four, block five in packet one and so on and so forth. Diagram 3 helps illustrate more clearly this ordering of blocks within packets.
Diagram 3, illustrates the block order within packets used within the Robust Audio Tools developed at UCL.
The main advantage of this method is that the audio outage caused by a lost packet is split over time, for example if packet two was lost although four blocks of data would have been lost it would not be four consecutive blocks. The loss of the four blocks contained within the lost packet would be spread evenly over sixteen times the size of a block, this would help make the audio loss a little less noticeable.
Ordering the blocks into the this ordering and placing them into packets can be done with very little processing required in comparison to simply placing the blocks in to the packets in chronological order, this is important since a main requirement of the application is to reduce the delay caused by processing.
Delay caused by waiting for blocks to be packed in this method is a main disadvantage. The minimum delay caused is thirteen times the length off an audio block, since the application has to wait for the thirteen audio blocks to have been recorded and processed before it can totally fill packet one and transmit the packet. However this delay can be shortened by choices audio blocks of a smaller size such as using blocks of 5ms gives a delay of 65ms which is greatly below the required maximum of 200ms although this will not be the only delay within the system.
The easiest and most efficient method to implement would be method two, using the packet structure, since this only involves reordering the audio blocks in memory as they arrive rather than having to compress and encrypt almost twice as much data. With the nature of the device the system will be running being a PDA with limited processing capacity it would be ill-advised to waste processor cycles recompressing audio blocks which may never be used by the end system receiving them.
|
| |
