Technical University of Košice
Faculty of Electrical Engineering and Informatics
Efficient VoIP Solution for the Environment of
the Technical University of Kosice
Jozef Janitor
Master’s Thesis
Košice 2008
Technical University of Košice
Faculty of Electrical Engineering and Informatics
Department of Computers and Informatics
Efficient VoIP Solution for the Environment of
the Technical University of Kosice
Master’s Thesis
Jozef Janitor
Supervisor: Ing. František Jakab, PhD.
Consultant: Ing. František Jakab, PhD.
Košice 2008
Metadata Sheet
Author:
Jozef Janitor
Thesis title:
Efficient VoIP Solution for the Environment of the Technical University of Kosice
Language:
English
Type of Thesis:
Master’s Thesis
Number of Pages:
77
Degree:
Master
University:
Technical University of Košice
Faculty:
Faculty of Electrical Engineering and Informatics (FEEI)
Department:
Department of Computers and Informatics (DCI)
Study Specialization:
Computers and Informatics
Study Programme:
Information Systems and Technologies
Town:
Košice
Supervisor:
Ing. František Jakab, PhD.
Consultant(s) :
Ing. František Jakab, PhD.
Date of Submission:
16. 5. 2008
Date of Defence:
4. 6. 2008
Keywords:
VoIP, IP Telephony, Converged Networks, Unified Communication, Realtime Communication, QoS, Security, ENUM, SIP,
NAT, SBC
Category Conspectus:
(In Slovak only) Výpočtová technika; Počı́tačové siete
Thesis Citation:
Jozef Janitor: Efficient VoIP Solution for the Environment of
the Technical University of Kosice. Master’s Thesis. Košice:
Technical University of Košice, Faculty of Electrical Engineering and Informatics. 2008. 77 pages
Title SK:
Efektı́vne riešenie VoIP siete pre prostredie Technickej Univerzity v Košiciach
Keywords SK:
VoIP, IP Telefónia, Konvergované Siete, QoS, Bezpečnost’
Abstract in English
Modern data networks has in the last few years evolved into networks which are capable of
transferring more than just one information flow at the same time. Each flow is transferred
with guaranteed quality of service parameters. We can call these networks as Converged
networks. Converged networks integrate data, voice and video communication into one
common unified network. The thesis introduces the possibilities of usage of converged
networks in building a secure and easily scalable VoIP network. As a model solution,
the implementation of the VoIP network at the Technical University of Kosice and the
Computer Networks Laboratory is described.
Abstract in Slovak
Moderné dátové siete sa v posledných niekol’kých rokoch vyvinuli do sietı́, ktoré sú
schopné prenosu viacerých informačných tokov v jednom čase, s garanciou parametrov
kvality služieb pre každý jeden z týchto tokov. Takéto siete môžeme nazývat’ konvergovanými siet’ami. Konvergované siete integrujú dáta, hlas a video komunikácie do jednej
zjednotenej spoločnej siete. Práca popisuje možnosti využitia konvergovaných sietı́ pre
vybudovanie bezpečnej a jednoducho škálovatelnej VoIP siete. Ako modelové riešenie
sa popisuje implementácia VoIP siete v prostredı́ Technickej University v Košiciach a
Laboratória Počı́tačových Sietı́.
Declaration
I hereby declare that this thesis is my own work and effort. Where other sources of
information have been used, they have been acknowledged.
Košice 16. 5. 2008
..........................
Signature
Acknowledgement
I would like to express my sincere thanks to my supervisor Ing. František Jakab,PhD. for
his constant, and constructive guidance throughout the studies.
Special mention should go to the team of Computer Networks Laboratory at Technical
University of Kosice.
At last but definitely not least, I would like to express my thanks to my whole family and
friends for their help throughout my studies at university.
Thank you.
Slovak: Chcem sa podakovat vedúcemu diplomovej práce Ing. Františkovi Jakabovi,PhD.
za cenné rady a pripomienky pri tvorbe tejto diplomovej práce a za poskytnutie priestorov
a vybavenia v Laboratóriu pocı́tacových sietı́ na Technickej Univerzite v Košiciach.
Taktiež chcem podakovat kolektı́vu Laboratória pocı́tacových sietı́ na Technickej Univerzite v Košiciach, za nezištnú pomoc a rady počas tvorby diplomovej práce.
V neposlednom rade chcem podakovat celej rodine a priatel’om za nezištnú podporu počas
mojho pôsobenia na vysokej škole.
Ďakujem.
Preface
Voice over IP (VoIP) and IP Telephony are emerging technologies that bring realtime
voice communication features into data networks. VoIP as a term defines the process of
transferring some parts of a voice communication over an IP data network. VoIP is many
times used with voice gateways to crossconnect the PSTN or local analog or digital PBX
networks with IP data networks. IP Telephony, on the other hand, defines end to end
voice over ip transmission. In IP Telephony, the endpoints are usualy IP phones connected
directly to an IP data network.
In the last few years we have been seeing how these technologies have became parts
of our daily life. To provide VoIP or IP telephony services with required quality, it
is necessary to consider the quality of the underlying transporting network. Different
QoS technologies and methods can be used to provide these quality requirements. It is
also necessary to think about security aspects. While the traditional telecommunication
networks are usually completely isolated from attacker’s access, it is many times difficult
to provide this level of security in data network. Firewalls can be used to protect VoIP
servers, and endpoints. For the actual voice transmitting in IP networks it is necessary
to implement also additional security solutions, especially at OSI Layer 2 and Layer 3.
For privacy aspects, encryption and identity managements are necessary to implement.
Network Address Translation (NAT, PAT) that is many times used by Internet Service
Providers and home access routers brings also connectivity issues into VoIP networks.
Many different technologies have been developed to address these issues.
The world beyond VoIP and IP Telephony is called Unified Communications. Unified
Communications unifies and integrates different communication channels into one common solution, that provides easy and unified access to voice services, presence, emails,
call processing, mobility, etc.
Contents
Introduction
1
1
The problem expression
4
2
Introduction to Voice Networks
5
2.1
Traditional Telecommunications Networks . . . . . . . . . . . . . . . . .
5
2.2
Data Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.3
IP Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
2.4
Converged Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
2.5
VoIP Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
3
Voice over IP
16
3.1
Signaling Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
3.1.1
H.323 Signaling Protocol . . . . . . . . . . . . . . . . . . . . . .
18
3.1.2
SCCP Signaling Protocol . . . . . . . . . . . . . . . . . . . . . .
19
3.1.3
SIP Signaling Protocol . . . . . . . . . . . . . . . . . . . . . . .
19
3.1.4
SDP Signaling Protocol . . . . . . . . . . . . . . . . . . . . . .
24
3.1.5
IAX Signaling Protocol
. . . . . . . . . . . . . . . . . . . . . .
26
3.1.6
MGCP Signaling Protocol . . . . . . . . . . . . . . . . . . . . .
26
Media Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
3.2.1
Voice Codecs . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
3.2.2
RTP Media Protocol . . . . . . . . . . . . . . . . . . . . . . . .
29
3.2
4
Quality of Service
32
4.1
Network QoS Parameters . . . . . . . . . . . . . . . . . . . . . . . . . .
32
4.1.1
Packet Loss . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
4.1.2
Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
4.1.3
Jitter
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
Measuring Voice QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
4.2
FEEI
4.3
5
7
Provisioning Network QoS . . . . . . . . . . . . . . . . . . . . . . . . .
35
4.3.1
Best Effort Model . . . . . . . . . . . . . . . . . . . . . . . . .
35
4.3.2
Integrated Services Model . . . . . . . . . . . . . . . . . . . . .
36
4.3.3
Differentiated Services Model . . . . . . . . . . . . . . . . . . .
36
Securing VoIP networks
38
5.1
Security Threats of Transport Network . . . . . . . . . . . . . . . . . . .
38
5.1.1
Layer 1 Security . . . . . . . . . . . . . . . . . . . . . . . . . .
39
5.1.2
Layer 2 Security . . . . . . . . . . . . . . . . . . . . . . . . . .
39
5.1.3
Layer 3 Security . . . . . . . . . . . . . . . . . . . . . . . . . .
40
5.1.4
DNS Security . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
5.1.5
Uninterruptible Power Supply . . . . . . . . . . . . . . . . . . .
41
Major Security Issues of VoIP . . . . . . . . . . . . . . . . . . . . . . .
41
5.2.1
Eavesdropping . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
5.2.2
Toll Fraud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
5.2.3
Call Spoofing . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
5.2.4
DoS Attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
5.2.5
Enhanced Emergency Calls . . . . . . . . . . . . . . . . . . . .
43
5.2.6
Spam over IP Telephony . . . . . . . . . . . . . . . . . . . . . .
44
5.2
6
DCI
Firewalls, NAT, PAT and VoIP
45
6.1
Traversal Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
6.1.1
Simple Traversal of UDP through NATs . . . . . . . . . . . . . .
46
6.1.2
Traversal Using Relay NAT . . . . . . . . . . . . . . . . . . . .
47
6.1.3
Interactive Connectivity Establishment . . . . . . . . . . . . . .
47
6.1.4
Application Layer Gateway . . . . . . . . . . . . . . . . . . . .
47
6.1.5
Session Border Controller . . . . . . . . . . . . . . . . . . . . .
48
Call Control and Routing
49
7.1
49
Centralized Call Control . . . . . . . . . . . . . . . . . . . . . . . . . .
10
FEEI
8
9
DCI
7.2
Distributed Call Control . . . . . . . . . . . . . . . . . . . . . . . . . .
49
7.3
H.323 Gatekeeper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
7.4
SIP Proxy Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
7.5
ENUM Disributed Directory Procotol . . . . . . . . . . . . . . . . . . .
51
Additional Services based on VoIP
54
8.1
VoIP Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
8.1.1
Interactive Voice Response . . . . . . . . . . . . . . . . . . . . .
54
8.1.2
Presence Services . . . . . . . . . . . . . . . . . . . . . . . . . .
54
8.1.3
Video over VoIP . . . . . . . . . . . . . . . . . . . . . . . . . .
55
8.1.4
Unified Communications . . . . . . . . . . . . . . . . . . . . . .
55
VoIP at the Technical University of Kosice
56
9.1
Initial Status Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . .
57
9.2
Possible Solutions for Extending . . . . . . . . . . . . . . . . . . . . . .
57
9.2.1
SIP Express Router . . . . . . . . . . . . . . . . . . . . . . . . .
58
9.2.2
Asterisk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
58
9.2.3
Voice Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . .
59
9.2.4
ENUM Routing . . . . . . . . . . . . . . . . . . . . . . . . . . .
59
9.2.5
Additional Services . . . . . . . . . . . . . . . . . . . . . . . . .
60
Final Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . .
61
9.3
10 Conclusion
70
Bibliography
73
Appendices
77
11
List of Figures
2 – 1 Time Division Multiplex . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2 – 2 Circuit Switched Network . . . . . . . . . . . . . . . . . . . . . . . . .
7
2 – 3 Packet Switched Network . . . . . . . . . . . . . . . . . . . . . . . . . .
9
2 – 4 Basic VoIP Network . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
3 – 1 Signaling and Data Protocols in VoIP . . . . . . . . . . . . . . . . . . .
16
3 – 2 SIP Registrar Server . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
3 – 3 SIP Proxy Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
3 – 4 Basic Sip Call Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
3 – 5 MGCP Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
3 – 6 Sound Digitalization . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
3 – 7 PDU Layout for G.711, G.729 and G.729 with cRTP . . . . . . . . . . .
30
6 – 1 SIP NAT Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
7 – 1 ENUM Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
7 – 2 ENUM Call Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
9 – 1 First IP Telephony Project in SANET . . . . . . . . . . . . . . . . . . .
56
9 – 2 Final VoIP Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . .
61
9 – 3 Cisco Call Manager Call Routing Configuration . . . . . . . . . . . . . .
66
9 – 4 Cisco Call Manager SIP Trunk Configuration . . . . . . . . . . . . . . .
67
9 – 5 TCL Based CLIP Functionality . . . . . . . . . . . . . . . . . . . . . . .
68
9 – 6 TUKE Yellow Pages . . . . . . . . . . . . . . . . . . . . . . . . . . . .
69
List of Tables
3 – 1 Main VoIP Codecs . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
3 – 2 Emerging VoIP Codecs . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
4 – 1 One Way Delay values in VoIP . . . . . . . . . . . . . . . . . . . . . . .
33
4 – 2 Mean Opinion Score Values . . . . . . . . . . . . . . . . . . . . . . . .
34
List of Symbols and Abbreviations
AES Advanced Encryption System
ALG Application Layer Gateway
ARP Address Resolution Protocol
ATA Analog Telephone Adapter
B2BUA Back to Back User Agent
BRI
Basic Rate Interface
CAS Channel Associated Signaling
CCS Common Channel Signaling
CNL Computer Networks Laboratory
CoS
Class of Service
cRTP Compressed Realtime Transport Protocol
DiffServ Differentiated Services
DoS
Denial of Service
DS0
Digital Signal 0, basic digital signaling rate of 64-kbps
E&M Ear and Mount or Earth and Magneto
FXO Foreign Exchange Office
FXS
Foreign Exchange Station
ICE
Interactive Connectivity Establishment
FEEI
DCI
IETF Internet Engineering Task Force
IM
Instant Messaging
IntServ Integrated Services
IP
Internet Protocol
IPv4 Internet Protocol version 4
IPv6 Internet Protocol version 6
ITU
International Telecommunication Union
IVR
Interactive Voice Response
LAN Local Area Network
MITM Man In the Middle
MOS Mean Opinion Score
NAT Network Address Translation
OWD One Way Delay
PAT
Port Address Translation
PBX Private Branch Exchange
PDU Protocol Data Unit
PoE
Power over Ethernet
PSTN Public Switched Telephone Network
QoS
Quality of Service
15
FEEI
DCI
RSVP Resource Reservation Protocol
RTP
Realtime Transport Protocol
SANET Slovak Academical Network
SBC Session Border Controller
SCCP Skinny Client Control Protocol
SER
SIP Express Router
SIP
Session Initiation Protocol
SRTP Secure RTP
STUN Simple Traversal of UDP through NATs
TCP
Transmission Control Protocol
TDM Time Division Multiplexing
TLD Top Level Domain
TLS
Transport Layer Security
ToS
Type of Service
TUKE Technical University of Kosice
TURN Traversal Using Relay NAT
UDP User Datagram Protocol
UPNP Universal Plug and Play
UPS
Uninterruptible power supply
16
FEEI
DCI
VAD Voice Activity Detection
VoIP Voice over IP
17
List of Terms
Voice over IP is a technology that enables transferring realtive voice communication
over an IP Data Network.
Signaling Protocols enable exchanging messages between network devices. Signaling
Protocols are use in VoIP to create, manage and teardown calls.
Media Protocols transfer the actual voice or video and provides required reliability features.
Gateway connects together and enables communication on different network types. In
VoIP gateways interconnect VoIP and traditional telecommunications networks.
Network Address Translation is process, that usually happens on a NAT enabled router,
that changes the source or the destination IP address or port number of a received
packet before forwarding towards the destination.
Firewall is a device or an application that protects a network or an individual host from
unwanted communication.
FEEI
DCI
Introduction
The problem of voice transmission over data networks has been a heavily discussed topic
in the last few years. We can divide this problem to different layers. From many network
models, the ISO OSI layered model seems to be the most appropriate to explain a complex
problem like the voice transmission in data networks. Some layers of the OSI model, like
the physical layer, are obvious, and will be not described in the thesis.
On the data link layer of the OSI model, we can talk about two basic technologies: circuit
switched technologies and packet switched technologies.
The legacy voice networks, or telecommunication networks, were based on circuit switched networks. The drawback of these networks is in the scalability and in the fact that
they can carry at one time only one flow per circuit. On the other hand, security and quality
of service had been built into these networks from the beginning.
Packet switched networks were initially created to provide data access between computers
and computer systems. The benefits of packet switched networks are in the fact, that they
are dividing the information flow into data packets, which are they switched throughout
active parts and links of the network. If there is no information flowing on a link, or there
is still some free bandwidth, this link can be reused by other flows. That means higher
scalability and better use of bandwidth.
The voice journey from circuit switched telecommunication networks into packet switched data networks has been first through the Voice over ATM, later through the Voice
over Frame Relay networks. ATM and Frame Relay networks have their roots in telecommunication networks. Therefore, it is obvious that QoS and security are built-in, or
they are easy to provide. On the other hand, Ethernet, as a de-facto protocol of current
data networks, has never been designed to overcome these networks. Legacy Ethernet
networks were non-deterministic networks, where almost nothing was guaranteed. However, the low price of the Ethernet technology, and later newer devices like Ethernet
1
FEEI
DCI
Switches opened a path to Ethernet to become reliable, highly scalable, with security and
QoS integration.
As a mainstream network layer protocol, in data networks currently the IP protocol is a defacto standard. IP provides connectionless communication channels between endpoints.
Furthermore, the Internet’s wide spreading across the world provides means to create a
new generation of services built on IP data networks. As nowadays, IP data networks
are reliable and capable of QoS and security, these networks can carry legacy data, plus
voice and video at one time. Voice and video are currently one of the main drivers of the
Internet, and in the near future, they will become just more general.
To provide a Voice over IP service with a required quality, security and scalability on the
top of IP data networks, it was necessary to develop new protocols and technologies.
The thesis is devoted to describe some of these technologies. One of the main goals of
the thesis is to provide a model solution of a Voice over IP network built within the
infrastructure of the Technical University of Kosice and the environment of the Computer
Networks Laboratory.
The thesis text is divided into several chapters. The first chapter introduces the actual thesis
topic, maps a state of a voice network at the Technical University of Kosice before the
thesis[’s] outputs have been implemented. The first chapter also provides short description
of technologies and protocols that were used within the work.
The second chapter introduces basics of Voice over IP technologies and refers to differences between Voice over IP networks and Plain Old Telephone Service (POTS). At the end
of this chapter, the main issues of Voice over IP networks are collected.
The third chapter describes basic VoIP protocols. Signalization and voice transfer protocols, as well as some additional supporting protocols are described in this chapter.
The fourth chapter provides a look into the Quality of Service problematic in Voice over IP
networks. Basic methods of determining the voice quality are outlined within this chapter.
2
FEEI
DCI
The chapter ends with examples of methods that can provide voice transmission over IP
networks with required quality.
The fifth chapter provides a look into the security problematic in Voice over IP networks.
Secure voice transmission and signalization, identity and key exchange methods are
described in this chapter.
The sixth chapter introduces the problematic of Firewalls and Network Address Translation
in Voice over IP networks. Methods of handling these circumstances are introduces in this
chapter.
The seventh chapter is about Call Routing in bigger or distributed Voice over IP networks.
Differenced between centralized and decentralized solutions and H323 gatekeepers and
ENUM routing is described in this chapter.
The eight chapter is about addon services and Uniffied Communications. Presence, collaboration and productivity tools based on Voice over IP technologies are introduced in this
chapter.
The ninth chapter contains the model solution of a Voice over IP network at the Technical
University of Kosice and the Computer Networks Laboratory.
The tenth chapter contains conclusions.
3
FEEI
1
DCI
The problem expression
The goal of this thesis is to create within the environment of the Technical University of
Kosice and the Computer Networks Laboratory a new efficient model for providing reliable
Voice over IP services with Scalability, Security and Quality of Service considerations.
To achieve this goal, it is necessary to:
• Analyze the current situation of the Voice over IP and PSTN network at the Technical
University of Kosice
• Analyze and research current technologies used in building converged VoIP networks
• Create an efficient model to extend the current state of the VoIP network at the
Technical University of Kosice
• Implement the proposed model to the network environment
4
FEEI
2
DCI
Introduction to Voice Networks
Next chapters will introduce basics of voice transmission over traditional telecommunication and IP data networks. Specific issues of real-time voice transmission over IP networks
will be analyzed in more details.
2.1
Traditional Telecommunications Networks
Alexander Graham Bell accomplished the first voice transmission in 1876. After his
invention, telecommunication industry has started to develop.
Traditional telecommunication networks transferred voice in its analog or digitalized form
over a circuit switched network. The main components of a traditional telecommunications
network are:
• Edge Devices
– Analog Telephones
– Digital Telephones
• Local Loops
• Trunks
• Central Office (CO) switches
• Private Branch Exchange (PBX)
Edge devices are usually endpoints that terminate a voice call. The two types of edge
devices that are used in traditional telephony networks are Analog Telephones and Digital
Telephones. Both analog and digital telephones are usually connected directly to the PSTN
network or to a PBX.
Local loop is the interface to the telephone company network. Typically, it is a single
5
FEEI
DCI
twisted pair of wires that carry a conversation. Trunks provide a communication path
between two switches. Several signalization protocols were developed to operate on trunk
links.
Central Office switches and Private Branch Exchanges are the heart and the brain of the
telephony network. They terminate local loops, provide power to edge devices, generate
tones, handle signaling, digit collection and call management (call routing, setup, accounting and teardown). Connection between CO switches and/or PBX switches is usually
accomplished with trunk links.
Analog telephony is prone to noise interference and typically can carry only one call per a
wire pair. Digital telephony is resistant against noise interference because a voice channel
is digitalized (PAM, PCM) into a 64kbps digital signal stream. Digital telephony can also
more easily use a single wire pair to transfer more than one call at the same time. To
transfer more voice channels over a single wire pair at the same time, multiplexes has to
be used. The two multiplexes that used in telecommunication networks are:
• Frequency Division Multiplexing
• Time Division Multiplexing
Frequency Division Multiplexing (FDM) carries multiple voice channels by allocating an
individual frequency range to each call. FDM is typically used in analog connections. FDM
is used in cable or digital subscriber line (DSL) connections to allow the simultaneous use
of multiple channels over the same wire.
Time Division Multiplexing (TDM) (Fig. 2 – 1) uses digital transmission and assigns short
time intervals, or time slots to each channel in rotation. In telecommunication, usually
T1 and E1 TDM multiplexes or their combinations are used. T1 multiplex is defined
as a 24-channel trunk, 64kbps per each channel that provides bandwidth of 1536kbps.
E1 multiplex is defined as a 32-channel trunk, 64 kbps per each channel that provides
bandwidth of 2048kbps. E1 and T1 switches are typically used as trunk connection between
CO switches or PBX switches.
6
FEEI
DCI
Fig. 2 – 1 Time Division Multiplex
Fig. 2 – 2 Circuit Switched Network
7
FEEI
DCI
When a voice call is established in traditional telecommunication networks, a permanent
virtual circuit is created between the two endpoints. In TDM networks, a timeslot is
assigned to the voice call. This circuit is then reserved throughout the call duration only
for one particular voice call. Other calls cannot use or share the created communication
channel, even if there is actually no voice transmission happening. We call this type
of network a Circuit Switched Network (fig. 2 – 2). Circuit Switched Networks provide
guaranteed delivery and the same guaranteed quality of voice service throughout the call
duration. On the other hand, this approach is cost ineffective because the permanent virtual
circuits can carry only one call.
Public Switched Telephone Network (PSTN) is generally a representative of the traditional telecommunication network. Although, modern PSTN networks may use NGN data
network technologies.
2.2
Data Networks
Whilst in telecommunication networks the bandwidth is rather expensive, in data networks
the bandwidth is usually cheap and more accessible. Data networks use datagrams or
packets to transfer data between endpoints on a best effort basis. The data or the information
that needs to be transferred over a data network is split into small segments. By adding
additional control fields to segments, datagrams or packets are created. Packets are then
delivered from the source point to the destination throughout a Packet Switched Network.
In packet switched networks (fig. 2 – 3), each packet may be switched over a different
path on its journey to the destination. Packets can be load balanced over different data
links to provide better utilization of free bandwidth. The drawback of this packet switched
approach is that because each path may have different speed and quality, packets may
arrive to the destination in different order, on congested paths even some packets may be
even dropped. As a contrast, in telecommunication networks, at the beginning, or before
the call transfer a permanent virtual circuit with guaranteed delivery was created and used
8
FEEI
DCI
Fig. 2 – 3 Packet Switched Network
for the entire call.
2.3
IP Networks
Internet Protocol (IP) is a network layer protocol in the TCP/IP protocols family. IP is
widely used in packet switched networks as a routed protocol, which carries data from
upper layers. Data from upper layer protocols are encapsulated into IP packets. Each IP
packet has its source and destination IP address. IP addresses are used as logical addresses
assigned to network devices and provide a unique global addressing mechanism between
computers. When two computers are communicating with each other, each of them has its
own unique IP address. Globally all IP address must be unique to provide communication
possibilities between computers.
Because of the abstraction and encapsulation provided by the TCP/IP and ISO OSI layered
models, IP can be transparently used over different layer 2 and layer 1 technologies. This
allows the IP to be used over Ethernet, FDDI, Token Ring, ATM, Frame Relay and other
data-link layer technologies. Each data-link layer protocol may have its own method of
9
FEEI
DCI
physical addressing. Address Resolution Protocol (ARP) provides a an addressing gate
between the IP protocol and data-link layer technologies.
The connectionless attribute of the IP protocol eliminates the need of virtual circuits. With
IP, is not needed to setup a virtual circuit before a host tries to send packets to a host it has
previously not communicated with. The drawback of this connectionless attribute is in the
unreliable service that is provided by the IP protocol. This means that the network itself
at the IP protocol level does not provide any guarantees of data delivery. It can cause:
• Data corruption
• Out-of-order delivery
• Duplicate arrival
• Lost or dropped packets
The primary reason for the lack of reliability is to reduce the complexity of routers. Routers
are devices that can make intelligent forwarding decisions based on a router’s routing table
and generally, the destination IP address of the IP packet. Routers route packets from the
source computer to the destination.
If reliability is needed and required, it can be provided by higher layer protocols (e.g.
transport layer). Modern data networks can provide a level of high reliability even at
lower layers. So, even though no guarantees are provided by the IP protocol itself, the
better the underlying network, the better the experience for the user.
IP protocol is available in two versions:
• IP version 4 (IPv4)
• IP version 6 (IPv6)
IP protocol in version 4 defines the IP address as a 32 bit number. That means that
232 =4,294,967,296 IP addresses can be defined in IPv4. Because of some special IP
addresses and special IP address ranges, not all of these IP addresses can be used as usable
10
FEEI
DCI
host (computer) IP addresses. The usable IP addresses can be divided to public and private
IP addresses.
Public IP addresses are used to global addressing of computers directly connected to the
Internet. Public IP addresses are routed on routers within the Internet.
Private IP addresses are used only for local addressing of computers connected to Local
Area Networks (LAN). Private IP addresses are not routed on routers within the Internet.
For the Internet, it means a big problem. As it was said above, when two computers
want to communicate with each other, each of them must have its own unique IP address.
Because of fast growing of the Internet, already in early 90’s there were not enough public
IP addresses for every computer connected to the Internet. To overcome this issue, new
access methods were developed:
Proxy servers, Network Address Translation (NAT), Port Address Translation (PAT) can
represent a big number of computers in a Local Area network as one public IP address
on the Internet. This method also increases the security of the LAN network because it
masquerades its contents. While having higher security in LAN networks, proxy servers,
NAT and PAT may cause several problems for some applications. As a definitive solution
to overcome all of these problems and issues is the IP version 6.
IP protocol in version 6 defines the IP address as a 128-bit number. That means that
2128 ≈3.4x1038 IP addresses can be defined in IPv6. This number seems to be fairly
enough to assign an globally unique public IP addresses to every device on the World.
All the great functions and features of the IP protocol has allowed it to became a de-facto
unified network layer standard of modern data networks as well as the Internet. We can
call these networks as IP Networks.
11
FEEI
2.4
DCI
Converged Networks
Convergence definition as in [1]: ”to move toward the same point and come closer together
or meet”.
As the data networks have evolved into networks that offer reliable data delivery, quality
of service and security, it was obvious that they can do even more than just transferring
emails and files. In the last years, we could have seen how the telecommunication and data
networks have came closer together. Traditional telecommunication networks are moving
to the Next Generation Networks, based on technologies used in data and IP networks.
This allows new services to be integrated into telecommunication networks.
Converged networks can deliver on a single unified and common underlying infrastructure
voice, video, data and mobility services. As an underlying infrastructure, IP data network
is used. In the next chapters, a brief introduction will be made to technologies that enabled
high quality converged services in IP data networks.
2.5
VoIP Networks
Voice over Internet Protocol (VoIP) is a set of technologies that enables replacing voice
services from the traditional analog or digital circuit switched networks to IP data networks.
The three main compelling benefits of VoIP are:
• VoIP makes better use of network bandwidth. Traditional voice uses and reserves a
64-kbps circuit (timeslot in TDM), even when there is actually no voice transmitted.
VoIP can save the bandwidth when there is no voice to transmit (e.g. silence).
• VoIP allows building new services, such as the following:
– Integration of voice and data systems together. Incoming calls can be intelligently routed through IVR services, or delivered to the destination phone with
added information from internal information systems.
12
FEEI
DCI
– Voice codecs can improve sound quality. When enough bandwidth is available,
high quality (HD) wideband codecs can be used to transfer voice.
– Integration with new clients. VoIP clients can be traditional analog telephones
connected though ATA gateways, but VoIP clients may be also hardware IP
phones, software IP phones (softphones) on computers or laptops, mobile
phones with VoIP applications, or even television connected to a SetTopBox.
• VoIP can save money by routing calls through an local IP network or Internet,
instead of using the PSTN network.
• VoIP provides mobility. You can have the same telephone number on different
devices - on your phone on your desk, mobile phone, PDA, laptop, etc.
The main components of a VoIP network are:
• Edge Devices
– IP Phones
– Gateways
• IP data network
• Communications Managers
Edge Devices represented as IP Phones and Gateways transforms IP packets carrying
voice into a sound and vice-versa. IP Phones are standalone hardware pieces or software
applications running on computers. Voice Gateways enables cross-connection of VoIP
network with other voice networks. The simplest voice gateways are Analog Telephone
Adapters (ATA) used to connect an analog phone or fax to a VoIP network. More advanced
gateways have different interfaces that are used in various voice transmitting technologies.
We can divide these interfaces into two basic groups:
• Analog Interfaces
– Foreign Exchange Station (FXS) interface
13
FEEI
DCI
Fig. 2 – 4 Basic VoIP Network
– Foreign Exchange Office (FXO) interface
– Ear and Mount or Earth and Magneto (E&M)
• Digital Interfaces
– ISDN BRI
– T1/E1 Common Channel Signaling (CCS)
– T1/E1 Channel Associated Signaling (CAS)
FXS interfaces provide power and are used to connect to an analog phone or a fax. In
traditional telecommunication networks, ports on a CO or a PBX switch, that are used to
connect phones are FXS ports.
FXO interfaces are interfaces that are used in analog phones. FXO interfaces emulate an
analog edge device. You can connect an FXO to an CO or a PBX switch with an FXS port.
14
FEEI
DCI
E&M ports are used as trunk ports. While on the FXS and FXO ports the signalization uses
the same channel as the voice is transmitted in (in-band signalization), with E&M ports
the signalization runs on a separated channel (out-of-band signalization). This makes the
E&M ports preferable for trunk connections where signalization is very important.
ISDN BRI interfaces are digital interfaces as defined in ISDN. Two B channels, each per
64kbps are used to transfer voice or any digital data. A single 16kbps D channel is used
for signalization with the Q.931 protocol.
T1 or E1 interfaces with CCS signalization are similar to ISDN BRI interfaces. CCS
is out-of-band signalization method. A common channel is reserved in trunk to provide
signalization. Typically Q.931 or QSIG protocols are used for signalization itself. T1
then provides 23 digital channels, while E1 provides 30 digital channels. This kind of
signalization is preferred on T1 or E1 interfaces when used as trunk links.
CAS signalization is defined as in-band signalization and provides 24 voice channels
for T1 interfaces and 30 voice channels for E1 interfaces. For in-band signalization, the
required bits are robbed from the voice channel. This kind of signalization is also called
as Robbed Bit Signaling.
As we can see, there are different signalization methods in traditional telecommunication
networks. Each of them has its good and bad properties, and may be used for different
uses.
Special signaling and data protocols used in VoIP networks are the fundamental enablers
of voice communication over an IP data network. Because in VoIP the voice is actually
transmitted over an IP network, which was in the beginning not designed to provide
reliable transfer rates required for voice communication, it is necessary to use several
QoS techniques to solve this issue. Security can be also a next major problem because of
having easier possibilities to do eavesdropping on an open IP data network based VoIP
service that in a closed telecommunication network. Encryption and identity management
are the answers to these issues, but they are usually not simple to implement.
15
FEEI
3
DCI
Voice over IP
Voice over IP (VoIP) is a technology that provides real-time voice communication possibilities over an IP data network. The term IP Telephony defines a full-IP communications
solution without translation to other than VoIP protocols.
As in traditional telecommunication networks signalization between CO/PBX switches
and edge devices enabled processing of call requests, similar signalization protocols have
been developed in VoIP as well. For the actual voice transmission, the analog voice must be
first digitalized and processed through voice codecs to be encapsulated into data protocols.
Fig. 3 – 1 Signaling and Data Protocols in VoIP
16
FEEI
3.1
DCI
Signaling Protocols
Signaling protocols are used to create, manage and teardown calls or multimedia services.
Signaling protocols also enable endpoints registration, endpoints status gathering for
presence services, etc. Signaling protocols are one of the most important parts of VoIP
technologies. Without signaling, it would be not possible to start voice transmission in IP
data networks.
When a phone dials a number, the number is transmitted to a communications manager
application (softswitch) as a signalization call request message. The communications
manager then searches its own voice routing table, to find out how to route the call to the
dialed destination number. It can also check if there are enough resources (bandwidth, cpu
time, free port, etc.) before contacting the destination device. Before a call is established,
signaling protocols will negotiate endpoint’s addresses on which the voice packets will
flow. Typically in VoIP voice packets are flowing directly between IP phones, while
signaling is flowing only between a phone and its communications manager. After the
call is established, signaling protocols provide call management functions. When a call is
ended, signalization protocols teardown the flow of voice packet.
The main signaling protocols in VoIP are:
• H.323
• SCCP/SKINNY
• SIP
• IAX
• MGCP
17
FEEI
3.1.1
DCI
H.323 Signaling Protocol
H.323 is an open ITU recommendation covering aspects required for voice-video multimedia IP communication. H.323 was originally created to provide a mechanism for
transporting multimedia applications over LANs. Although numerous vendors still use
H.323 only for videoconferencing applications, it has evolved to address the growing
needs of VoIP networks. H.323 is currently one of the most widely used VoIP signaling
and call control protocols. By default, H.323 uses TCP as a transport layer protocol and
port 1720. H.323 is a binary protocol. For troubleshooting and analyzing H.323 signaling,
you may need special tools.
The main components of H.323 architecture are:
• Terminals
• Multipoint Control Units
• Gateways
• Gatekeepers
H.323 Terminals are the edge devices. They can be implemented as a separate hardware
or software running on a computer.
Multipoint Control Units are sophisticated devices enabling multipoint video or voice
conferences with mixed voice or video streams. They may be a necessary part of videoconferencing systems.
H.323 Gateways enable interconnecting a H.323 type of network to different networks
types (e.g. PSTN). It is necessary to translate protocols used in different network types
so that they can communicate together. This may be sometimes not a trivial problem.
Advanced features of one protocol may not be supported in H.323 and vice versa.
Gatekeepers represent a communication manager or an IP PBX in H.323 networks. Gatekeepers provide functions like H.323 endpoints registration, authentication, authorization
18
FEEI
DCI
and accounting, addressing, call routing, telephone numbers translation to IP addresses,
resource reservation, bandwidth management and monitoring, etc.
3.1.2
SCCP Signaling Protocol
Skinny Client Control Protocol (SCCP/SKINNY) is a Cisco proprietary terminal control
and signaling protocol. Originally developed by Selsius Systems which was acquired by
Cisco Systems in 1998. SCCP is a signaling protocol used in Cisco Unified Communications solutions. Generally, SCCP is used to provide a controlling channel between
Cisco Unified IP Phones and Cisco Unified Communications Manager (formerly Cisco
Call Manager). Cisco Unified Communications Manager represents a communications
manager or an IP PBX for an IP telephony and VoIP solution from Cisco Systems. By
default, SCCP uses TCP as a transport layer protocol and port 2000. SCCP is a binary
protocol. For troubleshooting and analyzing SCCP signaling, you may need special tools.
3.1.3
SIP Signaling Protocol
Session Initiation Protocol (SIP) is an open IETF lightweight signaling protocol, widely
used for setting up and tearing down multimedia communication sessions such as voice and
video calls over IP. It can be also used as a signaling protocol for instant messaging (IM),
presence information services, online games setup, etc. Because of the lightweightness
property of SIP, it can be easily extended and used for creating almost any type of advanced
multimedia communication over an IP networks. By default, SIP uses UDP as a transport
layer protocol and port 5060. Secure (encrypted) SIP uses TCP as a transport layer protocol
and port 5061. IETF has a draft specification of SIP over the SCTP transport layer protocol.
SIP itself has been built on a basis of well-known standards used in web technologies like
HTTP, SMTP, etc. As HTTP and SMTP, SIP is an ASCII text based protocol that makes
it easy to troubleshoot. The protocol has similar structure like the HTTP headers. High
Performance (HP) and High Availability (HA) is provided on a similar basis as in SMTP.
19
FEEI
DCI
REGISTER sip:cnl.tuke.sk SIP/2.0
FROM: sip:jozjan@cnl.tuke.sk
To: sip:jozjan@cnl.tuke.sk
Contact: <sip:jozjan@147.232.22.67>
EXPIRES 3600
sip:jozjan@cnl.tuke.sk
=
sip:jozjan@147.232.22.67
(1)
(2)
SIP/2.0 200 OK
(3)
Database
Registrar
SIP UA
Fig. 3 – 2 SIP Registrar Server
SIP access servers are defined for each SIP domain in DNS as SRV type records. More
SIP access servers while each of them may have different or the same priority may handle
one domain. Clients then primarily access those servers, whose priority is the highest.
The main components of SIP architecture are:
• User Agents
• Registrar Server
• Location Server
• Redirect Server
• Proxy Server
• Gateways
User Agents (UA) are the edge devices. They can be implemented as a separate hardware
or software running on a computer. Devices that can initiate or accept communication
requests are UAs.
Registrar Server (fig. 3 – 2)provides registration services for UAs. When a UA is turned on,
it tries to register its location information (IP address, SIP port, etc.) to the registrar server.
Each UA identifies itself with a username (extension), authorization username, password
and SIP domain that it tries to register to. After a successful registration, registrar server
stores the information about UA’s location usually in a database.
20
FEEI
DCI
Fig. 3 – 3 SIP Proxy Server
Location Server uses the location database built by the Registrar Server or a static locations
database. Location Server provides information how to reach the destination UA. This
information is usually the UA’s IP address, listening port, username, etc.
When the Redirect Server receives a call request to some extension, it will use the
Location Server to find out how to reach and contact the destination UA. After finding
this information, it will send a SIP REDIRECT message to the client. The REDIRECT
message contact redirects the client requests directly to the destination UA’s location. In
this case, after receiving the REDIRECT message, UAs can communicate directly together
without utilizing other components of SIP architecture.
Proxy Server (fig. 3 – 3) is in the beginning similar to a Redirect Server. After receiving a
call request, it contacts the Location Server to find out how to reach the destination UA,
but after finding this information no REDIRECT message is sent to the calling client.
Rather, the Proxy Server forwards messages from the calling client to the destination UA
and vice versa. In this case, a Proxy Server acts like a connecting bridge between SIP
UAs. Stateless Proxy Servers only forward messages and do not analyze the contents of
messages. Stateless Proxy Server cannot provide information like how many active calls
are in the SIP network. On the other hand, Statefull Proxy Servers analyze and interpret
received messages and maintain a state of each communication. Therefore, Statefull
Proxy Server can for example provide information about number of active calls in the SIP
network.
21
FEEI
DCI
Registrar, Location, Redirect and Proxy servers are usually embedded into one software
solution and together act as a communication manager or IP PBX for the SIP network.
SIP Gateways provide the same functions as H.323 gateways - interconnect SIP networks
with other types of network.
Communication with SIP is based on messages. The main SIP message types are:
• Requests
– INVITE - Indicates a user or service is being invited to participate in a call
session.
– ACK - Confirms that the client has received a final response to an INVITE
request.
– BYE - Terminates a call and can be sent by either the caller or the called.
– CANCEL - Cancels any pending searches but does not terminate a call that
has already been accepted.
– OPTIONS - Queries the capabilities of servers.
– REGISTER - Registers the address listed in the To header field with a SIP
server.
• Responses
– SIP 1xx - Informational Responses
– SIP 2xx - Successful Responses
– SIP 3xx - Redirection Responses
– SIP 4xx - Client Failure Responses
– SIP 5xx - Server Failure Responses
– SIP 6xx - Global Failure Responses
22
FEEI
DCI
Fig. 3 – 4 Basic Sip Call Flow
A standard SIP call flow with messages is shown on fig. 3 – 4
Example on a SIP Register message:
REGISTER sip:cnl.tuke.sk SIP/2.0
Via: SIP/2.0/UDP 192.168.1.3:1944;branch=z9
Max-Forwards: 70
Contact: <sip:jozjan@10.0.0.1:1944;rinstance=69f104d940ae8487>
To: "Jozef Janitor <7222>"<sip:jozjan@cnl.tuke.sk>
From: "Jozef Janitor <7222>"<sip:jozjan@cnl.tuke.sk>;tag=4e2d6f2f
Call-ID: MGQxOWE5NTYxMGRjMmY5ZjI5NzYxZGNjZTdmNWUwM2U.
CSeq: 213 REGISTER
Expires: 120
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
User-Agent: X-Lite release 1011s stamp 41150
Authorization: Digest username="jozjan",realm="cnl.tuke.sk",nonce="47e4",uri="sip
Content-Length: 0
23
FEEI
3.1.4
DCI
SDP Signaling Protocol
SIP provides only services on a signalization level. SIP registration messages, INVITE
messages, etc. contain in the SIP part only information that is necessary to deliver signalization packets. For the actual voice or other data transmission setup, additional information
must be exchanges between UAs. Therefore, an extension to the SIP is necessary. As it
was said in the previous chapter, SIP is a lightweight protocol and it can be easily extended
with other protocols.
Session Description Protocol (SDP) is an application-layer control protocol for creating,
modifying, and terminating sessions such as Internet multimedia conferences, Internet
telephone calls and multimedia distribution. SDP defines a format of initialization parameters streaming media (voice, video). The initialization parameters are the endpoint’s IP
address, transport protocol, port, codec, etc. Both UAs must agree in the call initialization
process on parameters that are sent in the SDP part of SIP packets. If the negotiation
process does no ends with an agreement on both or on one side, a SIP error message
”NOT ACCEPTABLE” will be send to the other participants.
The following example is a SIP INVITE request with a SDP part. The SDP part defines
the IP address 10.10.10.13 as the endpoints IP address on which it will receive RTP audio
stream on port 4000. RTCP flow will be received on port 4001. The called side will select
one codec that will be used for voice transconding.
INVITE sip:7400@ser.cnl.tuke.sk SIP/2.0
Via: SIP/2.0/UDP 10.10.10.13:5060;rport;branch=z9hG4
Max-Forwards: 70
From: sip:jozjan@ser.cnl.tuke.sk;tag=518344cbbe264697a88
To: sip:7400@ser.cnl.tuke.sk
Contact: <sip:jozjan@10.10.10.13:5060;transport=UDP>
Call-ID: 00a21aba63fe446a9476dcf6bb97a9a9
CSeq: 153 INVITE
24
FEEI
DCI
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, SUBSCRIBE, NOTIFY, PUBLISH, REFER
Supported: replaces, 100rel, norefersub
User-Agent: PJSUA v0.8.0/win32
Content-Type: application/sdp
Content-Length:
432
v=0
o=- 3415133005 3415133005 IN IP4 10.10.10.13
s=pjmedia
c=IN IP4 10.10.10.13
t=0 0
a=X-nat:0
m=audio 4000 RTP/AVP 103 102 104 117 3 0 8 101
a=rtcp:4001 IN IP4 10.10.10.13
a=rtpmap:103 speex/16000
a=rtpmap:102 speex/8000
a=rtpmap:104 speex/32000
a=rtpmap:117 iLBC/8000
a=fmtp:117 mode=20
a=rtpmap:3 GSM/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=sendrecv
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
25
FEEI
3.1.5
DCI
IAX Signaling Protocol
Inter-Asterisk eXchange revision 2 (IAX2 or simply just IAX) is a proprietary protocol
used by the open source Asterisk IP PBX and FreeSwitch Softswitch as an alternative
to SIP, H.323, SKINNY, etc. By default, IAX2 uses UDP as a transport layer protocol
and port 4569. The major difference from the protocols that were described in previous
chapters is that IAX caries the signalization and the audio data traffic in the same channel
and not uses RTP. This makes it more preferable for deployments where Firewalls, NAT
or PAT is used. With IAX if the signalization is working, the audio will work too. It may
not be true for other signalization protocols. The drawback of IAX is in its poor support
from other vendors.
3.1.6
MGCP Signaling Protocol
Media Gateway Control Protocol (MGCP) differs from the previous signalization protocols. MGCP is not used to provide signalization between IP Phones, but MCGP is used
to provide signalization for gateways. MGCP defines a distributed architecture of Media
Gateways (MG) and Media Gateway Controllers (MGC or also Call Agent). MGs connect the VoIP network to other network types. MGs itself in the MGCP architecture are
low-level devices, which are responsible only for media translation (e.g. VoIP to PSTN).
Call routing and rest of the application logic is concentrated in MGCs. MGCs take over
full control over gateways. MGCP is Master-Slave architecture. Bigger service providers,
likely implement MCGP, and its superiors’ Megaco, because MGCP gives them a full
control over a entire network of gateways from one (or more) central point.
3.2
Media Protocols
While signaling protocols provide necessary information required for a call setup, Media
Protocols provide the actual voice transmission over an IP data network. Before the voice
26
FEEI
DCI
Fig. 3 – 5 MGCP Architecture
begins its journey over a data network as an IP packet, it must be first digitalized and
packetized. Next subchapters will introduce techniques, methods and protocols used for
sound digitalization and reliable transmitting in IP data networks.
3.2.1
Voice Codecs
Before voice may be transmitted over an IP data network, sound has to be captured from a
microphone and digitalized. The digitalized sound is then split into small, typically 20ms
sections. These small sound sections are then encapsulated to transmit over an IP data
network, and sequentially sent to the other end, where they are replayed out a speaker.
This process is also called the Packetization.
Sound is captured at a microphone by sampling. The Nyquist theorem says that to reproduce a signal, sampling must occur at twice the maximum frequency. Standard phone
27
FEEI
DCI
Fig. 3 – 6 Sound Digitalization
systems were designed to capture frequencies from 300-Hz to 4-kHz. That means that the
sampling frequency must be 8-kHz. After samples are created, Pulse Amplitude Modulation (PAM) is used to quantize each sample to 256 voltage levels (8-bit number). If 8000
samples are created in one second, each sample is quantized to an 8-bit number, the output
generates a 64kbps raw digital signal (DS0).
Two forms of quantization are used. An earlier developed liner scale called µ-law, and a
logarithmic scale called a-law. µ-law is primarily used in North America and Japan, while
the a-law is used in the rest of the World. The latter a-law benefit from the logaritmic
scale, as it is does a better job for reproducing sound.
After PAM samples are created, they are encoded using a coder/decoder (CODEC). Two
main techniques are using in codecs: Pulse-Code Modulation (PCM) and Code Excited
Linear Prediction (CELP). PCM encodes the digital signal from PAM straight to bits.
CELP uses sophisticated algorithms and predictions methods for encoding the digital
signal. That enables CELP to compress the encoded digital signal and save bandwidth.
Voice quality is measured on a scale called Mean Opinion Score (MOS). MOS of 5 is
perfect, whereas 4 is toll quality and anything less is less acceptable. MOS is a subjecting
voice quality measurement method. For objective measurement, Perceptual Evaluation
of Speech Quality (PESQ) can be used. PESQ values can be easily calculated into MOS
values. Table 3 – 1 contains a list of basic characteristics of main codecs used in VoIP.
Table 3 – 2 contains a list of new emerging codecs that provide higher sound quality, better
performance or bandwidth usage.
28
FEEI
DCI
Codec
Technique
Bandwidth (kbps)
20 ms Sample Size (B)
Quality (MOS)
G.711
PCM
64
160
4.10
G.726
ADPCM
32, 24, 16
80, 40, 20
3.85
G.728
LDCELP
16
40
3.61
G.729
CS-ACELP
8
20
3.92
G.729A
CS-ACELP
8
20
3.90
Tab. 3 – 1 Main VoIP Codecs
Bandwidth (kbps)
Note
GSM
13
-
iLBC
15.2, 13.33
good quality even with packet loss
speex
2 to 44
8, 16 and 32kHz wideband sampling
G.722
48 to 64
7 kHz wideband sampling
Codec
Tab. 3 – 2 Emerging VoIP Codecs
3.2.2
RTP Media Protocol
Voice samples are encapsulated in Realtime Transport Protocol (RTP). RTP PDUs are
encapsulates to UDP datagrams and then to IP packets. Voice does not need the reliability
provided by TCP. TCP provides reliable data transfer, where if a data packet is lost or
damaged it will be retransmitted. This kind of behaviour could cause quality issues for
realtime audio (voice) transmission. For realtime voice transmission it’s more acceptable
to ignore some lost or damages packets, then to wait for their retransmission. By the time
the retransmission happened, the moment to play the sound sample would have passed
and there would be only silence. UDP datagrams provide unreliable data transfer. UDP
datagrams are continuously send in a row and are not retransmitted even when some are
lost. UDP itself does not provide methods for reordering received packets into a correct
order, nor does recognize time between samples. RTP is a protocol used within the UDP
container that adds the necessary features for voice transfer.
29
FEEI
DCI
Fig. 3 – 7 PDU Layout for G.711, G.729 and G.729 with cRTP
As in [8], RTP provides:
• Payload-type Identification
• Sequence Numbering
• Time Stamping
• Delivery Monitoring
The Internet, like other packet networks, occasionally loses and reorders packets and
delays them by variable amounts of time. Received packets are not immediately decoded
and played in speakers, rather they are first put info a buffer and played with a short delay.
We call this buffer as a Jitter Buffer. Jitter buffer, Sequence numbering and Time Stamping
enables RTP on the receiving side to reorder received packets into their correct order, and
provide better voice quality.
As a VoIP packet is transmitted over a data network, it contains a data link header (for
Ethernet it’s 14-Byte header + 4-Bytes CRC trailer), an IP header (20-Bytes), and 8-Byte
30
FEEI
DCI
UDP header and 12-Bytes of RTP. Typically in VoIP 20ms voice samples are packetized.
To each 20ms payload data an additional 58-Bytes overhead are added in the process of
encapsulation. As it’s shown in table 3 – 1, G.711’s 20ms sample size is 160-Bytes. After
adding the RTP, UDP, IP and Ethernet headers, the overhead takes about a quarter of the
transmission. It is even worst when the G.729 codec is used, where the 20ms sample size
is only 20-Bytes. In this case, the overhead takes about 3 times more bandwidth then the
payload. A simple equation of total bandwidth requirements for VoIP turns out to be:
Total Bandwith = (Headers + Sample) * SpS
where the Headers part is the sum of RTP, Layer 4, Layer 3 and Layer 2 headers in
Bytes, the Sample is the site of one voice sample in Bytes and the SpS represents samples
per second. If the phone uses 20ms samples, 50 samples will be created per second
(SpS=50s−1 ). For the G.711, the equation equals to:
(Headers + Sample) * SpS = (14+4B + 20B + 8B + 12B + 160B) * 50s−1 = 10.9kBps
= 87.2kbps
For encapsulated G.729 stream, the total required bandwidth turns out to be 31.2kbps,
while the codec itself generated only 8kbps stream.
To overcome the overhead problem, RTP Header Compression (cRTP) was introduced.
RTP header compression compresses the RTP, Layer 4 and Layer 3 headers from 40 Bytes
to 2 or 4 Bytes labels only. The compression itself is based on remembering the IP, UDP
and RTP headers of the first packet in a media stream, and as if they are almost the
same (same IP addresses, TTL, same ports, etc.) throughout the entire communication,
substituting them later only by small labels. When RTP Header Compression is necessary,
it has to be enabled on a link level at each Layer 3 or upper device.
To save even more bandwidth, Voice Activity Detection (VAD) can be enabled. VAD is
a technology that recognizes when you are not talking and stops generating RTP packets
for that time, thus saving bandwidth. VAD can therefore dramatically reduce demands for
bandwidth and save it for other calls.
31
FEEI
4
DCI
Quality of Service
Different types of communication services have different quality requirements on the
transport network. Applications such as file transfer, e-mail, web browsing do not require
extraordinary values of transfer parameters, but require high bandwidth. On the other
hand, services like VoIP, videoconferencing systems and remote administration tools have
higher needs on the level of interactivity provided by the transport network, but have
lower needs for bandwidth.
4.1
Network QoS Parameters
The quality of a VoIP service depends on 3 basic Network Quality of Service parameters:
• Packet Loss
• Delay
• Jitter
4.1.1
Packet Loss
The Packet Loss parameter defines how many packets were lost on their path from a source
host to a destination host. In VoIP if a packet carrying a voice sample is lost, speakers on
a receiving side will have nothing to play and the sound will be cracked. For VoIP, 0%
packet loss is recommended. Although some codecs may reconstruct the voice even when
a small percentage of media packets is loss.
4.1.2
Delay
The Delay parameter defines an end-to-end one way delay (OWD) caused by the transporting network. Table 4 – 1 shows an ITU recommendation [11] for OWD values in VoIP
32
FEEI
DCI
One Way Delay (ms)
Description
0-150
Recommended range for VoIP
150 - 400
Recommended range for degraded VoIP
Above 400
Inappropriate for VoIP
Tab. 4 – 1 One Way Delay values in VoIP
communication.
4.1.3
Jitter
The Jitter parameter defines the level of delay variation of received packets. As the IP
data network is a packet switched network, each packet may arrive to the destination with
different delay. The delay variation of received packets is called Jitter. Because the jitter
is changing in time, it is not possible to decode and play a voice sample immediately after
receiving it. Otherwise when a sample would be decoded and played out a speaker, the
next sample to immediate decode and play may have not yet arrived. Therefore received
packets are first put into a Jitter Buffer. The Jitter Buffer collects packets, reorders them
into correct order in case they arrived in different order, and creates a small delay to
decoding and playing samples. That enables that even if the delay parameter of each
packet is changing in time, or in other words, the jitter is changing in time, samples are
decoded and played out a speaker linearly in time.
4.2
Measuring Voice QoS
The quality of a realtime voice communication over an IP data network is usually expressed
in Mean Opinion Score (MOS) values. MOS (ITU P.800) is a subjective measurement
method for evaluating voice quality and it is expressed as a single number in the range
from 1 to 5 (table 4 – 2), where 1 is lowest quality, and 5 is the highest quality.
The MOS value is generated by averaging the results of a set of standard, subjective tests,
33
FEEI
DCI
MOS
Quality
5
Excellent
4
Good
3
Fair
2
Poor
1
Bad
Tab. 4 – 2 Mean Opinion Score Values
where a number of listeners rate the heard audio quality. For the main voice codecs, the
corresponding MOS values are shown in Table 4 – 2.
For objective voice quality measurements, several other methods were developed, one of
them is the ITU’s E-model (ITU G.107). The E-model is a complex model and is defined
with a basic equation ([12]):
R = Ro - Is - Id - Ie + A
where:
Ro =S/N at 0 dBr point
Is = Impairments simultaneous to voice signal
Id = Impairments delayed after voice signal
Ie = Effects of special equipment e.g. codecs
A = Advantage factor (to take account of user advantages such as mobility)
The R factor calculated by the E-model ranges from 100 down to 0, where 100 is excellent
and 0 is poor. R factor and can be transformed to a MOS value. The E-model evaluates
the voice quality based on parameters derived from network QoS parameters, codec, etc.
Therefore, it can be implemented by an computing algorithm and implemented in VoIP
network.
34
FEEI
4.3
DCI
Provisioning Network QoS
Real-time applications, such as voice applications, have different characteristics and requirements than traditional data applications. Voice applications tolerate only a little variation
of delay. Packet loss and jitter degrade the quality of the voice transmission that is delivered to the recipient. Therefore, it is necessary to implement QoS techniques into the
underlying transport IP data network, to provide for voice applications required bandwidth
with low values of jitter, delay and packet loss.
When designing a network, it is necessary to consider that in the network with several hops,
the available bandwidth is only as much as the slowest link. When multiple applications,
flows and hosts use the same links, the available bandwidth is shared between applications.
To provide required bandwidth and reliability, networks QoS models were developed.
Three network QoS models exist:
• Best Effort
• Integrated Services (IntServ)
• Differentiated Services (DiffServ)
4.3.1
Best Effort Model
The Best Effort data delivery is the default method. Traffic is send out in the order it arrives
with no differentiation between types of traffic and no guarantee of delivery. Benefits of
the best effort model include its scalability (the Internet is based on best effort delivery),
and its easy of deployment (no need for additional configuration in network).Drawbacks
include the fact that all traffic is given the same service level.
35
FEEI
4.3.2
DCI
Integrated Services Model
The Integrated Services (IntServ) model is a QoS model that guarantees a specific level of
service to each flow of identified traffic, throughout the entire network, for the length of
the session. This is done by using the Resource Reservation Protocol (RSVP). As RSVP
enabled device, application or a router or a communications manager requests a specific
level of service from its next-hop router. A check is made along the path between the two
endpoints, so that each RSVP enabled router in the path reserves bandwidth for that data
flow. If a network is not able to provide the required bandwidth, the session is not allowed
or the quality level is degraded. The drawback of the IntServ model is in its complexity
and it requires that all routers in the network support IntServ services. If one router in a
transmission path does not support IntServ services, quality cannot be guaranteed.
4.3.3
Differentiated Services Model
The Differentiated Services (DiffServ) model groups network traffic into different classes
based on a traffic type and its needs for QoS. For example, voice traffic is placed to a
different class than email traffic. However, email might be placed to the same class as web
traffic. These classes are distinguished from each other based on the value representing
the traffic class in the Layer 3 IP header or Layer 2 headers (e.g. 802.1q tags). Each hop
must be configured to treat that marked traffic the way you want. This is called per-hop
behavior.
In the Layer 3 IP header, the 8 bit Type of Services (ToS) field is used for classifying.
When only the top 3 bits of the ToS field are used, the older IP Precedence is used. Newer
DSCP uses the top 6 bits of the ToS field. The bottom 2 bits of the ToS field are not used
for setting class type. The default DSCP value is zero, which corresponds to the best effort
delivery model.
At Layer 2 the Class of Service (CoS) fields are used. In Ethernet, with 802.1q tagging,
the 3 bits the 802.1p are used for CoS. The value of these 3 bits corresponds to the
36
FEEI
DCI
IP Precedence values. Benefits of DiffServ include many classes of possible services and
scalability. As drawback, it is complex to configure, when a DiffServ configuration change
is applied on one device, it must be applied on the rest of the devices in the network, or at
least the transmission path. DiffServ does not absolutely guarantee a level of service as it
is in IntServ, because the edge devices that start the transmission do not have information
about network paths utilization.
Classification, Marking and Policing are the three main steps that provide network QoS.
Classification classifies packets or flows into QoS classes. The classification process can
be based on several methods: ip address or port matching, application layer analyzation,
etc. Marking is a process that marks packets with information about their priority. At
Layer 3, Marking changes the value of the IP ToS field, at Layer 2 Marking changes the
802.1p tags values. Policing happens on output queues or active network devices, where
VoIP packets can be prioritized against other type of flows.
37
FEEI
5
DCI
Securing VoIP networks
Secure data transportation and delivery have became highly discussed topics of the last
few years. Data Networks Security is a major topic that includes also the problematic of
identity, service access, data confidentiality, validity, etc. Until the present time, security
issues of data networks were separated from telephony networks as they were two different
worlds. Currently as VoIP is a service implemented in data networks, all threats that may
affect data networks security are automatically inherited by VoIP as well. As with many
new technologies, VoIP introduces new security risks and new opportunities for attacks.
Inheriting from both data and telephony networks, VoIP is subject to security issues coming
from both areas.
5.1
Security Threats of Transport Network
As VoIP is a complex topic, security issues starting from Layer 1’s physical connections,
until Layer 7’s faulty applications are included. Threats that affect VoIP can be divided
into several groups:
• Application Security
• Transport Security
– Signaling Security
– Media Protocols Security
VoIP is implemented as a network software application running on IP Phones, Servers
or Routers. It is obvious that as each software application might contain faulty code and
bugs, so does VoIP applications. When these are found and not fixed in quick time, they
may be used to attackers to gain access to service in various forms, or to denying access
to VoIP services by crashing VoIP applications.
38
FEEI
DCI
Transport Security is about security threats in data networks and their affect on VoIP.
Security threats in data networks usually use weaknesses in several layers of the ISO OSI
model.
5.1.1
Layer 1 Security
Layer 1 security aspects include physical access to the datacenter, cabling, access to
switchports and to the network itself. Every device connected to the data network may be
in some situations used as a tool in the attacker’s hand. Therefore, it is needed to consider
network level authentication of devices that want to gain network access. Network Access
Control and Protection (NAC, NAP) uses 802.1x protocol to authenticate devices or users
before providing access to the local network. At higher level, NAC and NAP can even
before providing access to the local network check what applications are running on a
computer, if operating system updates were installed, version of an antivirus, etc.
As electronic devices from time to time get broken, or cables might be cut off, layer 1
security plans should also include solutions for backup links connections to mission critical
systems. Traffic rerouting to backup links is usually a job of higher-level protocols.
5.1.2
Layer 2 Security
Layer 2, Datalink layer is commonly used in several attack techniques. Usually the
weaknesses of the ARP protocol are exploited and used to manipulate traffic flow. In
many situations, an attacker can generate spoofed ARP replies (ARP Spoofing) and can
successfully reroute the traffic from its original path, to the path via attacker’s computer.
This type of attack is called Man In the Middle (MITM) attack. It allows the attacker to
analyze or even change the traffic flow and its contents. Protection against these kind of
attacks can be provided by intelligent L2/L3 switches that are capable of analyzing ARP
packets (DAI - Dynamic ARP Inspection).
39
FEEI
DCI
ARP has a broadcast domain level significance only, separating critical applications from
a local computers VLAN to a separate VLAN increases the security and also provides
higher capabilities to provide network QoS. Modern intelligent switches can have one
native vlan, and at least one auxiary vlan (e.g. voice vlan) configured on a switchport.
This feature allows connecting IP Phones and computers to the same switchport, while
the IP Phones will use the voice vlan, and computers will use the native vlan. For more
experienced attackers, auxiary VLANs might not mean a stop wall. VLAN Hopping attack
is used to gain access to auxiary vlan by emulating an IP Phone. As currently, typically
IP Phones does not have 802.1x supplicants for network level authentication, it might be
difficult to protect against VLAN Hopping attacks.
5.1.3
Layer 3 Security
Layer 3, Network layer attacks are usually based on spoofing source IP addresses. IP
Spoofing attacks can be used to inject attacker’s data packets into a traffic flow. For VoIP,
it might cause call teardown, or when injecting RTP packets, your voice can be replaces by
other audio samples. Routers, as well as intelligent L2/L3 switches may provide protection
against IP spoofing attacks by verifying the source addresses of incoming packets.
Layer 3 security aspects also include routing protocols and routing security. Poorly configured IP routing, without routing updates authentication, might be exploited by an attacker
to change the routing tables of routers, causing traffic rerouting, MITM, DoS attacks or
means to analyze and change the traffic contents.
5.1.4
DNS Security
Security of DNS servers is many times not concerned in security policies, even though
it is a very important network service. Many applications nowadays totally rely on the
DNS system, as in their configuration they use DNS hostnames instead of IP addresses for
accessing servers. Therefore, spoofing DNS records might cause major issues like MITM
40
FEEI
DCI
and DoS attacks.
5.1.5
Uninterruptible Power Supply
A corporate VoIP devices (Servers, IP Phones, Gateways, Switches, Routers, etc.) should
be connected to the Uninterruptible Power Supply (UPS) units to provide functionality
even during a power cut. Power over Ethernet (PoE) distributes electrical power to network devices (e.g. IP Phones, Wireless Access Points, etc.) over the same UTP cables
infrastructure as the data are carried on.
5.2
Major Security Issues of VoIP
VoIP is a converged network service, therefore it brings with itself also security threats
from traditional telecommunications networks. Security issues that are concerned as major
issues for VoIP are:
• Eavesdropping
• Toll Fraud
• Call Spoofing
• Enhanced Emergency Calls
• DoS
• SPIT
5.2.1
Eavesdropping
VoIP itself provides some ways to overcome these issues. Eavesdropping typically require
MITM attack. Encrypted VoIP service protects the privacy of end users even if the MITM
attack was successful. Encryption for VoIP service can be provided by several protocols.
41
FEEI
DCI
IPSEC provides a framework for secure encrypted communication on Layer 3 - network
layer. It does not require any change to VoIP protocols as it is transparent for them. IPSEC
is typically used to provide secure communication between VoIP gateways. Benefits of
IPSEC include the complete security solution and scalability. Drawbacks include difficult
configuration, support in end devices, end-to-end issues with NAT, huge overhead for
VoIP, etc.
Secure SIP (SIPS) runs cleartext SIP over Transport Layer Security (TLS) providing an
encrypted communication channel. TLS is a successor to SSL that is widely for HTTPS
access to web servers on the Internet. TLS uses TCP as a transport protocol, it’s highly
scalable, and easy to implement. To utilize the real power of TLS, certificates from a
trusted certificate authority must be used on each VoIP device.
Secure RTP (SRTP) is a framework for transporting RTP streams in a secure encrypted way.
The encryption is processed with AES. The encryption keys exchange for AES is usually
handled within the call signalization and negotiation. Because the actual encryption keys
are included in the signalization, signalization protocols must be encrypted (e.g. SIPS).
A new specification of SRTP over DTLS moves the encryption keys exchange from
signalization directly to the SRTP negotiation.
ZRTP is a key agreement protocol that performs Diffie-Hellman key exchange during
call setup in the media path, and is transported over the same port as the Real-time
Transport Protocol (RTP). It enables SRTP channel negotiation without a need of providing
encryption keys in call signalization.
5.2.2
Toll Fraud
Toll Fraud is an attack where the goal is in the illicit use of a VoIP infrastructure to place
phone calls. Toll Fraud issues can be overcome by authenticating signaling messages and
users and careful configuration of VoIP services.
42
FEEI
5.2.3
DCI
Call Spoofing
Call Spoofing or a Vishing attack refers to a situation when an attacker is able to successfully masquerade itself as another person. Possible solutions for Call Spoofing protection
are in users’ authentication, identity management, etc.
5.2.4
DoS Attack
A Denial of Service (DoS) attack usually generate directed high load to VoIP servers that
causes a loss of service to users, typically the loss of network connectivity and services
by consuming the bandwidth of the victim network, or overloading the computational
resources of the victim’s system. Protecting against these threats is a job of a firewall and
a good patch management.
5.2.5
Enhanced Emergency Calls
VoIP is continuously replacing traditional telephone systems that had assigned regional
telephone numbers from a PSTN company. VoIP enables users to move with their number
wherever they go. That means an a major issue for emergency calls, which are in the PSTN
normally routed to a nearest emergency station. This service is called E911. The nearest
emergency station decision is based on a called ID (source telephone number) information.
With VoIP, if your caller ID is a number from Kosice, Slovakia, this information will point
to a nearest emergency station in Kosice, even if you are calling from London, UK. In
this case your call will be connected to an emergency station that is hundreds of km from
your actual location. Therefore users must be informed about E911 restrictions when they
travel and use VoIP, and a VoIP service provider should route emergency calls with a caller
ID representing user’s actual location.
43
FEEI
5.2.6
DCI
Spam over IP Telephony
SPam over IP Telephony (SPIT) could mean a major problem for making VoIP more
open. Methods for detecting SPAM delivered through email utilize the asynchronous
communication form of email. A received email can be first checked with an anstispam
solution. Usually text analysis are used to evaluate an email as a spam. That means that
the received email is not immediately delivered to the user’s inbox. For VoIP this kind
of methods are not acceptable as they break the realtime aspect of VoIP communication.
Therefore new methods have to be developed to provide secure and open VoIP service.
SIP Identity Management ([10]), greylisting ([33]), custom IVR scripts and other methods
can be used to protect a VoIP service against SPIT. Before these methods will be widely
used and tested, many VoIP networks will remain closed.
44
FEEI
DCI
IP Phone Alice
IP Address: 10.0.0.2
SIP Port: 5060
Media Port: 17898
Communications
Manager
PAT+Firewall
PAT
IP Phone Bob
IP Address: 192.168.0.2
SIP Port: 5060
Media Port: 23422
INVITE
Codec: G.711
RTP IP: 192.168.0.2
RTP Port: 23422
INVITE
200 OK
200 OK
SRC IP
5.4.3.2
SRC IP
5.4.3.2
200 OK
Codec: G.711
RTP IP: 10.0.0.2
RTP Port: 17898
Codec: G.711
RTP IP: 192.168.0.2
RTP Port: 23422
200 OK
SRC IP
147.232.22.1
Codec: G.711
RTP IP: 10.0.0.2
RTP Port: 17898
INVITE sip:bob@voip
FROM: sip:alice@voip
INVITE sip:bob@voip
FROM: sip:alice@voip
SRC IP
192.168.0.2
INVITE sip:bob@voip
FROM: sip:alice@voip
SRC IP
147.232.22.1
SRC IP
10.0.0.2
Internet
200 OK
Codec: G.711
RTP IP: 10.0.0.2
RTP Port: 17898
Codec: G.711
RTP IP: 192.168.0.2
RTP Port: 23422
ACK
X
X
RTP, Dst IP: 192.168.0.2 Dst Port:23422
RTP, Dst IP: 10.0.0.2 Dst Port: 17898
DROP
Destination IP is a Private IP Address
Fig. 6 – 1 SIP NAT Issues
6
Firewalls, NAT, PAT and VoIP
Signalization Protocols are usually used for call signalization only and the actual voice
transfer is handled by Media Protocols. Before a call is setup, IP Phones negotiate in
signalization IP addresses and Ports on which the media (RTP packets) will flow. With
SIP, SIP itself informs IP Phones about a call request, but information about media is
delivered in the SDP protocol, as part of a SIP message.
Basic Firewalls usually enable any communication sourcing from an inside network to an
outside, and from the outside allow only communication that was previously negotiated
from an inside. NAT and PAT not only does the same restrictions as Basic Firewalls do,
but they even change IP addresses and Port numbers in packets. For VoIP that means
issues for media transfer and signalization (fig. 6 – 1).
45
FEEI
6.1
DCI
Traversal Methods
To resolve media traversal issues with Firewalls, NAT and PAT translations, some of
methods bellow can be used:
• Simple Traversal of UDP through NATs (STUN)
• Traversal Using Relay NAT (TURN)
• Interactive Connectivity Establishment (ICE)
• Application Layer Gateway (ALG)
• Universal Plug and Play (UPNP)
• Session Border Controller (SBC)
6.1.1
Simple Traversal of UDP through NATs
Simple Traversal of UDP through NATs (STUN) protocol enables an IP Phone to discover
whether it is behind a NAT, and to determine its public IP address and the type of NAT.
By finding out the public IP address to which packets from an IP Phone are translated on a
NAT/PAT router, IP Phones can use this information in signalization and define reachable
IP addresses and port numbers in SIP and SDP protocols. The STUN proposal defines a
special STUN server in the public address space to inform the STUN-enabled clients in the
private address space of the Public NAT IP address and port being used for that particular
session. STUN enables signaling and media transfer to happen without any relay. The
drawback of STUN is that it works only for UDP and it does not work with symmetric
NAT.
46
FEEI
6.1.2
DCI
Traversal Using Relay NAT
Traversal Using Relay NAT (TURN) ([9]) was designed to solve the media traversal issue
for symmetric NATs. TURN relies on a server that is inserted in the media and signaling
path. This TURN server is located somewhere in the public address space. The TURNenabled SIP client sends an exploratory packet to the TURN server, which responds with
the public IP address and port used by the NAT to be used for this session. This information
is used in the SIP call establishment messages and for subsequent media streams. The
advantage of this approach is that there is no change in the destination address seen by the
NAT and, thus, symmetric NAT can be used. With TURN, signaling and media transfer is
flowing through a TURN server. That means one extra hop in a flow that can create worse
network QoS parameters.
6.1.3
Interactive Connectivity Establishment
IETF has introduced a framework called Interactive Connectivity Establishment (ICE).
ICE integrates STUN and TURN into a common architecture that tries to find and select the
best way for media transfer. ICE clients exchange reachability information and negotiate
to find one or more connection paths between them. If they establish that there is more
than one possible connection path, they will attempt to select the best quality connection
based on latency and jitter measurements. ICE is currently in its draft version, but many
developers has already adopted it, as ICE provides a pretty good solution for media
traversal that just works.
6.1.4
Application Layer Gateway
Application Layer Gateway (ALG) is a feature of some routers and firewalls, that provides
application level analysis of transferred data. That means that ALG can identify packets
that carry signalization information for VoIP and update them with new information about
47
FEEI
DCI
IP addresses and port mappings for media or signalization flow. ALGs on the other hand
can broke signalization information for new features yet unknown for ALGs.
Universal Plug and Play (UPNP) is a technology targeted to home users that provides
simplification of connecting networked devices together. UPNP provides information
about external IP addresses, dynamically opens pinholes in firewalls and creates port
forwarding for clients. UPNP does not provide authentication and require changes in
applications to support UPNP.
6.1.5
Session Border Controller
Session Border Controller (SBC) is usually a device located at the edge of local or corporate network that provides signalization unification, codec negotiation or transcoding,
detection and traversal for devices behind NAT/PAT/Firewalls, logging, encryption, etc.
Signalization and media flows are flowing through an SBC device. Service providers very
likely use sBCs, as they handle all the issues of NAT/PAT/Firewalls traversal without need
to implement other traversal solutions on a client side. End users can use devices with or
without support for STUN/TURN/ICE/... and experience the same functionality wherever
they are connecting from.
48
FEEI
7
DCI
Call Control and Routing
CO and PBX switches in traditional telephony networks collect dialed numbers from
phones and route calls to their destination based on predefined trunk connections. They
also provide signaling, tone generation and power to phones and have full control over the
phone. IP PBXes receive call setup messages from IP Phones and use their local settings
and voice routing tables to find a path to the dialed telephone number. The voice routing
table contains reachability information for telephone numbers. Two basic call control
architectures exist:
• Centralized
• Distributed
7.1
Centralized Call Control
Centralized call control allows an external device (call agent) to handle the signaling and
call processing, leaving the gateway to translate audio signals into voice packets after
call setup. The call agent is responsible for all aspects of signaling, thus instructing the
gateways to send specific signals or tones at specific times. In larger networks, a centralized
call control is beneficial as it integrates configuration of call routing into a single point. In
VoIP, MGCP and SCCP protocols represent the centralized call control architecture.
7.2
Distributed Call Control
Distributed call control distributes all aspects of call processing into the end devices. Only
the call routing may remain centralized. While in centralized architecture the end devices
may have no inteligence as it is provided by the call agent, with the distributed call control
architecture each end device must implement its own application logic.
49
FEEI
7.3
DCI
H.323 Gatekeeper
H.323 Gatekeeper is a component of the H.323 architecture that provides call control
support and services for H.323 endpoints. H.323 Gatekeepers provide:
• Zone management - The gatekeeper provides zone management for all registered
endpoints in the zone. For example, controlling the endpoint registration process.
• Address translation - Translates H.323 IDs (such as gwy1@domain.com) and E.164
numbers (standard telephone numbers) to endpoint IP addresses.
• Admission control - Controls endpoint admission into the H.323 network.
• Bandwidth control - Consists of managing endpoint bandwidth requirements.
• Call authorization - Restrict access to certain endpoints.
H.323 Gatekeepers centralize call routing logic. A very simple functionality of call routing
with H.323 gatekeepers can be described as:
1. A gateway has received a call request.
2. The gateway sends an admission request to the gatekeeper.
3. The gatekeeper determines how to reach the destination of the call.
4. The gatekeeper sends back to the gateway information how to reach the destination
of the call.
5. The gateway contacts the destination of the call and establishes the call.
7.4
SIP Proxy Server
SIP Proxy Server ([6]) is an intermediary entity that acts as both a server and a client for
the purpose of making requests on behalf of other clients. A proxy server primarily plays
the role of routing, which means its job is to ensure that request is sent to another entity
50
FEEI
DCI
ENUM: +421556027222
VoIP: sip:7222@cnl.tuke.sk
FAX: +421556027001
WEB: www.cnl.tuke.sk
Mobile: +421900343540
...
ENUM
Fig. 7 – 1 ENUM Mapping
”closer” to the targeted user. Proxies are also useful for enforcing policy (for example,
making sure a user is allowed to make a call). A proxy interprets, and, if necessary, rewrites
specific parts of a request message before forwarding it. SIP proxies are elements that
route SIP requests to user agent servers and SIP responses to user agent clients. A request
may traverse several proxies on its way to a UAS. Each will make routing decisions,
modifying the request before forwarding it to the next element. Responses will route
through the same set of proxies traversed by the request in the reverse order.
A call routing process with a SIP Proxy Server is similar to H.323 Gatekeepers.
7.5
ENUM Disributed Directory Procotol
When traditional telecommunication networks and data networks has started to converge
together, a problem of mapping telephone numbers between these two networks has
became visible. While the telephone numbers in traditional telecommunication networks
are numbers in the E.164 format, in IP data networks it can be IP addresses, H323 IDs,
SIP URIs, etc. Dialing an IP address, or a SIP URI on a 12 button telephone dialer could
be very difficult. ENUM is a protocol that solves this issue.
ENUM is a protocol [4], that provides a distributed directory for mapping telephone
numbers in E.164 format to other records (Fig. 7 – 1). ENUM uses the well known DNS
system and NAPTR DNS records to provide its functionality. For the official global ENUM
tree, a DNS zone the e164.arpa. top level domain (TLD) was delegated.
In it’s simplest form, a number of the E.164 form:
51
FEEI
DCI
VoIP
+421556027222
+421556027222
PSTN
If an ENUM record exists for VoIP access,
route via VoIP / Otherwise use PSTN
Fig. 7 – 2 ENUM Call Routing
+421 55 602 7222
is mapped into the DNS under the e164.arpa hierarchy as:
2.2.2.7.2.0.6.5.5.1.2.4.e164.arpa.
This mapping allows a DNS hierarchy of national registrars to generate DNS records
corresponding to well-known telephone numbers. The DNS record used to store ENUM
services is the NAPTR record. The NAPTR records may list one or more ENUM services,
with preferences, for any such number. These might be SIP, H.323 or e-mail services. In
the context of an ENUM-aware application, the application would need to look up the
NAPTR record for a target number, and determine whether a SIP entry existed, and if it
did initiate the call to the listed name.
For the E.164 number from above, the following NAPTR records are found in a DNS
lookup:
$ host -t NAPTR 2.2.2.7.2.0.6.5.5.1.2.4.e164.arpa.
2.2.2.7.2.0.6.5.5.1.2.4.e164.arpa has NAPTR record 100 10 "u" "E2U+sip"
"!∧\\+42155602(....)$!sip:\\1@cnl.tuke.sk!" .
One NAPTR record was found. The found NAPTR record’s order is 100, preference is
10, the record type is E2U+sip which is used to define mapping to ISP URI. The mapping
itself maps the last 4 numbers from the E.164 number to SIP URI: sip:7222@cnl.tuke.sk.
52
FEEI
DCI
VoIP servers can decide how to router the dialed number (Fig. 7 – 2). If a VoIP path is
found in ENUM, then use VoIP as a primary route, otherwise route the dialed number
through the PSTM network.
53
FEEI
8
DCI
Additional Services based on VoIP
As VoIP is a network service of IP data networks, it is easy to implement additional software
services that will interact with VoIP in any possible ways. These services are usually
implemented as a networking software running on computers or servers. Against traditional
telecommunication networks it is a huge advantage. In traditional telecommunication
networks a new service had to be implemented as separate hardware, different vendors
may had used different standards that made compatibility issues, there were not as many
developers for telecommunication application as developers for software applications, so
the price was usually very high even for a simple service. VoIP services nowadays can be
written in almost any programming language with good support of programming tools.
8.1
8.1.1
VoIP Applications
Interactive Voice Response
Interactive Voice Response (IVR) scripts can implement automated attendants that will
interactively navigate users through a voice menu. These services can dynamically interact
with other corporate systems, gather information about callers, etc. In call centers a
customer can be connected always to the same operator that he we speaking with previously
and detailed information about the customer can be displayed on a display of IP phone
even before picking up the call. VoIP services can integrate with local directories and
provide click to dial functions.
8.1.2
Presence Services
Presence Services based on VoIP technologies enable information sharing about your
actual availability, location, preferred contacting method, etc. These information can be
shared with other systems, so other employees may know that you are busy right now
54
FEEI
DCI
because of your presentation on some event. This information can be provided even
without dialing your telephone number. Moving with your number wherever you go and
personalized call routing features are beneficial for everyone who travels a lot, or he or
she has a mobile office.
8.1.3
Video over VoIP
Video-telephoning and videoconferencing are just additional services build on the top of
VoIP technologies. From a technological point of view, adding video support to VoIP means
just one more media stream. Therefore even other services like document sharing, dynamic
collaboration features and multimedia information exchange can be easily implemented
as new VoIP based services.
8.1.4
Unified Communications
Just few years ago a term Unified Communications has been formed. As converged
networks integrated voice and data networks into one common network, Unified Communications is a step even beyond converged networks. Unified Communications (UC)
integrate many, or all communication forms into a single solution build on IP data networks. UC is not just about VoIP, but it’s about emails, presence, video, instant messaging,
etc.
55
FEEI
DCI
Fig. 9 – 1 First IP Telephony Project in SANET
9
VoIP at the Technical University of Kosice
A VoIP network at the Technical University of Kosice (TUKE) has been started developed
in year 2002, with cooperation of the Computer Networks Laboratory (CNL) and the
Slovak Academical Network (SANET) at the First IP Telephony Project in SANET (Fig.
9 – 1). The goal of this project was to use the optical backbone infrastructure of SANET
to build an IP Telephony network between 3 Slovak Universities in Košice, Žilina and
Bratislava. For this project, the Cisco AVVID architecture was selected and implemented.
Two Cisco Call Managers were installed in Kosice and Zilina. Getaways to local PBXes
and Cisco IP Phones were deployed in Kosice, Zilina and Bratislava.
56
FEEI
9.1
DCI
Initial Status Analysis
The work of this thesis has started in year 2005 after finishing the installation of the First
IP Telephony Project in SANET. As the TUKE had assigned from a local Telco numbers
range +421-55-602-XXXX, the 7XXX (+421-55-602-7XXX) numbers were selected for
the IP telephony network.
Cisco Call Manager in version 4.0 was installed and provided services for about 10 Cisco
IP Phones at the Technical University of Kosice. As a communication protocol for IP
Phones, only the SCCP protocol was available. Connection between the PSTN and the IP
Telephony network of the TUKE was not realized because of legal issues with the local
main PBX. IP telephony connection to Zilina and Bratislava from local IP Phones was
provided by H.323 protocol trunks, that were defined as static voice routes on the Cisco
Call Manager. Connection to the Czech Academical VoIP Network (CESNET VoIP) was
provided as well by a static H.323 trunk.
As new protocols like SIP and ENUM have became more popular in the last years, it was
obvious that it is necessary to start moving to SIP and ENUM.
9.2
Possible Solutions for Extending
SIP is currently a de facto standard for signalization between endpoints and for connecting
VoIP networks between each other. Cisco Call Manager in version 4.0 has only a SIP
trunk feature. Only Cisco Unified Communication Manager 5.0 (formerly Call Manager)
or higher has SIP endpoints registration feature. Therefore the Cisco Call Manager in its
current version is not extendable with SIP IP Phones. New solutions for SIP endpoints
registration had to be found. Open Source solution were more preferable with consideration
of future development possibilities.
57
FEEI
9.2.1
DCI
SIP Express Router
SIP Express Router (SER) as in ([13]) is a high-performance, configurable, free SIP server
licensed under the open-source GNU license . It can act as SIP (RFC 3261) registrar,
proxy or redirect server. SER can be configured to serve specialized purposes such as load
balancing or SIP front-end to application servers, SEMS for example. Together with the
RTPproxy software it can act as media relay or Session Border Controller.
SER features complete support of RFC 3261 functionality, a variety of database backends
(mysql, oracle, postgres, radius, text-db), management features (remote management via
XML-RPC, load-balancing), NAT traversal, telephony features (LCR, speeddial), multidomain hosting, ENUM, presence, etc.
SER is additionally enhanced by a variety of additional SIP tools, which provide functionality for management, media processing, CDR processing, etc.
SER has been ported to several unixlike operating systems. It has support for Linux,
NetBSD, FreeBSD and Solaris.
SER supports both IPv4 and IPv6. Becasue of its high performance, flexibility and interoperability, SER is widely used by many service providers. Additional features like
Voicemail, Call Conferecing, IVR, etc. are provided through 3rd party applications.
SER was selected as a main routing engine for SIP for the TUKE VoIP Network.
9.2.2
Asterisk
Asterisk as in ([14]) is a complete PBX in software. It runs on Linux, BSD, Windows and
OS X and provides all of the features you would expect from a PBX and more. Asterisk
does voice over IP in four protocols, and can interoperate with almost all standards-based
telephony equipment using relatively inexpensive hardware.
Asterisk provides Voicemail services with Directory, Call Conferencing, Interactive Vo-
58
FEEI
DCI
ice Response, Call Queuing. It has support for three-way calling, caller ID services,
ADSI, IAX, SIP, H.323 (as both client and gateway), MGCP (call manager only) and
SCCP/Skinny.
For interconnection with digital and analog telephony equipment, Asterisk supports a
number of hardware devices, most notably all of the hardware manufactured by Asterisk’s
sponsor, Digium. Digium has single and quad span T1 and E1 interfaces for interconnection
to PRI lines and channel banks. In addition, single to quad port analog FXO and FXS
cards are available and are popular for small installations.
Asterisk was selected as an IVR service, test service with echo test and as an Back to Back
User Agent (B2BUA) for special applications in the TUKE VoIP Network.
9.2.3
Voice Gateway
Cisco Voice Gateways have long successful history in connecting VoIP networks with
PSTN or other voice networks. As the TUKE already had a Cisco 3725 Router with E1
interface for the First IP Telephony project in SANET, it was decided to use this device
for interconnecting the VoIP network at TUKE with the PSTN network. Because the
main PBX of TUKE does not provided free E1 interfaces, an additional hop was rather
accepted, and the voice gateway was connected to a small Panasonic PBX that was directly
connected to the main PBX and had one free E1 interface.
9.2.4
ENUM Routing
Call Routing configuration with Cisco Call Manager 4.0 was difficult to scale with, because
adding a new reachable VoIP network to its voice routing table required generating a new
static route and a gateway configuration. If some parameters (IP address of the gateway,
port, etc.) were changed in a remote network, administrators had to be informed. If
administrators were not informed about changes in remote voip networks, call routing to
59
FEEI
DCI
these networks was broken. H.323 Gatekeepers could solve this solution by registering
new sited and providing call routing logic. However, this solution was rejected as one of
the goals was to migrate from H.323 trunks to SIP.
The global ENUM tree for Slovakia was for a national trial delegated under the control
of SANET. A Slovak National ENUM Working Group was formed by the Ministry of
Transport, Posts and Telecommunications of the Slovak Republic, where the CNL had a
role of a supporting partner. The 1.2.4.e164.arpa. DNS zone is still managed in SANET. An
ENUM mapping for the TUKE voice network (+421-55-602 - 2.0.6.5.5.1.2.4.e164.arpa.)
was delegated to DNS servers of TUKE. Therefore, any change that was made in the voice
network of TUKE was easily propagated through the ENUM distributed directory. Other
institutions have started with using ENUM for call routing as well. Currently almost all
Slovak Universities use ENUM for VoIP call routing to other institutions.
For testing purposes, a private ENUM tree was created in SANET (e164.bts.sk) and in
CNL (e164.cnl.tuke.sk). These trees were used for testing and setting up additional trunk
connections through ENUM.
9.2.5
Additional Services
Special XML applications were created for Cisco IP Phones. Cisco IP Phones have a
big display that features a browser for web pages written in an Cisco-XML language. A
local and global directory applications were created, as well as rss readers, messaging
applications and screensavers.
Cisco Gateways support TCL scripting language to manipulate call processing. A TCL
script was written that provides caller ID and called name mapping for incoming calls
from the TUKE PBX or PSTN network.
60
FEEI
DCI
Fig. 9 – 2 Final VoIP Architecture
9.3
Final Implementation
The final current look of the VoIP network at the Technical University of Kosice (Fig.
9 – 2 is a result of a common work of several previous Master’s Thesis of CNL members
and this Master’s Thesis.
The Final Implementation has implemented SIP signaling protocol for trunking, call
routing and endpoints registration. Moreover the ENUM protocol has enabled dynamic
and scalable call routing within different educational institutions in Slovakia and the rest
of the World. Handling NAT and Firewall issues enabled TUKE users to use software IP
phones on their laptops while traveling, or having IP Phones at home. Additional value
added services that have been implemented as part of the VoIP network enabled integration
of different information systems used by the TUKE.
First, the Sip Express Router (SER) in a version of 0.9.x series was installed on a Debian
61
FEEI
DCI
GNU/Linux server at the Computer Networks Laboratory’s datacenter. This server is used
as a SIP proxy, registrar and location server, and works also as an SBC with NAT traversal
for the TUKE VoIP network. To provide high performance and high availability features,
a SIP voice domain is created as an DNS record in local CNL DNS servers:
$ORIGIN cnl.tuke.sk.
sip. udp SRV 0 0 5060 stargate.cnl.tuke.sk.
This record defines a SIP domain ”cnl.tuke.sk” that is managed by one SIP server with
hostname stargate.cnl.tuke.sk, uses UDP transport, load balancing order 0, preference 0
and SIP port 5060 which is the default SIP port. After the DNS system configuration, SIP
UAs are able to connect to the SIP voice network just by defining is as a ”cnl.tuke.sk”
domain. Because some broken SIP UAs does not support DNS SRV records, an A-type
record for SER.cnl.tuke.sk was created too:
$ORIGIN cnl.tuke.sk.
ser IN A 147.232.22.70
IP phones that support SIP protocol can register with an username and password to SER.
That enabled the use of several software or hardware SIP IP Phones. User accounts are
stored in a MySQL database and primarily are managed through a command line interface.
The ”serctl” application provides a command line management interface to SER. Serctl
is used for managing user accounts (adding, removing, changing), sip aliases, registration
database, etc. The following command will add a new user account - 7222 - with password
- jahodka - and a contact information for this number will be jozjan@cnl.tuke.sk.
$serctl add 7222 jahodka jozjan@cnl.tuke.sk
A main routing logic is more or less concentrated from each part of the TUKE VoIP
Network to SER. ENUM lookups are enabled in SER’s configuration for incoming call
requests where the called number has a format similar as E.164 numbers:
if( (uri=~"^sip:[0-9]{8,}@") | (uri=~"^sip:\\+.*@") )
62
FEEI
DCI
When a called number meets the requirements, and ENUM DNS lookup is used to find
SIP URIs to the called number. When a lookup is successful, a NAPTR records is returned
from DNS in a form:
2.2.2.7.2.0.6.5.5.1.2.4.e164.arpa has NAPTR record 100 10 "u" "E2U+sip"
"!∧\\+42155602(....)$!sip:\\1@cnl.tuke.sk!" .
This ENUM record is then interpreted as: the called number +421556027222 is reachable
through VoIP on SIP URI: sip:7222@cnl.tuke.sk. In case the called number would not have
any ENUM records, or for some reasons it is not possible to establish a VoIP connection,
SER can fallback to route the call over a PSTN as it was shown on Fig. 7 – 2.
NAT Traversal solutions like STUN, etc. seemed to be not efficient enough and experiences
showed that users have generally problems with NAT Tranversal. Therefore as a definitive
NAT Traversal solution an SBC was selected. SER can provide SBC features for NAT
Traversal with a Mediaproxy or Rtpproxy addons. Rtpproxy is more powerful as it is
written in C, while the Mediaproxy is a python application. An additional advantage
of Rtpproxy over Mediaproxy is support for video streams. For the SBC solution the
Rtpproxy was selected and implemented.
If an incoming call is evaluated as a call behind a NAT, SER will automatically switch
into an SBC mode. In SBC mode the traffic is flowing through the Rtpproxy server. In
native mode, without an SBC the media traffic is flowing directly between endpoints.
Incompatibility issues of some vendors at the SIP/SDP level has forced to create a solution
that will normalize the signalization and make calls possible. For that reason a special
extension handling script was created on Asterisk. That makes Asterisk to work as a
B2BUA to normalize signaling and media streams between devices from different vendors
that have common issues. The actual call redirection to Asterisk is handled by a specific
routing configuration at SER:
##########################################################
# Buggy SIP phones - use Asterisk as B2BUA
63
FEEI
DCI
route[5] {
if (method!="REGISTER") {
# Buggy phone 1, Buggy phone 2, ...
if (uri=~"sip:(7xxx)|(7xxy)|(7xxw)|(7xxz)@") {
if (!(src_ip==147.232.22.70 && src_port==5061)) {
# Routing to asterisk
prefix("b2bua-");
}
else {
append_hf("X-B2BUA: Asterisk\r\n");
}
}
}
}
##########################################################
##########################################################
# Calling to B2B UA @ Asterisk (b2bua-.*@cnl.tuke.sk)
if(uri=~"^sip:b2bua-.*@")
{
route(13);
route(4);
route(1);
break;
};
##########################################################
##########################################################
# Redirection to Asterisk
64
FEEI
DCI
route[13]
{
rewritehostport("127.0.0.1:5061");
}
##########################################################
The Asterisk B2BUA dialing script as in /etc/asterisk/extenstions.conf:
exten => _b2bua-.,1,Dial(SIP/${EXTEN:6}@ser-local)
The Cisco Call Manager’s call routing configuration has been simplified as many previous
entries were deleted and replaced with a single call route pointing to a SIP trunk to SER.
Fig. 9 – 3 displays a screenshot from a call routing tables configuration on the Cisco Call
Manager. Fig. 9 – 4 displays a screenshot from a SIP Trunk configuration on the Cisco
Call Manager.
A Cisco 3725 Router with an E1 interface was setup as a Voice Gateway between the VoIP
and the Local Telephony Network of TUKE. The E1 interface of the router was connected
to a free E1 interface of a Panasonic PBX located in another campus. The Panasonic
PBX is connected to the main TUKE PBX with an optical E1 trunk too. The main TUKE
PBX and the Panasonic PBX were both configured to forward call requests to extensions
starting with 7 (7XXX) to the Voice Gateway. As a signalization protocol on the CCS E1
link between the Voice Gateway and the Panasinic PBX the ISDN Q.SIG was used.
To provide additional functionality for IP Phones, a TCL script was written and implemented on a router that provides caller id and called name identification (Fig. 9 – 5) TCL CLIP. When a call via the E1 interface arrives to the gateway, the TCL script is
started and a VoiceXML script download request is send to PHP web application. Within
the request, the caller ID is included. This information is then used by the PHP script to
find out information in a local telephone directory. The returned VoiceXML file contains
information caller, like caller’s name, department, etc. This information is then used when
a call is beign routed form a Voice Gateway via VoIP signalization protocols, in this case
65
FEEI
DCI
Fig. 9 – 3 Cisco Call Manager Call Routing Configuration
66
FEEI
DCI
Fig. 9 – 4 Cisco Call Manager SIP Trunk Configuration
67
FEEI
DCI
Voice Gateway
6.
1.
ISDN
SIP/SCCP
TUKE
PSTN
2.
VoiceXML
5.
3.
PHP Web
Application
SQL
4.
Telephone Directory
Fig. 9 – 5 TCL Based CLIP Functionality
via SIP.
For Cisco IP Phones a Cisco-XML web based telephone directory application was created (TUKE Yellow Pages). The server side was written in PHP and SQL. The telephone
directory database is the same as the one for the TCL CLIP service. To integrate the
directory application, a special Cisco-XML file had to be created and defined as a corporate directory location. Cisco IP Phones can reach this directory just by clicking on the
Directory button and select the TUKE Yellow Pages application (Left @ Fig. 9 – 6). The
application’s menu is simple, it has only one input box for the searched person (Middle
@ Fig. 9 – 6). After clicking on the search button, the server side application searches the
database and generates output in a Cisco-XML format that is displayed on the IP Phone’s
display (Right @ Fig. 9 – 6). While developing the directory application, DTD validation
of a generated XML file was a very troubleshooting method when the IP Phone did not
68
FEEI
DCI
Fig. 9 – 6 TUKE Yellow Pages
work with the application. Usually it was because of bad XML formatting. End users
really appreciated this application, especially on places without computers.
After testing and evaluating the final implementation, it turned out that the solution is
scalable, it provides good possibilities to test several VoIP technologies and systems as
the new network provides heterogeneous architecture. H.323, SIP, AIX, MGCP and other
protocols can be tested in this network.
69
FEEI
10
DCI
Conclusion
This Master’s Thesis was designed to cover VoIP as a technology, that not only can
replace traditional telecommunications networks, but brings a new way and possibilities
of realtime multimedia based communication with required quality in IP data networks.
The goal of this Master’s Thesis was to introduce a theoretical background required to
understand VoIP, best practices in usage and implementation with currently developing
VoIP standards, solutions for handling general issues of VoIP implementations and a design
and an implementation of a scalable VoIP network for the environment of the Technical
University of Kosice.
The work in thesis analyzed the existing situation of the VoIP network at the Technical
University of Kosice that remained after the First IPT project in SANET. The VoIP
network used a Cisco Call Manager 4.0 server for Cisco IP Phones management and
call routing. Interconnection with different universities or institutions sometimes required
major configuration changes on both sites. Information about changes in trunking or
system configuration must have been propagated manually. When more institutions that
are educational started to use VoIP, this kind of trunking configuration was not efficient
and not scalable.
A solution for extending this network was proposed and implemented in the practical
work of the thesis. Within this process new servers and services for VoIP were installed
in the infrastructure of the Computer Networks Laboratory at the Technical University of
Kosice.
Extending the VoIP network with SIP support for IP Phones brought support for 3rd party
VoIP solutions, softphones and applications. Sip Express Router (SER) was selected as a
software solution for the SIP part of the VoIP network. Moreover, SIP has started to be
used globally in Slovak Educational institutions (Universities, High Schools, Ministry of
education, etc.).
70
FEEI
DCI
For easy access to the voice network of the Technical University of Kosice from other
institutions, a global ENUM zone, corresponding to the telephone numbers assigned from
Telco, was delegated and configured on the DNS servers of the Technical University of
Kosice. Everyone who is using ENUM and SIP is able to connect to the voice network of the
Technical University of Kosice. Call routing based on ENUM lookups was implemented
and configured on SER and the major call routing from the old VoIP network was moved
and integrated on SER.
To provide access to the VoIP network from home or from remote networks, and to
overcome the issues of NAT traversal, SER was also configured with the Rtpproxy as a
Session Border Controller (SBC). SER in SBC mode detects if a client is from a remote
network or it is behind NAT, and provides a working NAT traversal solution.
The Asterisk IP PBX was implemented to provide IVR scripts and to handle issues between
IP Phones from different vendors. To crossconnect the standard telephony network at
TUKE, a Cisco 3725 router with an E1 interfaces was connected to a Panasonic PBX.
The router was configured as a voice gateway with SIP and H.323 support for VoIP.
Communication through the E1 interface with the telephony network of the TUKE and
the PSTN was established with ISDN Q.SIG and Q.931 protocol. The router’s support
for TCL scripts was utilized and a script for caller id and caller name identification
was written. The TCL script uses an VoiceXML page, dynamically generated by a web
application written in PHP and a corporate directory stored in a MySQL database.
Utilizing the feature of Cisco IP Phones with an Cisco-XML browser, several application
were written to provide access to local directories, rss feeds, weather information, etc.
Quality of Service settings with traffic policing were implemented in a manageable network
infrastructure of CNL. Switches and routers were configured to prioritize voice service
against other network services. Cisco’s auto-qos macros were used for easy configuration.
On places where the network supported Power over Ethernet, electrical power to IP
Phones was provisioned through the same UTP cable that was used for communication
71
FEEI
DCI
with network.
The proposed solution did not covered all features that were described in this thesis.
Security, advanced Quality of Service, Unified Communications and Additional Services
for VoIP are topics that are open for future work in other master’s thesises.
The current look of the VoIP network at the Technical University of Kosice (Fig. 9 – 2 is a
result of a common work of this and several previous Master’s Thesises of CNL members.
The current architecture is stable, scalable and ready for building and developing new
services and applications for VoIP.
72
FEEI
DCI
Bibliography
[1] Cassidy, Carol-June. 2007. Cambridge Dictionary of American English. Cambridge: Cambridge University Press, 2007 2nd edition.
ISBN-9780521691970
[2] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks,
M. Handley, E. Schooler. 2002. SIP: Session Initiation Protocol
RFC 3261
[3] F. Andreasen, B. Foster. 2003. Media Gateway Control Protocol (MGCP)
RFC 3435
[4] P. Faltstrom. 2000. E.164 number and DNS
RFC 2916
[5] Cisco Systems. 2003. SIP Call Flows [online] April 2008
http://www.cisco.com/univercd/cc/td/doc/product/voice/c ipphon/sip7960/sadmin31/bsipcflw.htm
[6] A. Johnston, S. Donovan, R. Sparks, C. Cunningham, K. Summers. 2003. Session
Initiation Protocol (SIP) Basic Call Flow Examples
RFC 3665
[7] M. Handley, V. Jacobson, C. Perkins. 2006. SDP: Session Description Protocol
RFC 4566
[8] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson. 1996. RTP: A Transport
Protocol for Real-Time Applications
RFC 1889
[9] J. Rosenberg, R. Mahy, P. Matthews. 2008. Traversal Using Relays around NAT
(TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN). [online]
April 2008
73
FEEI
DCI
draft-ietf-behave-turn-07
http://tools.ietf.org/html/draft-ietf-behave-turn-07
[10] J. Peterson, C. Jennings. 2006. Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)
RFC 4474
[11] SERIES G: TRANSMISSION SYSTEMS AND MEDIA, DIGITAL SYSTEMS
AND NETWORKS International telephone connections and circuits – General
Recommendations on the transmission quality for an entire international telephone
connection, One-way transmission time
ITU G.114 (2003)
[12] ITU-T Recommendation G.107.
The E-model, a computational model for use in transmission planning.
http://www.itu.int/
[13] iptel.org. 2008. Sip Express Router description. [online] April 2008
http://www.iptel.org/ser/
[14] voip-info.org. 2008. Asterisk description. [online] April 2008
http://www.voip-info.org/wiki-Asterisk
[15] K. Brown. 2004. Ip Telephony Unveiled. Indianapolis: Cisco Press, 2004.
ISBN-1587200759
[16] D. Minoli, E. Minoli. 1998. Delivering Voice over Ip Networks. New York: John
Wiley, 1998.
ISBN-471254827
[17] Syngress et.al. 2001. Configuring Cisco Avvid. Publishing, Syngress et.al. City:
Syngress, 2001.
ISBN-1928994148
[18] P. Loshin. 2001. Big Book of Ip Telephony Rfcs. San Diego: Morgan Kauf74
FEEI
DCI
mann/Academic Press, 2001.
ISBN-0124558550
[19] K. KLEINOVÁ, F. JAKAB, M. JAKAB, J. JANITOR, M. VOZÁR. 2005. New form
of effective communication in academic sphere VoIP as supporting instrument of elearning Conference Proceedings of the 4th International Conference on Emerging
e-learning Technologies and Applications, Slovak Republic, 13 - 14 September
2005, Košice, elfa s.r.o., 2005, pp. 179-185
ISBN 80-8086-016-6
[20] F. JAKAB, KLEINOVÁ, M. VOZÁR, M. JAKAB, J. JANITOR. 2006. Possibilities
to provide VoIP with required quality. Electronic computer and informatics ECI
2006, Košice-Herlany, September 2006, ELFA, 2006, 255-261pp.,
ISBN 80-8073-598-0
[21] R. Barbuš. 2004. Implementácia IP Telefónie na báze infraštruktúry SANET. Master’s Thesis. 2003. Technical University of Kosice.
[22] K. Kleinová. 2004. Implementácia IP telefónie na báze siete SANET. Master’s
Thesis. 2004. Technical University of Kosice.
[23] M. Vozár. 2006. Implementácia hlasových služieb v prostredı́ dátových sietı́. Master’s Thesis. 2006. Technical University of Kosice.
[24] M. Jakab. 2007. Bezpecnost VoIP. Master’s Thesis. 2007. Technical University of
Kosice.
[25] J. Janitor, F. Jakab, V. Murı́n. 2006. ENUM.
ISBN-8080860300
[26] Cisco Systems. 2006. Understanding H.323 Gatekeepers [online] April 2008
http://www.cisco.com/warp/public/788/voip/understand-gatekeepers.html
[27] UPNP Forum. 2008. About UPnP Technology [online] April 2008
http://www.upnp.org/about/default.asp#technology
75
FEEI
DCI
[28] Zfone Project. 2008. The Zfone Project [online] April 2008
http://zfoneproject.com
[29] Newport Networks. 2008. White Paper - NAT Traversal Solutions for Multimedia
over IP Services [online] April 2008
http://www.newport-networks.com/whitepapers/nat-traversal2.html
[30] Cisco Systems. 2008. Overview of SIP Security [online] April 2008
http://www.cisco.com/en/US/docs/ios/12 3/vvf c/cisco ios sip security applica
tion guide/sipsecov.html
[31] T. Dierks, C. Allen. 1999. The TLS Protocol
RFC 2246
[32] Wikipedia. 2008. Secure Real-time Transport Protocol [online] April 2008
http://en.wikipedia.org/wiki/Secure Real-time Transport Protocol
[33] Wikipedia. 2008. Greylisting [online] April 2008
http://en.wikipedia.org/wiki/Greylisting
[34] IXIA. 2008. Assessing VoIP Call Quality Using the E-model [online] April 2008
http://www.ixiacom.com/library/white papers/display?skey=voip quality
[35] B. Stewart, D. Donohue. 2007. CCNP ONT Quick Reference Sheets. Electronic
edition.
ISBN-15870503152
76
Appendices
Appendix A CD medium - Master’s Thesis in its electronic form, configuration files of
Sip Express Router, Asterisk, Voice Gateway, ENUM DNS configuration files, SIP
domain DNS configuration files, TCL scripts, source code of the TUKE Yellow
Pages, source code for the CLIP VoiceXML application.