1. Introduction:-
This section introduces and explains
different things like
history, future scope and benefits of the application developed.
1.1 History
of electronic communication:- A brief history of electronic
communication.
The fundamental purpose of an electronic communication system is
to transfer information from one place to another. Thus electronic
communication can be summarized as transmission, reception, and processing of
between two or more locations using electronic circuits. The original source
information can be in analog (continuous) from such as the human voice or
music, or digital (discrete) from, such as binary-coded numbers or alphanumeric
codes. All forms of information must however be converted to electromagnetic
energy before being propagated through an electronic communication system.
Fig 1:- A simple electronic communication
model
A quick look at the development history of electronic communication
1837- Samuel Morse developed the first electronics communication system
which
uses dots, dashes, and spaces generated through electromagnetic induction
1876- Alexander Graham Bell and
Thomas A. Watson were the first to successfully transfer human conversation
over a crude metallic-wire communications system they called the Telephone (this is the focus of my
project)
1894- Guglielmo Marconi successfully
transmitted the first wireless radio signals through earth’s atmosphere
1920- Commercial radio began.
After this commercial era of electronic communication has started,
companies raced for finding a better way of communication, developing the
existing systems and inventing the new ones. As the Telephone has
revolutionized the way humans communicate with each other, the
telecommunication system under went a lot of changes, circuits switched
telephone exchanges, PSTNs, electronic exchanges were
used to provide an efficient means of communication. VoIP
is one such newly invented telephone system, which operate on different
principles exploiting the facilities provided by data networks. Before we could
thoroughly study the VoIP system we need to have an
idea of how PSTN or traditional telephone system and the data networks works together.
The PSTN Legacy Architecture
It's important to understand the architecture of the legacy
public-switched telephone network to understand the equipment, software, and
protocols involved in VoIP integration. The situation
for the next few years will be that the existing PSTN will slowly give way to a
new public packet network. In the meantime, the existing PSTN must be leveraged
because millions of users and non-IP devices are connected to it. In addition,
it supports a variety of voice services such as 800 and 900 numbers. An
Internet telephony device wanting to connect with one of these devices must use
PSTN signaling. Here are the possible Internet/PSTN interconnection scenarios:
·
Internet
user/device to PSTN user/device (packet to circuit)
·
PSTN
user/device to Internet user/device (circuit to packet)
·
PSTN
user/device to PSTN user/device across the Internet (circuit to packet to
circuit).
·
Internet
user/device to Internet user/device across the PSTN (packet to circuit to
packet)
In each of these
cases, some translation is required to convert from one signaling method to another.
In the PSTN, signals are messages sent between telephony switches to set up and
terminate calls and indicate the status of terminals involved in calls. These
signals are carried over a separate data network known as CCS (Common
Channel Signaling). The protocol used by CCS is SS7 (Signaling System 7). The
entire system is called the IN (Intelligent Network).
1.2 Introduction to VoIP:- Voice over IP (VoIP) refers to the carriage of telephone calls over the Internet, rather than the traditional public switched telephone network (PSTN) -- the copper wires and fibers that connect every house together. VoIP is used heavily by carriers (telephone companies) for their internal networks, and is gaining increasing popularity as high-speed Internet links to the home become more common. As well as being considerably cheaper than traditional phone calls (effectively free, assuming your Internet link is already paid for), VoIP allows for a variety of more sophisticated telephone services, such as video, multi-party communications (conferencing), and, well, pretty much anything you can think of. This is one of the most exciting aspects of the Internet taking over the telephone world - it takes control of the network off the existing carriers, and allows for a wide variety of people do come up with new and interesting services.1.2.1 The Benefits of Using VoIP :-
Once your phone call is being routed over the Internet, it can, in theory go anywhere. Well, anywhere that's on the Internet. This of course probably doesn't include your mother, or the friend who's walking down the street with a mobile phone. To get around this problem, many people provide gateways to the PSTN from VoIP. Most of these gateways are commercial, but they are usually much cheaper than the phone call over a landline would be. The standardisation of the VoIP protocols also mean you have a large variety of companies who can accept your business.
1.2.2
Detailed description of VoIP:-
Many people have
used a computer and a microphone to record a human voice or other sounds. The
process involves sampling the sound that is heard by the computer at a very
high rate (at least 8,000 times per second or more) and storing those
"samples" in memory or in a file on the computer. Each sample of sounds
is just a very tiny bit of the person's voice or other sound recorded by the
computer. The computer has the wherewithal to take all of those samples and
play them, so that the listener can hear what was recorded.
VoIP is based on the same idea, but the
difference is that the audio samples are not stored locally. Instead, they are sent over the IP network to
another computer and played there.
Of course, there
is much more required in order to make VoIP work. When recording the
sound samples, the computer might compress those sounds so that they require
less space and will certainly record only a limited frequency range. There are
a number of ways to compress audio, the algorithm for which is referred to as a
"compressor/de-compressor", or simply 
CODEC.
Many CODECs exist for a variety of applications
(e.g., movies and sound recordings) and, for VoIP, the CODECs
are optimized for compressing voice, which significantly reduce the bandwidth
used compared to an uncompressed audio stream. Speech CODECs
are optimized to improve spoken words at the expense of sounds outside the
frequency range of human speech. Recorded music and other sounds do not generally sound very good when
passed through a speech CODEC, but that is perfectly OK for the task at hand. Below
given are the some of the CODECs used for various purposes.
Audio codecs:-
|
Name |
standardized by |
description |
bit rate (kb/s) |
sampling rate (kHz) |
frame size (ms) |
remarks |
|
(ADPCM)
DVI |
Intel,
IMA |
ADPCM |
32 |
8 |
sample |
|
|
G.711 |
ITU-T |
Pulse
code modulation (PCM) |
64 |
8 |
sample |
mu-law (US, |
|
G.721 |
ITU-T |
Adaptive
differential pulse code modulation (ADPCM) |
32 |
8 |
sample |
Now
described in G.726; obsolete. |
|
G.722 |
ITU-T |
7 kHz
audio-coding within 64 kbit/s |
64 |
16 |
sample |
Subband-codec that divides 16 kHz band into two subbands, each coded using ADPCM |
|
G.722.1
|
ITU-T |
Coding
at 24 and 32 kbit/s for hands-free operation in
systems with low frame loss |
24/32 |
16 |
20 |
See also |
|
G.723 |
ITU-T |
Extensions
of Recommendation G.721 adaptive differential pulse code modulation to 24 and
40 kbit/s for digital circuit multiplication equipment
application |
24/40 |
8 |
sample |
Superceded
by G.726; obsolete. This is a completely different codec than G.723.1. |
|
G.723.1
|
ITU-T |
Dual
rate speech coder for multimedia communications transmitting at 5.3 and 6.3 kbit/s |
5.6/6.3 |
8 |
30 |
Part of
H.324 video conferencing. DSP Group. It encodes speech or other audio signals
in frames using linear predictive analysis-by-synthesis coding. The
excitation signal for the high rate coder is Multipulse
Maximum Likelihood Quantization (MP-MLQ) and for the low rate coder is
Algebraic-Code-Excited Linear-Prediction (ACELP). |
|
G.726 |
ITU-T |
40, 32,
24, 16 kbit/s adaptive differential pulse code
modulation (ADPCM) |
16/24/32/40 |
8 |
sample |
ADPCM;
replaces G.721 and G.723. |
|
G.727 |
ITU-T |
5-, 4-,
3- and 2-bit/sample embedded adaptive differential pulse code modulation
(ADPCM) |
var. |
? |
sample |
ADPCM.
Related to G.726. |
|
G.728 |
ITU-T |
Coding
of speech at 16 kbit/s using low-delay code excited
linear prediction |
16 |
8 |
|
CELP.
Annex J offers variable-bit rate operation for DCME. |
|
G.729 |
ITU-T |
Coding
of speech at 8 kbit/s using conjugate-structure
algebraic-code-excited linear-prediction (CS-ACELP) |
8 |
8 |
10 |
Low
delay (15 ms) |
|
GSM
06.10 |
ETSI |
RegularPulse Excitation LongTerm
Predictor (RPE-LTP) |
13 |
8 |
22.5 |
Used
for GSM cellular telephony. |
|
LPC10e
(FIPS 1015) |
US
Govt. |
Linear-predictive
codec |
2.4 |
8 |
22.5 |
10
coefficients. |
Once the sound is
recorded by the computer and compressed into very small samples, the samples
are collected together into larger chunks and placed into data packets for
transmission over the IP network. This process is referred to packetization. Generally, a single IP packet will contain
10 or more milliseconds of audio, with 20 or 30 milliseconds being most common.
Vint Cerf, who is often called the Father of the Internet, once
explained packets in a way that is very easy to understand. Paraphrasing his
description, he suggested to think of a packet as a
postcards sent via postal mail. A postcard contains just a limited amount of
information. To deliver a very long message, one must send a lot of postcards.
Of course, the post office might lose one or more postcards. One also has to
assemble the received postcards in order, so some kind of mechanism must be
used to properly order to postcards, such as placing a sequence number on the
bottom right corner. One can think of data packets in an IP network as
postcards. Just like postcards sent via the postal system, some IP data packets
get lost and the CODECs must compensate for lost
packets by "filling in the gaps" with audio that is acceptable to the
human ear. This process is referred to as packet-loss
concealment (PLC). In some cases, packets are sent multiple times in order to
overcome packet loss. This method is called, appropriately enough, redundancy.
Another method to address packet loss, known as forward-error correction (FEC),
is to include some information from previously transmitted packets in subsequent
packets. By performing mathematical operations in a particular FEC scheme, it
is possible to reconstruct a lost packet from information bits in neighboring
packets.
Packets are also
sometimes delayed, just as with the postcards sent through the post office.
This is particularly problematic for VoIP systems, as delays in delivering a voice packet
means the information is too old to play. Such old packets are simply
discarded, just as if the packet was never received. This is acceptable, as the
same PLC algorithms can smooth the audio to provide good audio quality.
Computers generally measure the packet delay and expect the delay to remain
relatively constant, though delay can increase and decrease during the course
of a conversation. Variation in delay (called jitter) is the most frustrating
for IP devices. Delay, itself, just means it takes longer for the recorded
voice spoken by the first person to be heard by the user on the far end. In
general, good networks have an end-to-end delay of less than 100ms, though
delay up to 400ms is considered acceptable (especially when using satellite
systems). Jitter can result in choppy voice or temporary glitches, so VoIP devices
must implement jitter buffer algorithms to compensate for jitter. Essentially,
this means that a certain number of packets are queued before play-out and the
queue length may be increased or decreased over time to reduce the number of
discarded, late-arriving packets or to reduce "mouth to ear" delay.
Such "adaptive jitter buffer" schemes are also used by CD recorders
and other types of devices that deal with variable delay.
Video works in
much the same way as voice. Video information received through a camera is
broken into small pieces, compressed with a CODEC, placed into small packets,
and transmitted over the IP network. This is one reason why VoIP is promising as a new
technology: adding video or other media is relatively simple. Of course, there
are certain issues that must be considered that are unique to video (e.g.,
frame refresh and much higher bandwidth requirements), but the basic principles
of VoIP
equally apply to video
telephony.
Of course there
is much more to VoIP
than just sending the audio/video packets over the Internet. There must also be
an agreed protocol for how computers find each other and how information is
exchanged in order to allow packets to ultimately flow between the
communicating devices. There must also be an agreed format (called payload
format) for the contents of the media packets. I will describe some of the
popular VoIP
protocols in the next section.
Through out this
section, I have focused on computers that communicate with each other. However,
VoIP
is certainly not limited to
desktop computers. VoIP
is implemented in a variety of hardware devices, including IP phones, analog
terminal adapters (ATAs), and gateways.
In short, a large number of devices can enable VoIP communication, some of
which allow one to use traditional telephone devices to interface with the IP
networks: one does not have to
throw out existing equipment to migrate to VoIP.
2. System Architecture Description :-
I’ve developed a software for the demonstration of VoIP.
I’ve developed it modularly paving a way to extend the application in future.
Here I’ll give a brief about the application and its architecture, like how the
modules were organized, and the function of modules. Python was used in order
to quickly build the system in less time. When compared to other languages
python is 300% more productive, It has a large set of
libraries which keeps the programmer from reinventing the wheel.
The aim of the software is to enable the user
to communicate with out registering or connecting to the server. So when we
launch the application we are ready use it for making and receiving calls, with out
having any registration or login troubles. It enables the user to make a call
just by entering the other person’s IP address. But in order to help (as
expecting the user to know other person’s IP address before hand sounds bizarre
in networks configured with DHCP) the
users a facility was given in the application where he/she can register him/her
self with a session server running on internet or on their local network, they
can also get the list of users who were already online and registered them
selves. So registering with the server enables users to call the other
registered persons easily with out knowing their IP address, just by double
clicking on the name of the user displayed in the hosts
listbox of the application.
2.1 Overview of modules:-
The
software developed is broadly divided into two modules:
·
The first module is the one running on
the client side “Client Module”
·
The other running at the server side
“Server Module”
Client Module:
This module will be concerned with the following work load:
·
The registration of the user onto the
system
·
Un-registering the user out from the
system
·
Transportation of voice packets
Server Module:
This module will undertake the following work
·
Processing the requests of the user
·
Maintaining records of the registered users
Client module is further organized
into following modules:
·
Session Module:- This module
will collect the following information from the user who wants register him
self on the server
ü
User Name
ü
Server address
This module captures the above information and sends
it to the server for authentication.
·
Voice Capture Module:- This module
will capture voice data from the user by reading from an input device like mic and provide it to the next module (voice compression
Module)
·
Voice Compression-Decompression Module: - This module
will apply compression algorithms to the captured voice. It will then pass this
compressed voice to the next module (Packet Formation and Transmission
Module)
· Packet Formation and Transmission / Reception Module: - This module will generate the packets containing voice data which will be transmitted to the server for further processing.
Server module is further organized
into following modules:
·
Request processing Module: - This module processes the requests it
receives from the online clients. In order to perform operations like
Registering/Un registering an user, or sending the
updated online hosts list to the user.
·
Maintaining logged in User Information: - This module adds all the
users, who are logged to the system, into a temporary data structure maintained
by the server.
2.2 Structure and Relationships:
The structure of the modules is explained below:
·
Each module works as a separate entity
·
Control information is transferred
between modules to achieve coherent working
Fig 2:-The structure of modules
The above figure shows the structure of
the modules. The client module is split into 4 different modules, Session
module, Audio module, CODEC module and transportation module.
Working Relationship between
modules is shown below
Fig 3:- Working relationship
of modules
2.3 User Interface Issues:-
The GUI of the application was built using Tkinter module of python, where bwidgets wrapper was used for increased functionality and for a better look and feel. In this section I’ll be explaining the ins outs of GUI of Crescendo like what it contains and how to use it. When you start the application you will be greeted by a splash screen reading ‘Godson Presents’. It stays there for a few seconds and then the actual GUI is displayed on the screen. The splash screen of the application looks like as shown in fig
Fig 4:- Splash screen of Crescendo
Fig 5:- Main GUI of the Crescendo application
The GUI of the application that user interacts most is shown above
where, this part of the application contains different things, presenting
different features to the user of Crescendo. Just as show in figure 5 the GUI
contains a menu bar with different options and a list box. The menu bar options
are used to control the functionality of the application, to set the options,
to change the look of the application. As the menu bar shows it contains four
different menu buttons named connect, call, view, and help sequentially. The
functions offered by these menu buttons is explained in the following figures.
Fig 6:- Figure displaying ‘connect’ menu options
Using connect menu a user can register him self with the location
server running on a remote machine, by providing his name and the remote server
address to the specific fields in the options menu under view menu button.
Clicking on the register button registers the user with provided name, which
makes his being added to the online hosts list who are running crescendo this
list sent to the users upon request and is displayed in the host list box that
can be seen below the menu bar.
And clicking on the un register button deletes
the user name from the online host list maintained by the location server.
The update option in the connect menu will send a request to the
location server for the updated online hosts list of the users currently
registered them selves with the location server running on a remote machine.
After receiving the online users list the list is displayed in the host list
box.
Fig 7:- Displaying the options under the call menu button
Moving on to the next menu button having the label
‘call’. This one currently offers an options
called ‘Make a call’ which can be seen in the above figure. This option enables
the user to get access to the dial pad of the crescendo application. Apart from
displaying the dial pad it has nothing much to do.
Fig 8:- Displaying the options under the view menu button
This menu button offers a number of features which allow user to change
the applications look and to set some options which are used while communicating
with location server or while making a call.
Fig 9:- Displaying the options under the help menu button
The help menu button contains the options as shown in the above figure.
These two options can be used to get information about the application.
Fig 10:- Displaying the output of the options menu
Now let us have look at the process of getting registered with the
location server and setting some options which will be used while making a
call. The above figure shows the output the of the
option named options under the menu button having the label view. In the above
dialog window displayed we have three tabs which provides access to the
different fields of the
dialog window shown. Clicking on the first tab displays
a filed where user can enter his
registration name.
Fig 11:- Displaying
entry field for location server address
Clicking on the second tab displays the entry box where user can type
the location server address, with which he wants to get registered. After
entering data at each location the user must click ok button provided under in
order the given information be considered.
Fig 12:- displaying compression technique options
Clicking on the third tab brings up the above shown screen. Where user can select a compression technique by checking the
appropriate check button.
After getting finished working with the options
dialog user can click the close button to close the dialog.
Fig 13:- Getting registered with the location server
After doing all the above explained process the user can click on the
register option in the connect menu in order register himself and to get the
latest online host list. The above screen shows one such incidence where user
has clicked the register button and the application is trying to get the online
host list.
Fig 14:- displaying the retrieved online users list
The above screen displays the online users list, in the host list box.
The names displayed in there were of those who currently registered them selves
with the location server.
Fig 15:- Getting the updated online users list
When ever the user wants to get the updated host list for that moment
he can do so by simply clicking the update option in the connect menu. When the
user clicks it, a request was sent to the location server for the online users
list, when the application receives the list a notification is displayed in the
form of dialog box as shown in figure 15.
Fig 16:- Displaying the dial pad
In order to make a call to the remote user we simply need to enter the
address of the remote user in IP format or domain name format. To do so the
user need to get the dial pad first which can simply be
displayed by clicking on “Make a call” option in the call menu. The IP
address can be directly entered in the address field provided in the dial pad
dialog or it can done by clicking appropriate buttons in the dial pad. The
address can also be a domain name of the remote machine where crescendo is
currently running. After entering the address user can simply click ok button to
call the remote user, press the cancel button to cancel the dial pad dialog.
Fig 17:-
Making call by clicking on the name online user
There is another simple way to make a call. It is just by clicking on
the name of the online user displayed in the host list box. When ever the user
selects the name of the online user it is highlighted in blue color. If the
user wants to make a call to a particular person he can simply double click the
name of that user.
Fig 18:- Out going call
In either of the above explained two ways a user can make an out going
call. In such moment the dialog box with a progress bar is shown, indicating
the user that the call is being routed. On the other side the called party was
displayed an incoming call alert dialog.
Fig 19:- Incoming call alert
When
ever there is an incoming call the user is alerted with a
in coming call alert dialog as well as an audio alert in the form of a
telephone is played on the users machine. In the incoming call alert dialog
user was given a choice whether accept a call or not. As the caller was
identified and his IP address is displayed on the incoming call alert dialog,
user can simply press appropriate button in order to accept or reject the
incoming call.
Fig 20:- Call in Progress dialog
A ‘call in progress’ dialog is displayed in two
cases whenever an outgoing is successfully routed and remote user accepted the
call. And whenever an incoming call is accepted
and the voice link is established. The call in progress dialog indicated that a
call is successfully established and user is ready to talk to the remote user.
An ‘end call’ button is given, for user to end the call that is currently in
progress. The other user is notified that the call is ended by the user.
Fig 21:- No response dialog
A no response dialog is displayed when ever remote user didn’t
responded to the incoming call alter. This simply means that the user is busy
or he is not at the machine.
Fig 22:- Call ended dialog
A call ended dialog is displayed when ever the remote user end a call in progress by clicking end call button.
Fig 23:- Iconified window
“Iconify window” option in the ‘view’ menu
will simply make the crescendo application to be displayed in a form like this
as shown above. This is often useful where user can put the Crescendo to a side
on the desktop and to continue attending his other works on computer.
Fig 24:- Hide from task bar
The above figure shows the crescendo application when the hid from task
bar option is checked in the ‘View’ menu. This is often useful in saving the
taskbar space. So that other applications have enough room to display their
titles.
Fig 25:- Stay on top
When the ‘stay on top’ option was checked in the
‘view’ menu then the application stays on top of every other window in desktop,
as shown in figure.
Fig 26:- All look changing options checked
It is some times useful to check all the look changing options provided
in the ‘view’ menu. In such a situation the application looks as shown above in
figure 26.
Fig 27:- ‘About’ dialog
box
The about dialog box can be displayed by clicking on the ‘About’ option
given under the menu button labeled ‘About’
3. Detailed Description of Components: -
3.1 Server Module:-
|
Type |
This is the total software
running on the server machine. It will contain two modules which have been
briefly described above. |
|
Purpose |
The purpose of this module is
manifold:
This
module is actually containing two subordinate modules which interact with
each other and the users to provide the service. The module acts as a single
abstraction from the user point of view and which the user thinks he is
interacting with. This module is an integration of various modules running on
the server machine. |
|
Function |
The
module performs various functions by deriving services from its various
subordinate modules. The functions provided include: ·
User Registration/Un registration. ·
Maintaining records of online registered users. ·
Sending updated hosts list to users upon request. |
|
Subordinates |
The various subordinates under
this module are as follows:
|
|
Dependencies |
This module depends on the
client module for its working. The client sends the control points to this
module which define the kind of work which needs to be carried out. The work
carried out might be anyone of the works defined in the “Function
Description” in the table. The client module sends information to the server
module specifying the kind of service desired. The server module initiates
one of its subordinate modules and waits for other clients. This module
server multiple clients at the same time and controls session information
(list of registered online users) |
|
Interfaces |
The server module has two
interfaces as follows:
|
|
Resources |
The module uses all the resources
used by individual subordinate modules |
|
Processing |
The processing of the module is
the sum of processing of each individual subordinate module |
|
Data |
--------------NA-------------- |
3.1.1 User Information Module:
|
Type |
This module is a part of the
server module. |
|
Purpose |
The purpose of this module is to
maintain information of the currently logged-in users and their addresses for
communication. |
|
Function |
The module performs the
following functions:
|
|
Subordinates |
------------NA---------------- |
|
Dependencies |
The module depends upon server
module to get the information of the users who need to be register/un
register of the system. |
|
Interfaces |
The module interacts with the server
module to add/delete valid users to/from the registered online users list. |
|
Resources |
The module uses the temporary
data structure dictionary to maintain the user groups |
|
Processing |
The module works as follows:
ü
The user key is searched in the dictionary and a pointer
to the key is returned. ü
This pointer is used to delete the user key |
|
Data |
The data structure maintained in
the module for storing information about the registered online users is a
python dictionary. Which contains the fields, key as username and value is
network address format used in python i.e. a tuple
with users IP address and port number Example data structure: {“Bob”:(“192.168.1.1”,7777), “ |
3.1.2 Request Processing Module:
|
Type |
This module is a part of the
server module. |
|
Purpose |
The purpose of this module is to
process the requests of the onlinser users. |
|
Function |
The module performs the following
functions:
|
|
Subordinates |
------------NA---------------- |
|
Dependencies |
The module depends on the
“server module” for getting the requests of the users. |
|
Interfaces |
The module interacts with the
server module to get the user requests and to parse them, or to send the
results back to the user |
|
Resources |
The module depends on the
customarily built python string |
|
Processing |
The module works as follows:
|
|
Data |
The data structure used in this module
is a python string which has the form “singnal+information” Example data structure looks
like “507{“bob”:(”192.65.23.4”,7777),” |
3.2 Client Module:-
|
Type |
This module is the program
running on each of the client machines |
|
Purpose |
The purpose of the module is
that it acts as the interface to the user for carrying out various service
from the system |
|
Function |
The module performs the following
functions:
|
|
Subordinates |
The module has the following
subordinates:
|
|
Dependencies |
The module depends on the data
supplied by the user and the control, signal received from the server
program/remote user. |
|
Interfaces |
The module interacts with the
user directly and carries out the tasks requested by him. The other interface
is the server module which responds to the data sent in by the client. |
|
Resources |
The client machine uses the
following resources:
|
|
Processing |
The processing of this module
can be understood by understanding the processing of the subordinate modules. |
|
Data |
The module makes use of online
data made available to it by the user and the server module. |
3.2.1
Session Module:-
|
Type |
This module is a part of the
client module. This is a subprogram running on the client machine. |
|
Purpose |
This module collects the user
information concerning his validity and sends them to the server |
|
Function |
The function of this module is
to act as a data supplier for the server module for authentication purposes |
|
Subordinates |
-------------NA------------ |
|
Dependencies |
-------------NA------------ |
|
Interfaces |
This module has only one user
interface and other interface as a server module. |
|
Resources |
------------NA------------ |
|
Processing |
The user information is recorded
in a structured string format and send
to the server |
|
Data |
The data structure used in this
module is a custom built python string in the for of “signal+information” Example data structure: “500bob” |
3.2.2
Audio Module:-
|
Type |
This module is a part of the
client module. This is a subprogram running on the client machine. |
|
Purpose |
The module captures/playback
voice data on the client side |
|
Function |
The module performs the
following functions:
|
|
Subordinates |
The module has the following
subordinate modules ·
CODEC module |
|
Dependencies |
It
depends on the data it receives from the remote client when the call is in
progress |
|
Interfaces |
The interface to this module is
the user who will be directly interacting with the hardware to provide real
time voice signal. This voice signal will be given to the next module. The module interacts with client
module for sending and receiving sound samples. The module will also receive
decompressed voice data from the receiving voice packets and pass them to the
system speakers to give voice signal at the output. |
|
Resources |
The module captures the voice
data through microphone and sound cards The module also makes use of the
speaker to output the voice data |
|
Processing |
The processing is done as
follows:
|
|
Data |
The data structure used is
python string which stores the digital sound |
3.2.3 Voice
Compression-Decompression Module(CODEC):-
|
Type |
This module is a part of the
client module. This is a subprogram running on the client machine. |
|
Purpose |
The purpose of this module is to
compress the captured voice so that quality sound can be reproduced with less
data being transmitted. This module helps in achieving:
|
|
Function |
The module works on the array
structure containing the voice data and apply compression algorithms to it. |
|
Subordinates |
----------------NA---------------- |
|
Dependencies |
--------------NA-------------- |
|
Interfaces |
The module has following
interfaces:
|
|
Resources |
-------------NA---------------- |
|
Processing |
The module works as follows:
|
|
Data |
The data structure referenced by
this module is the python string. |
3.2.4 Packet Formation and Transmission / Reception
Module:-
|
Type |
This module is a part of the
client module. |
|
Purpose |
The purpose of this module is to
send, receive and parse all sorts of information, like voice packets,
signaling information |
|
Function |
The packets are generated using
UDP / IP protocol. It also acts as a communication base between the local
client and remote client machines. |
|
Subordinates |
----------------NA---------------- |
|
Dependencies |
----------------NA---------------- |
|
Interfaces |
The module interacts with the
client module |
|
Resources |
-----------------NA----------------- |
|
Processing |
The module works as follows:
|
|
Data |
The data structure is the
packets formed from the socket programming in python. |
5. Design decisions and tradeoffs:-
Selecting the programming language in
order complete a project like this is a big challenge
in it self. My decision to select Python for this task at hand is supported by
a number of reasons out of a few myths. A common complaint made of python is that it
is not suitable for serious application development, and is only suitable for
scripting and prototyping tasks. This section covers the design decisions I
made during the project building, tradeoffs of those decisions and hope fully
will explain why implementing the application in python is preferably feasible.
In this process of explaining
things I’ll try to answer some questions.
Why would I choose Python for VoIP? Python's
a high-level language, with many constructs that make it extremely pleasant to
work with. In addition, the network framework provides an efficient and elegant
model for implementing network protocols.
In implementing the software
phone, a nice-to-have was that the phone would work in a cross-platform way - I
am not aware of any existing cross-platform software phones.
Why would I not choose Python for VoIP?
The primary reason would seem to be performance - VoIP
is a complex beast, with requirements for throwing around packets of audio at
some speed. It would seem from a first look that an interpreted language like Python would not be suitable for this
task.
Why Python?
There are a few obvious reasons for choosing Python for Crescendo.
It's easy to work with, and to
debug. For implementing a network protocol from scratch, Python is hard to beat.
It's cross platform - It would
work on Linux and Solaris, having it work on other platforms would be a
nice-to-have. There's a variety of UI toolkits available from Python, as well as one (Tkinter) that's cross platform. And finally, of course, Python is fun to write.
Why not Python?
The first concern I had was
whether Python would be fast
enough to handle VoIP. VoIP
is a lot of little packets flying back and forth, and with certain applications
(such as conferencing) you need to do software mixing of multiple audio samples
down to a single sample. In VoIP you need to send a
packet of audio every 20ms. This requirement was my major concern about Python's suitability for this task.
Timing and
Buffering
There are a issues you encounter
as part of implementing VoIP ( In
transmitting and receiving packets) The first is the simple trade-off of
buffering vs latency. Simply put, the more you buffer
before playing, the more robust you are in the face of a glitchy
network that delays individual packets of audio, but the more delay there is in
playing the audio. For now, Crescendo takes a simple approach of buffering after
buffering a for a little while it is sent to the audio device. And every 20ms,
a lump of audio is read from the audio device and sent to the network. While
this doesn't give the best performance in the world, it's the easiest to
implement. In practice, this is usually "good enough", but I do
intend to revisit this issue in the future.
The next issue is that VoIP requires a reliable source of audio - you need to send
the audio every 20ms. The real problem with this is that most modern computers
have a timer clock that runs at only 100Hz. This means that the resolution of
the timer is just 10ms. This has the unfortunate implication that if you miss
the 20ms clock tick (even by a single millisecond) you get a 10ms delay. This
delay is quite obvious to the listener and can render an audio stream unusable,
even if only one in 10 samples is delayed in this way. I initially assumed that
this real-time requirement would make Python
an unsuitable language for implementing VoIP – indeed.
But I tested my assumption first. I was pleasantly surprised.
Timing strategies:-
The
approach I took is to schedule a call for every 20ms, using the polling and
scheduling mechanism of GUI. This design looks to be GUI task dependent, and
heavily effects the timing, that a call is been made with in 20ms. More over it
makes the whole application to be a particular UI specific one. But merging a
python loop with the main loop of GUI seemed to be a headache and it didn’t
worked for me. If I tried to depend on python’s asyncloop
the program is exits in a bizarre manner right after receiving a single packet.
So for the moment I let the GUI event driven frame work of Tkinter
to schedule a call for every 20ms and employed buffering both at recording and
play back of audio of audio samples so that I don’t a relatively a bulk of
audio causing notable delays.
Asynchronous
network Programming:-
Although
python have some nice asynchronous modules like asyncore
and asynchat which run at with their own main loop, I
was bewildered how to implement it when GUIs main loop is already running. So
for some time I tried doing things with threads in python which again didn’t
worked. I wondered, that there is no way to stop a thread in python (currently=
python2.3), It is unpleasant if a thread is made to handle a blocking call to
socket waiting for connection or incoming data. It hurts a lot to use thread on
a socket which didn’t work as expected. So going to the relatively low level in
the context of python I used the select system call, to handle sockets
asynchronously which really made my day.
GUI:-
The use
of Tkinter is questioned even for normal applications
when compared to other UI toolkits of python like pyGTK,
pyQT, wxPython. Tkinter is blamed for it’s non
native look and feel, for it’s slow nature, and for it’s limited low level
widgets. In spite of all these asides, I found Tkinter
to be easy to work with, which has some understandable documentation around
internet. To cope with the low level widgets and look and feel problems I have
used pybwidgets a python wrapper for Bwidgets of Tcl/Tk. Which has some very advanced dialog boxes, progress bars which can
be well used in a network application to notify the progress of tasks going on
in background to the user. For example I’ve used Progress bar dialog
several times in the application to notify the users, one such situation is
when a call is in progress a Progress Dialog box with a button to end call is
displayed which perfectly suits for the situation.
Picking up pybwidgets
is also a problem as it had some contenders in the form of Tix
and Pmw. The design of bwidgets
is completely done in Tcl which needs no shared
object files or dlls to make it work, easy to
install. Tix and Pmw are
reported to have some problems with installations. Even though I need to
decipher the Tcl/Tk man pages in order to unsderstand Tix and pybwigets which is a drawback when compared to Pmw. Pybwidgets seemed to be neat
having a native look and feel for buttons and having some nice widgets just
sufficient for the moment in a manner like not more, not less.
6. Pseudo Code for the Components:-
6.1 Syntax of Python:-
The syntax of python is pretty
straight forward and easy to understand. Python has not curly braces so it’s
important that we follow the correct indention. Although it seems to be posing
some restrictions on writing code, it is indeed one of the great asset of python in making the code more readable and
maintainable
A simple
program to print hello world is as follows
Code:-
print
“hello world”
It is that
simple to write programs in python.
6.2 Code for
writing a simple GUI in Tkinter:-
from Tkinter
import*
root=Tk()
Label(root,text=’Hello
word’).pack()
root.mainloop()
The above shown code simply displays a
window with a label having the text ‘Hello, world’.
6.3 Pseudo code for audio operations:-
To record the audio data we write:
X=device.read()
Which returns X
with a python string containing audio a chunk of audio data.
In order to play back we simply
write the code like:
device.write(X)
Which plays back
the audio data the variable X contains.
The above terminology of read() and write() instructions is originated from the Unix
style of handling hardware devices. In unix
each device is treated as a file. So the read()
returns the audio data captured by the sound card in the computer and write()
instruction makes the audio to be played back by sending the audio data to the
sound card. Where ‘device’ may be considered as any usable sound card installed
on the computer. Which must be opened using open system call,
before performing any operations on sound device
6.4 Pseudo Code for
Writing Network Operations:-
socket.send(string,(host,port))
The
above code represents a datagram socket to send the string data to the remote
machine waiting at port number specified by port and having an address specified
by host variables. Port is int in type and host is a
string coatining the IP address or domain address of
the remote host.
socket.bind(7777)
string,host=socket.recv(100)
The above code
represents a datagram socket used to receive data from a remote host
represented by the address ‘host’, variable. The data received is in string
format stored in ‘string’ variable. The amount of data that can received at a
time is represented by the buffer value given in the recv() function. Usually the
address format used in python for socket programming is a list of hosts IP
address or domain address in string format and the port number given as int.
Example:-
In order to address a host with IP address 64.27.9.87
at port 6576, we simply use the following format
(’64.27.9.87’,6576)
Or if we want to connect to yahoo.com at port 80 the
address format used is as follows
(‘yahoo.com’,80)
7.
Conclusion and Scope for future work:-
4. Reuse and Relationship to other Products:-
I have designed my software modules with adequate foresight so that whatever I
implement can finally be extended and implemented later on a larger scale with
added features.
These are some of the ways in which the
software modules can be reused:
- The peer to peer audio transmission can be extended to setup a
conference between number of users in which I can use all the classes I
have designed and add additional classes.
- Along with audio transmission, video transmission can also be
enabled just by interfacing a web-cam and reading data from the video
card.
- Features like call waiting, call forwarding, call conferencing
and voice mailbox can be included with the extended design of location
server module with increased functionality which for the moment only
maintains the list of online users.
I’ve used open source language
Python, while designing the various modules of my project. Python comes as a batteries included device. Which means,
it comes with many pre built libraries, which helps us to get the work done quickly,
when compared to other languages. I have also used some third party
python libraries Here is a brief description of those libraries I used to
develop the application:
- The microphone and speaker interface module is based on an open
source code. Which is a python library called fast audio. It was primarily
based on port audio module. The fast audio is ideal for real time
applications like VoIP where it contains an
internal thread which keeps us from waiting for audio input, that is both
audio recording and audio playback can be achieved through the non
blocking calls to the audio device. So we waste no time in the audio
operations getting completed. The fast audio module is also a platform
independent one, it works both on Windows and on
Linux. But it has problems working with the Linux latest ALSA drivers,
nevertheless works well with the
- The inbuilt audioop library of python is used to achieve the audio
compression in uLaw and ADPCM. It is so simple
to use the audioop module of python,
if we provide an audio chunk in a python string format it returns the
compressed chunk of that audio in desired compression algorithm. I’ve also
used the pygsm module written by Itamar Shtull-Trauring to
achieve the GSM compression and decompression.
- For network
programming such as sending and receiving packets and building a location
server I’ve used the socket module of python, which allows us to write
network applications in matter of seconds.
My product is a tool
that can be used for voice communication (pc to pc).Also; in the near future
this tool can extended to use it as for conferencing and multicast IP lectures.
The benefits of using such product are:
- Cost reduction on long
distance and international calls can be achieved as access to Internet can
be obtained at flat rates, often at local calling rates.
- Integration of voice and
data networks provides a single infrastructure which supports all forms of
a communication and leads to:
·
-Bandwidth
Optimization.
·
-Long-term
equipment cost reduction because of the single physical network.
·
-Single
network also leads to decrement in maintenance and support costs.
- Thus, in short VoIP and thereby this product provides many services
on one single platform.
However there still are some
limitations to this project that deal with the quality of voice provided which I
am not going to address.
8. Appendecies:-
8.1 Source code
#Gui + phone module
#Copyright (c) 2005-2006 Godson
from Tkinter
import*
from bwidget
import*
import os,time
import session
global root
import socket,select
import audio
voicePort=socket.socket(socket.AF_INET,socket.SOCK_DGRAM)
voicePort.bind(('',7777))
is_readable=[voicePort]
is_writeable=[voicePort]
is_error=[voicePort]
-----------------------------code truncated-------------------
def endApp(self):
import sys
root.after_cancel(self.waitloopID)
root.destroy()
sys.exit(0)
if __name__=='__main__':
show=Tk()
show.iconify()
show.config(bg='white')
sl=Label(show,bg='white',fg='darkgreen',text='Godson Presents',font='Helvetica
30 bold')
sl.grid()
sl.update()
show.wm_state('zoomed')
show.overrideredirect(1)
show.deiconify()
show.update()
show.update_idletasks()
time.sleep(2)
show.destroy()
root=Tk(className='VoIP')
root.iconify()
path=os.path.dirname(sys.path[0])
root.iconbitmap("e:/python23/phone.ico")
root.resizable(0,0)
ui=app=GuiPart()
app.bootGUI(root)
app.sysMenu()
app.waitLoop(1)
root.deiconify()
root.mainloop()
codec module
#Copyright (c) 2005-2006 Godson
lstate=None
rstate=None
-----------------------------code truncated-------------------
Audio module:--
#Copyright (c) 2005-2006 Godson
import time,os,sys
import codec
fmt=0
-----------------------------code truncated-------------------
Session module
#Copyright (c) 2005-2006 Godson
import socket
import select
import cPickle
serverPort=socket.socket(socket.AF_INET,socket.SOCK_DGRAM)
-----------------------------code truncated-------------------
Server
#Copyright (c) 2005-2006 Godson
import socket
import cPickle
import select
import time
import sys
log=0;logf=''
client=socket.socket(socket.AF_INET,socket.SOCK_DGRAM)
-----------------------------code truncated-------------------
9. References:-
9.1
Related Articles:-
9.1.1 Articles on different issues of VoIP
http://voip-info.org
9.1.2. Shtoom – A VoIP application
written in python
9.1.3. Python
Language Tutorials and Books and Communities
9.1.3.1 Python 2.3 official
documentation
9.1.3.2 How to
think like a computer scientist
Allen Downey, Jefry Elkner,
Chris Meyers Published by Green Tea Press
9.1.3.3 Thinking
in Python by Bruce Eckel
http://www.mindview.net/Books/TIPython
9.1.3.4 The
oldest python community around
9.1.3.5 Bang Pypers- A python community located in banglore
http://groups.yahoo.com/group/bangpypers
9.1.4. Tkinter a GUI for Python
9.1.4.1 Thinking in Tkinter by Stephen Freg
9.1.4.2 An
Introduction to Tkitner by Fredrik Lundh http://effbot.org
9.1.4.3
Tkinter reference: a GUI for Python by John W.Shipman of New Mexico Tech computer center http://www.nmt.edu/tcc
9.2
Books Pertaining To the project:-
9.2.1
Computer Networks by Andrew S Tanenbaum
9.2.2
Electronic Communications systems by Wayne Tomasi