|
1. 1 The Motivation
|
| bet | 6/32 | | Sana | 22.07.2021 | | Hajmi | 0,89 Mb. | | #15652 |
3 SYSTEM REQUIREMENTS
This section illustrates the requirements of the VoIPv6 application, so that a system can be developed which will meet each of the system aims.
The User Interface should provide all the characteristics and ease of use, offered by the interface off the traditional telephone. This is important since the VoIP application will be aimed at telephone users who have switched over to VoIP. Ideally the user interface should allow a name of a person to be entered into the application via a keypad. However until the system is fully operational and debugged it would be more sensible to have an IP address entered via a keypad similar to how a telephone number is entered into a telephone.
The User Interface shall also have the same capabilities as a standard telephone; therefore a user shall be capable of calling a number, hanging up a call, answering a call when the phone is ringing, and either passively rejecting a call by not answering, or to forcefully reject a call by selecting reject. These capabilities are crucial to the application, since with out these the application would not imitate a standard telephone, consequently user would not use the application in favour of there telephones, due to lack of functionality the offer or simply the user feels uncomfortable.
The delay between the voice entering the application to the voice leaving the connected application should be kept to between 150 and 200ms, this is essential for a voice conversation to take place without the participants noticing the delay. Minimising the delay is important since the smallest delay between the end to end users on a Voice over IP application can become so annoying to a user that it becomes unusable.
The application where possible should use fast and efficient code, this will reduce the execution times such that the overall delay can be kept down to a minimum. This may involve choosing the faster solution where problems encountered can be solved in a number of different ways.
The application should sample the voice using one channel at 8000 times a second and playback the voice at the same rate. This is the required sampling rate to convey human voice in an acceptable manner, without a sampling level of at least 8khz band limiting will occur where high frequencies/tones will be lost. The sampling rate must be equal on both recording and playback such that the sound being played does not sound either to fast or too slow.
The application should protect the privacy of the user at all executing stages of the system. This is important since the audio blocks are no longer being transmitted on a Private Telecommunications network, but could be transmitted across a public or un-secure private network such as the internet or a university network. Encryption should be used to protect the user’s privacy whilst the data is sent across the network, hence eavesdroppers simply can not intercept audio blocks and merely play them.
The application should have mechanisms in place to manage the occasional lost packet, in such a manner that the either the outage of the audio is avoid, or the outage is hardly noticeable to the user. This is important since the user will find the system unusable if they are constant long outages due to occasional lost packets. Outages of course will be expected if numerous consecutive packets are lost by the network, this will be out of the control of the application.
The system should be considerate to other users on the network; data sent across the network shall always be reduced to a minimum form where ever feasible. Reducing transmission data will involve using minimised headers where practical, and to compress the bulky audio data such that, data being sent across the network is reduced. This requirement is important since reducing the data on the network increases the available bandwidth such that the network will become less congested and as a result will drop fewer numbers of packets.
|
| |
