Teknillinen Korkeakoulu
Teletekniikan laboratorio
S-38.128 Teletekniikan erikoistyö
Internet Telephony Testing Network
Tekijä: Antti Romppanen 43018c
Ohjaaja: Vesa Kosonen
Jätetty: 13.12.99
II
Abbreviations
B-ISDN Broadband ISDN
ETSI European Telecommunications Standardisation Institute
GUI Graphical User Interface
IETF Internet Engineering Task Force
IP Internet Protocol
ISDN Integrated Service Digital Network
ISUP ISDN User Part
ITU-T International Telecommunications Union - Telecommunications
sector
IWF Interworking Functions
LAN Local Area Network
MTU Maximum Transfer Unit
NIC Network Interface Card
PC Personal Computer
PCM Pulse Code Modulation
PSTN Public Switched Telephone Network
RFC Request For Comments
RTCP Real-time Transport Control Protocol
RTP Real-time Transport Protocol
SIP Session Initiation Protocol
SS7 Signalling System 7
TCP Transmission Control Protocol
III
TIPHON Telecommunications and Internet Protocol Harmonisation Over
Networks
UDP User Datagram Protocol
VoIP Voice over IP
IV
Table of contents
Abbreviations _____________________________________________________ II
Table of contents _________________________________________________ IV
Abstract __________________________________________________________ V
1. Introduction ___________________________________________________1
2. Internet telephony_______________________________________________2
2.1 Drivers for Internet telephony_______________________________________ 2
2.2 Internet telephony scenarios ________________________________________ 3
2.3 Standards related to Internet telephony_______________________________ 5
2.3.1 Internet protocol _____________________________________________________ 5
2.3.2 Transmission Control Protocol __________________________________________ 5
2.3.3 User Datagram Protocol _______________________________________________ 6
2.3.4 Real-time Transport Protocol ___________________________________________ 6
2.3.5 H.323______________________________________________________________ 6
2.4 Internet telephony gateway _________________________________________ 7
3. The testing network _____________________________________________8
3.1 Requirements for the network_______________________________________ 8
3.2 Network plan_____________________________________________________ 8
3.2.1 The gateways________________________________________________________ 8
3.2.2 The IP network ______________________________________________________ 9
3.2.3 Monitoring tools _____________________________________________________ 9
3.3 Setting up the network ____________________________________________ 10
3.3.1 The gateway setup___________________________________________________ 10
3.3.2 NISTNET emulator __________________________________________________ 12
3.3.3 Monitoring tools ____________________________________________________ 14
4. Conclusion ___________________________________________________15
V
Abstract
Internet telephony is a concept that unites the telephone network and the Internet.
It requires new entities to be introduced to the networks in order to provide
interworking between packet switched Internet and circuit switched telephone
networks. These new components convert the telephone signalling and speech
circuits into IP signalling and packetised speech transfer methods.
This special study on telecommunications is a plan and an implementation
description for an Internet telephony testing network. The purpose of the network
is to provide a platform for evaluating different pieces of network equipment
including testing and monitoring equipment. The network is constructed in Nokia
laboratory premises in Helsinki.
1. Introduction
1
1. Introduction
Voice over Internet Protocol (VoIP) means transferring of voice traffic over
networks utilizing Internet Protocol (IP) as a carrier. VoIP has become a
considerable alternative for traditional telephony circuits. Some operators have
already switched from Pulse Code Modulated (PCM) circuits to transferring their
speech traffic over dedicated IP networks. This gives several advantages over
circuit switched connections - and also some disadvantages that have to be dealt
with.
Internet telephony and VoIP have to some extent existed for some years now. But
as main-stream applications they have not yet done well. VoIP has been a means
of calling cheap long distance calls with Personal Computers (PC) over the public
Internet. This has been enabled by the rapid development of the processing power
and multimedia capabilities of PCs. Voice communication over the Internet has
been accomplished with different kinds of packet telephony software. These have
utilised proprietary methods of transferring voice in IP packets, and therefore the
public success has not been met. But now the situation is different. New standards
- such as the H.323 protocol family - have enabled software producers to
implement packet telephony software that can interwork with software from other
producers. Also the introduction of new network components, like Internet
telephony gateways, have driven the technology nearer towars a normal private
user. This is mostly due to the fact that users are very accustomed to the user
interface of a telephone, and the gateways make it possible to make calls over the
Internet with telephones connected to the Public Switched Telephone Network
(PSTN).
When a new technology is introduced to consumers, there has to be a certainty
that the service platform and the services are working correctly. This study is
about planning and implementing a test network for Internet telephony. The
network will be used to gather information about the technology and to test and
evaluate different tools that can be used in verifying the services.
2. Internet telephony
2
2. Internet telephony
2.1 Drivers for Internet telephony
PSTN connections allocate 64kbit/s part of a 2Mbit/s PCM link for speech traffic.
This allocation is called a timeslot in the PCM link. The timeslot is allocated for
the speech stream for the whole duration of the connection. Therefore the link is
utilised even if there is no speech traffic at all. This is considered as waste of
bandwidth, because the 64kbit/s connection cannot be teared down and formed
again for every speech burst. If the speech was transferred as packets, there would
be no such problem. Packets can be multiplexed to the same link and therefore
when one connection is silent another one could use its link for transmitting. This
allows better utilisation of the link. With speech coding the required bandwidth
for speech in the IP network is much less than the 64 kbit/s requirement in PSTN.
That is why the 64 kbit/s link would be able to carry several connections even if
they would all transmit 100% of their time. This is one the most important drivers
for VoIP.
Another advantage lies in the harmonisation of different network technologies
onto a single platform. If IP is a common carrier for speech and data traffic, the
network management can be a simpler task. In practise, however, the new
network components introduced by Internet telephony can reduce this simplicity
advantage. IP is seen as a common convergence layer for all traffic - in some
ways similarly to Broadband Integrated Services Digital Network (B-ISDN) that
was dreamed about a few years ago.
The charging mode of Internet traffic helps in bringing more affordable services
to end-users. Internet is charged according to the duration of the connection or
according to the amount of packets exchanged. The distance that the packets are
sent to is not conclusive, which makes long distance connections very cost-
effective.
2. Internet telephony
3
2.2 Internet telephony scenarios
The major standard setting organisations in the telephone world are European
Telecommunications Standardisation Institute (ETSI) and International
Telecommunications Union - Telecommunications sector (ITU-T). ETSI has
established a project called Telecommunications and Internet Protocol
Harmonisation Over Networks (TIPHON) that has defined many things
concerning Internet telephony. Many other definitions and recommendations have
risen from the side of the Internet standardisation. The main Internet standard
setting organisation is Internet Engineering Task Force (IETF), which has many
groups that concentrate on Internet telephony issues.
TIPHON has defined five architectural scenarios for Internet telephony
connections. These are presented in Figures 1-1 - 1-4. [1]
Figure 1-1 Call over IP network
Figure 1-2 Call from PSTN to IP network and vice versa
IPIP
IPPSTN IWF
2. Internet telephony
4
Figure 1-3 Call from PSTN to PSTN over IP network
Figure 1-4 Call from IP to IP over PSTN
The IWF stands for Interworking functions. An example of these is an IP
telephony gateway that converts PSTN connections to IP mode of networking.
Another one is a gatekeeper. Gatekeeper is a component that provides
authorisation, registration and address translation services for hosts and gateways.
This study aims to implement a network that can be used for scenarios in Figures
1-1, 1-2 and 1-3. They are the most interesting ones when thinking about real
world applications for Internet telephony.
IPPSTN IWF PSTNIWF
IPPSTNIWF IWFIP
2. Internet telephony
5
2.3 Standards related to Internet telephony
This chapter is a short introduction of the standards that are related to IP
telephony. Fist the network and transmission protocols are presented and then the
interworking protocols.
2.3.1 Internet protocol
IP is defined by the Request For Comments (RFC) 791. It is designed to be used
in interconnecting networks. It defines the packet format and addressing and
supports methods for segmentation of information to provide compatibility for
networks with small Maximum Transfer Units (MTUs). IP does not provide
mechanisms to augment end-to-end data reliability, flow control, sequencing, or
other services commonly found in host-to-host protocols. IP version 4 header
contains a 32bit address space that is divided to a network part and a host identity.
The length of the network part depends on the class of the particular network. In
IP version 6 the addresses are 128 bits long. [2]
2.3.2 Transmission Control Protocol
Transmission Control Protocol (TCP) is the most well-known transport protocol
used together with IP. IP provides network level services for TCP, which takes
care of the connection setup and teardown as well as the reliability of the
transportation. [3]
TCP uses sequence numbers and acknowledging to achieve a reliable transport
system. TCP also performs some flow control operations. These and the re-
transmit system are the reasons why TCP is great for reliable transportation - but
useless for real-time traffic. In Internet telephony applications TCP can only be
used for signalling transportation. For speech transportation its flown control
methods and re-transmission do not fullfill the necessary latency requirements. [3]
2. Internet telephony
6
2.3.3 User Datagram Protocol
User Datagram Protocol (UDP) is an unreliable transport protocol, which is an
alternative for TCP. UDP does not do anything to secure the transmission - it only
provides a similar best effort datagram service as IP. This also means that UDP is
not restricted in the same way as TCP. UDP does not perform flow control, and
therefore it is better suited for transferring speech traffic. UDP does not detect any
missing or reordered packets and does not do any re-transmissions. This is
perfectly acceptable with voice traffic, because when the re-transmitted packet
would reach the destination, it would already be too late.[4]
2.3.4 Real-time Transport Protocol
Real-time Transport Protocol (RTP) is well-suited to be a supplement to UDP.
When run on top of UDP it can provide important services for applications such
as audio, video or simulation data. RTP provides information about the real-time
traffic in the form of time stamping. RTP can be modified to meet the
requirements of an application. Real-time Transport Control Protocol (RTCP) is a
supplement to RTP that provides monitoring information about RTP traffic.[5]
2.3.5 H.323
H.323 is an umbrella standard by ITU-T. Umbrella means that it references many
other standards and provides as itself only a framework for the standards’
application. H.323 defines everything that is needed for providing audiovisual
services in packet-based multimedia communication systems where service is not
guaranteed. [6]
Call control in H.323 is defined in H.225.0. This standard defines signalling very
close to Q.931 signalling used in Integrated Services Digital Network (ISDN).
H.245 is protocol for negotiating the applicable speech codecs and other
parameters between the H.323 nodes. H.248 is a protocol that can be used to
control an external media gateway. This allows the separation of signalling and
speech media. H.323 defines also many other things, such as the speech and video
codecs and data transfer methods. [6]
2. Internet telephony
7
2.4 Internet telephony gateway
As mentioned earlier Internet telephony gateway is a network component
providing conversion of connections from PSTN to IP and vice versa. There are
several functions that a gateway must perform. First it must have a PSTN
interface that terminates or initiates PSTN connections. This interface can be for
example ISDN primary rate or Signalling System 7 (SS7) interface such as ISDN
User Part (ISUP). The PSTN signalling can be converted to H.323 or another
emerging alternative, such as Session Initiation Protocol (SIP).
The speech path in PSTN is coded with companded PCM, which can be used as
such in IP network. This speech codec is called G.711. If the telephony interface
is a mobile connection, the codec used is commonly GSM full rate. If the speech
is wanted to be transcoded with another codec, the gateway performs the
transcoding. Popular alternatives for G.711 are for example G.723.1 and G.729,
which compress the voice to about one tenth of the original G.711 stream.
Next the coded voice is transferred across the IP interface packed in RTP streams.
If a gatekeeper is used, there has to exist dialog between the gateway and the
gatekeeper to get access to network resources and to perform the address
translation from E.164 numbers in PSTN to IP addresses.
In the receiving gateway the signalling is terminated and the speech packets are
buffered. Buffering is conducted to even the irregular transmission times that have
taken place in the IP network. From the buffer the speech packets are again
converted to PCM voice, and PSTN signalling procedures are initiated to make
the connection to the end node in PSTN.
3. The testing network
8
3. The testing network
This chapter describes the requirements, planning and implementation of the
testing network.
3.1 Requirements for the network
The main requirements for the testing network were that the components should
be affordable and the network should be able to implement the scenarios in
Figures 1-1 - 1-3. The network should be able to have variable IP characteristics.
This means that there should be a way to control the load in IP network. Also
monitoring of the protocols used in interworking between PSTN and IP should be
possible.
3.2 Network plan
The whole testing network plan is realised in Appendix A.
3.2.1 The gateways
The fist step in planning the network was selecting the gateways for the network.
After reviewing several candidates the target was set for Natural Microsystems
Fusion platform. Fusion is used on Windows NT operating system. The system
consists of a PCI card with 4 E1 links. E1 is an European standard for connecting
2Mbit/s PCM links. Fusion supports ISDN primary rate connections on the
telephony interface. The selected version was an AG4000 card, which supported
up to 30 simultaneous H.323 calls. With an additional processing board the
capacity would have risen to 120 connections. However, in our testing network
there was no need for larger capacity. [7]
The system utilises the PC’s Ethernet Network Interface Card (NIC) in
communicating with the IP network. This configuration is called "Host Based
Fusion".
The gateway is not a real gateway product. Instead, it is a platform for developing
gateway applications. There was, however, a sample gateway application
provided with the board. This application contained all the necessary functions to
run an Internet telephony gateway.
3. The testing network
9
Our testing network required two gateways. Therefore two Fusion boards with
appropriate software, protocol stacks and licences were needed.
3.2.2 The IP network
The IP network part in our testing system should be able to emulate different
characteristics of real world networks. Therefore it was clear that either some
device that would be able to load the network would needed, or the load should be
emulated. It was decided that network emulation would give us more liberty in
configuring the network.
After searching for usable IP network emulator, the NISTNET package for Linux
operating system became a clear choice. The Linux operating system is free for
use, as well as the NISTNET software. Therefore the requirement for affordable
components was well met. NISTNET is able to emulate network delay, delay
variation (jitter), packet loss and packet duplication. For NISTNET to be able to
manipulate IP packets it has to be run in a machine that is configured as a router.
Linux has good support for routing built into the operating system, and that made
the choice even easier. [9]
3.2.3 Monitoring tools
Network monitoring was also one of the main requirements for the testing
environment. There are many software based monitors for different protocols.
These were naturally more appealing than more expensive systems requiring
hardware support. For Linux there exists many monitoring programs that are free
for use. In Linux router these would work just fine. The Linux operating system
contains basic monitoring tools, such as TCP Dump. This is however very basic,
and more advanced programs can be downloaded from the Internet. IPGrab is a
good example of a simple, but very usable monitoring program for linux. It
decodes many fields open from the IP datagrams. [9]
For Windows NT IP telephony gateway machines an H.323 monitor was hoped
for. One good candidate was found from a company called TTC. The Fireberd
DNA H.323 monitoring software monitors many signalling protocols under the
H.323 umbrella, and provides a nice Graphical User Interface (GUI) for message
decoding. The software is free for evaluation for 45 days. [10]
3. The testing network
10
3.3 Setting up the network
3.3.1 The gateway setup
The network setup was begun with the gateways. The installation of the boards
itself was straightforward thanks to the PCI bus interface, which helps a lot in
setting up the interrupts and memory addresses for the board. The drivers and
gateway application were not so easy to install. The drivers required a lot of
configuration and overally they did not leave a very professional image. The
gateway application was provided as source code only. The compilation to an
executable application required Microsoft Visual C++ software and some
configuring. When all the necessary software, including several codecs and H.323
stack by RadCom were installed, the system was ready for first testing. The
gateway sample application desktop view is seen in Figure 3-1.
Figure 3-1 Gateway application
3. The testing network
11
As mentioned earlier the gateway used the PC’s NIC card in connecting to the
Local Area Network (LAN). The PSTN ISDN primary rate interface was
connected to a Nokia DX220 telephony switch. Analog and ISDN basic rate
subscribers were connected to DX220. With the subscriber interfaces it was
possible to make calls that were routed to the ISDN primary rate route.
The subscriber database of the gateway application was implemented with one
simple text file. The database contained entries in the
form:"880000,131.228.150.20,PtoP,880000". This is translated as a call from
number 880000 is routed to IP address 131.228.150.20. The connection is from
PSTN to PSTN and the number to call in the terminating gateway is 880000. This
is a very simple subscriber database, but it is usable in our testing environment.
The database contained different mode identifiers for pure IP calls and calls from
IP network to PSTN and vice versa. In all cases the entry format was similar.
After connecting the IP interfaces to an Ethernet switch first test calls could be
made. The gateway required, that in PSTN to PSTN connections it had to receive
all digits of a telephone number at once. Thus it did not support overlap sending
of digits, and the switch had to be configured to so called En-block mode, where
the whole E.164 called party number is transmitted in SETUP message. Soon it
was found out, that the gateway worked fine except for the G.729 codec, which
did not produce any traffic on the speech path.
Next it was time to try a call between a H.323 and a PSTN client. The H.323
client that was used was Microsoft NetMeeting softeware on Windows NT
machine connected to the Ethernet switch. The software was configured to use
one of the H.323 gateways as its IP telephony gateway. Then a call could be made
to PSTN - if the address entry was in the gateway’s subscriber database. Besides
some problems with echo from the PC’s speakers to the microphone, the
connection worked properly. The NetMeeting software did not seem very stable -
it produced some freezes of the whole NT operating system.
Now the IP telephony gateway system was operational, and it was time to set up
the router and the emulation software.
3. The testing network
12
3.3.2 NISTNET emulator
Linux version used was Red Hat 5.2 distribution. Newer versions of Red Hat
exist, but the compability of NISTNET is guaranteed only with certain older
versions of the Linux kernel. Linux kernel had to be re-compiled to enable support
for IP packet forwarding. Kernel compilation is documented in Linux How-to
documents[11]. Kernel options that were needed in the compilation were:
• Prompt for development and/or incomplete drivers
• Enable loadable module support
• Networking support
• Network firewalls
• TCP/IP networking
• IP: forwarding/gatewaying
• IP: Firewalling
• IP: Masquerading
• IP: ipautofw masquerade support
• IP: ICMP masquerading
• IP: Always defragment
• Dummy net driver support
After the kernel had been compiled and the new kernel made active, next thing to
do was to configure the Ethernet cards. Two Ethernet cards were needed in the
router machine to support two subnetwork interfaces. The Network Interface
Cards (NIC) were 3COM 509 ISA-bus cards. Because the cards used ISA-bus,
there were some incompatibility problems. One of the cards had to be
programmed with an application provided by the manufacturer’s support pages to
use another interrupt and different memory area. After this alteration the system
recognized the cards.
3. The testing network
13
The cards were configured so that one of them had subnet 131.228.150.0 and the
other one 131.228.120.0. The IP addresses of the cards were 131.228.150.50 and
131.228.120.50 respectively. The netmask for both cards was set to be
255.255.255.0.
The cabling had to be modified to support direct connections from the gateway
machine’s NIC to router machine’s NIC. Following connections had to be made:
[11]
RJ45 Plug 1 Tx+ -------------- Rx+ 3 RJ45 Plug
2 Tx- -------------- Rx- 6
3 Rx+ -------------- Tx+ 1
6 Rx- -------------- Tx- 2
Figure 3-2 Crossover cabling
NISTNET software installation was well documented in the package. First some
kernel patches were installed, and then the actual application was compiled. The
application is loaded to the kernel as a loadable module. This means that first a
module is installed and then the application is started.
The user interface in NISTNET is graphical. It contains entries for packet sources
and destinations, as well as for the desired network characteristics. The possible
characteristics that are adjustable are network delays, delay variation, packet loss
percent, packet duplication percent and available bandwidth. NISTNET only
handles those packets that the source and destination addresses define.
With Ping tool it was possible to check the correct operation of NISTNET.
Pinging showed that the packets indeed were delayed and duplicated etc.
according to the settings. Pinging from the gateway machines also indicated that
the router machine was routing packets correctly.
3. The testing network
14
When the gateways and the router had been connected, first test calls through the
emulated network could be made. It was soon found out, that the differences in
voice were easy to spot, when the simulator introduced some IP inefficiencies to
the network.
3.3.3 Installing monitoring tools
The Windows NT Fireberd H.323 monitor was easy to install. Setup program was
provided in the installation package, and the installation went without a hitch. The
software is an off-line monitoring tool. This means that it records the signalling
from the NIC and decodes it off-line. The software decodes H.225, H.245, Q.931,
RAS, RTP, and RTCP protocols. A view of decoded H.323 messages can be seen
in Appendix A.
The linux network monitor IPGrab was a little harder to install. It required
installation of libpcap library, before its installation could be started [13]. After
compiling both the library and the application ipgrab worked perfectly. It decodes
packets and frames for numerous protocols, such as IP, TCP, UDP, Address
Resolution Protocol (ARP) and Ethernet. It is an on-line decoder, and it was able
to decode large streams of packets without any slowdowns.
4. Conclusion
15
4. Conclusion
The testing network worked properly. All the components achieved to fullfill the
requirements set for them. Especially the NISTNET software proved to be an
invaluable tool. With NISTNET emulation of large networks is possible, after you
know the network characteristics. These characteristics can be found out for
example by pinging network servers so much that statistics can be collected. Then
the values can just be set to the simulator and the network is ready to be used in
testing.
Linux itself was a good platform for performing network tests. The router support
in Linux worked fine, and the performance of the Linux router was very good.
Linux also provided a stable working environment, and support was easy to find
from the Internet. The free-of-charge idealism in Linux world is a great
advantage. Software, such as IPGrab, can be really valuable in many applications,
and further development of applications is easy thanks to the source code
delivered with the packages.
The gateways performed acceptably. The gateway application was adequate for
small scale evaluation purposes. But as a private branch exchange it would not be
powerful enough. The source code of all the gateway software was included in the
package. This was of course a good thing for development of own applications.
However, we did not have the resources required to study the software further.
All in all the testing network worked fine, and it will be used for further
evaluation and educational purposes.
References
16
References
[1] European Telecommunications Standards Institute, TR 101 300,
Telecommunications and Internet Protocol Harmonization Over Network
(TIPHON), Description of technical issues, 1999
[2] Defense Advanced Research Projects Agency, Internet Protocol Spefication,
RFC 791, 1981
[3] Defense Advanced Research Projects Agency, Transmission Control Protocol
Specification, RFC 793, 1981
[4] Postel J., User Datagram Protocol, RFC 768, USC/Information Sciences
Institute, 1980
[5] Schulzrinne H., Casner S., Frederick R., Jacobson V., Network Working
Group, RTP: A Transport Protocol for Real-Time Applications, RFC 1889, 1996
[6] Telecommunication standardisation sector of ITU, Packet-based multimedia
communications systems, H.323, 1998
[7] Natural Microsystems, AG4000 board homepage,
http://www.nmss.com/nmss/nmssweb.nsf/productlist/AG+4000+Series , 1999
[8] NISTNET homepage, http://www.antd.nist.gov/itg/nistnet/, 1999
[9] IPGrab, http://www.opensec.net/trinux/toolusage.html, 1999
[10] TTC, Fireberd DNA H.323 analysator homepage,
http://www.ttc.com/products/html/p_list/fb500_dna.html, 1999
[11] Linux Kernel How-To, http://ftp.uwasa.fi/ldp/HOWTO/Kernel-
HOWTO.html, 1999
[12] Data Cabling FAQ, http://www.faqs.org/faqs/LANs/cabling-faq/ , 1995
[13] Libpcap library, ftp://ftp.ee.lbl.gov/libpcap.tar.Z , 1999
Appendix A – Testing network
17
DX220Analog subscribers
E1 - ISDN Primary rateE1 - ISDN Primary rate
10Base T Ethernet (131.228.150.0)
10Base T Ethernet (131.228.120.0)
Gateway with NetMeeting
Router and NISTNET simulator with IPGrab software
Appendix B: View of the H.323 monitoring software
