Implementing a Voice Over Internet (Voip) Telephony System
Implementing a Voice Over Internet (Voip) Telephony System
Md. Manzoor Murshed
Final Project Report for the course CprE550: Distributed Systems and Middleware
ABSTRACT
This Project is to describe the architecture and implementation of Internet telephony Systems. It works with the
traditional telephone networks via a PSTN/IP gateway. It also serves as a corporate or campus infrastructure for existing
and future services like web, email, video and streaming media. We will also discuss common inter-operability
problems between the PBX and the gateway. Finally we implemented a VoIP system using Westplan simulator and
analyzed the traffic.
Keywords: VoIP, PSTN/IP interoperability, SIP, H.323, RTP, PBX, SDP, MGCP, Westplan.
1.
INTRODUCTION
Telephony service today is provided for the most part over circuit-switched networks, which are referred to as Public
Switched Telephone Networks (PSTN). This service is known as Plain Old Telephone Service (POTS). A new trend
that is beginning to emerge in recent years is to provide telephony service over IP networks, known as IP telephony, or
Voice over IP. An important driving force behind IP Telephony is cost savings, especially for corporations with large
data networks. The high cost of long-distance and international voice calls– is the crux of the issue. A significant
portion of this cost originates from regulatory taxes imposed on long-distance voice calls. Such surcharges are not
applicable to long-distance circuits carrying data traffic; thus, for a given bandwidth, making a data call is much less
expensive than making a voice call. In addition to the cost savings for long-distance voice calls, carrying voice traffic on
the data network within a business building or campus also can achieve substantial cost savings, since the operation of
today's proprietary PBX setups is relatively cost-inefficient. There are other very significant motivating factors for
carrying voice traffic over data networks as well. A very important benefit of IP Telephony is the integration of voice
and data applications, which can result in more effective business processes. Examples of such applications are
integrated voice mail and e-mail, teleconferencing, computer supported collaborative work and automated and
intelligent call distribution. Another benefit is the enabling of many new services both for businesses and for customers.
The flexibility offered by IP Telephony by moving the intelligence from the network to the end stations, as well as the
open nature of IP networks, is the factors that enable new services. Furthermore, many of the existing services that
require a fee today, such as caller-id, call-forwarding, and multi-line presence become trivial to implement; therefore,
such services are likely to be offered for free for competitive reasons. In order for IP Telephony to gain mainstream
acceptance and ultimately replace traditional Plain Old Telephone Service (POTS), two conditions have to be met. First,
the quality of the voice communication must be at least at the same level as POTS. The two primary aspects of voice
quality are the end-to-end delay, and the voice clarity (which depends on many factors, including the voice digitization
and compression scheme used, and the amount of lost or late-arrived packets). Therefore, the IP network must be
designed such that it can meet the delay and packet loss requirements of the telephony application. The second
condition for the acceptance of IP Telephony is the ease of operation and functionality offered to the end user at least at
the same level as in PSTN. This requires the IP Telephony architecture to provide a signaling infrastructure that offers
at least the same capabilities and features as the Signaling System 7 (SS7) architecture in PSTN. More specifically, the
signaling infrastructure must:






provide the functionality required to set up, manage, and tear down calls and connections;
be scalable to support a very large number of registered endpoints (in the order of billions worldwide), and a
very large number of simultaneous calls (in the order of millions worldwide);
support network management features for policy control, accounting, billing, etc;
provide a mechanism to communicate and set up the Quality of Service requested by the end points;
be extensible to help with adding new features easily;
support interoperability among different vendors’ implementations, among different versions of the signaling
protocol, and with different signaling protocols.
Two standards compete for IP Telephony signaling. The older and currently more widely accepted standard is the ITUT
recommendation H.323, which defines a multimedia communications system over packet-switched networks, including
IP networks. The other standard, Session Initiation Protocol (SIP), comes from the IETF MMUSIC working group. In
this project we will try to implement a Voip system using SIP.
Page 1 of 11
Implementing a Voice Over Internet (Voip) Telephony System
Section 2 gives an overview of SIP. Section 3 explains SIP components and messages. Section 4 explains signaling
standards. Section 5 gives an overview of H.323. Section 6 explains H.323 signaling. Section 7 briefly explains MGCP
protocol. Section 8 and 10 gives Westplan simulator setup for two simulations. Section 9 analyzes the simulation results
and finally section 11 gives conclusions.
2.
OVERVIEW OF SIP
For an Internet audio call, it is sufficient for a participant to know the audio algorithms supported by the other
participant and the IP address and port number at which to send the audio packets to the other participant. The problem
with this is that IP addresses are hard to remember and may change if the user changes his location or machine. SIP
allows use of a more high level address of the form user@domain for user mobility. For instance, a user can call
bob@office.com no matter what communication device, IP address or phone number he is using currently. The current
locations of the users are maintained by the SIP (location or registration) servers. When Alice, with address
sip:alice@home.com, wants to call Bob, sip:bob@office.com, her SIP phone contacts the server at office.com. The
server knows where Bob can be reached and can either return Bob's location to Alice's phone (in redirect mode) or can
itself try to contact Bob at his current location (in proxy mode). In the former case, Alice's phone retries the new
location, while in the latter case the server proxies the request transparent to the caller. It is possible to encounter
multiple SIP servers (either in redirect or proxy mode) in a given call attempt. A forking proxy can fork the call request
to more than one location, so that the first phone that is picked up gets the call, while all other phones stop ringing.
SIP calls can also use “tel" URLs that identify E.164 telephone numbers, for example, tel:+1-212-555-1234. The list of
supported audio and video algorithms and the transport addresses to receive them are described using Session
Description Protocol (SDP), carried in SIP requests and responses.
SIP Servers are essential network elements that enable SIP endpoints to exchange messages, register user location, and
seamlessly move between networks. SIP Servers enable network operators to install routing and security policies,
authenticate users and manage user locations. SIP Server applications may take many forms, but the SIP standard
defines three general types of server functionality that apply to all - Proxy, Redirect and Registrar servers. These
standard functionalities can be used according to the needs of the specific implementation.
Registrar Server: The SIP standard defines a registrar server as “a server that accepts REGISTER requests and places
the information it receives in those requests into the location service for the domain it handles”. REGISTER requests are
generated by clients in order to establish or remove a mapping between their externally known SIP address(es) and the
address(es) they wish to be contacted at. The REGISTER request can also be used to retrieve all the existing mappings
saved for a specific address. The Registrar processes the REGISTER request for a specific set of domains. It uses a
“location service” - an abstract location database - in order to store and retrieve location information. The location
service may run on a remote machine and may be contacted using any appropriate protocol (such as LDAP). The SIP
standard leaves this decision to the implementation. Some implementations may co-locate the location service and the
registrar server on the same machine. A registrar server may authenticate incoming REGISTER requests using the 401
(Unauthorized) responses.
Figure 1: Registration Process
Redirect Server: Redirect server functionality is the simplest of the three functionalities. A redirect server receives SIP
requests and responds with 3xx (redirection) responses, directing the client to contact an alternate set of SIP addresses.
The alternate addresses are returned as Contact headers in the response message. Some 3XX responses are 300 Multiple
Choices, 301 Moved Permanently, 302 Moved Temporarily, 305 Use Proxy, 380 Alternative Service. In most cases,
301 and 302 responses are used by redirect servers. 300 can also be used, although it is more ambiguous to the calling
client.
Page 2 of 11
Implementing a Voice Over Internet (Voip) Telephony System
Proxy Server: The SIP standard defines SIP proxies as “elements that route SIP requests to User Agent Servers (UAS)
and SIP responses to User Agent Clients (UAC). 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. The SIP specification defines two types of SIP
proxies, Stateful proxy and Stateless proxy. A stateless proxy is a “simple message forwarder”, as described in the SIP
standard. When receiving a request, the stateless proxy processes the request much like a stateful proxy, however the
stateless proxy forwards the message in a stateless fashion - without saving any transaction context. This means that
once the message is forwarded the proxy “forgets” ever handling this message.
3.
SIP COMPONENTS AND MESSAGES
There are two key components in a SIP-based network, User Agents and Servers, which yield a straightforward,
simplistic operation. The SIP User Agents contain a User Agent Client (UAC) and a User Agent Server (UAS). The
UAC function initiates the SIP requests, while the UAS function contacts the user when a request is received and
returns a response on behalf of that user. The response may be an acceptance, a rejection, or a redirection of the request.
A SIP server may also be deployed to perform specific functions within the network. A Proxy server makes requests on
behalf of other clients and possibly translated a message, as necessary, before forwarding. A Redirect server accepts a
SIP request, maps the address into another address, and then returns the new address to the Client. The Registrar server
accepts REGISTER requests and may be co-located with the Proxy or Redirect servers. Finally, the location server
provides a service to the Proxy or Redirect servers by obtaining information regarding SIP server.
SIP components are identified with a SIP Uniform Resource Locator, or URL, which takes a form similar to that used
with e-mail systems, such as user@host. The user part could consist of a user name or telephone number, while the host
part could consist or a domain name or a numeric network address. A SIP message can either be a request from a client
to a server, or a response from a server to a client. The request message defines the operation requested by the client,
while the response message provides information from the server to the client indicating the status of that request. There
are six types of request messages, distinguished by what is called a method:
1.
2.
3.
4.
5.
6.
Invite: Indicates that the user or service is being invited to participate in a session.
Ack: Confirms the client has received a final response to an Invite request.
Options: Is used to query a server about its capabilities.
Bye: Is sent by a User Agent Client to indicate to the server that it wished to release the call.
Cancel: Is used to cancel a pending request.
Register: Is used by a client to register an address with a SIP server.
The response messages contain Status Codes and Reason Phrases that indicate the current condition of a request. The
status code values are divided into six general categories:
1.
2.
3.
4.
5.
6.
1xx: Informational- The request has been received and processing is continuing.
2xx: Success – An Ack, which indicated that the action was successfully received, understood, and accepted.
3xx: Redirection – Further action is required to process this request.
4xx: Client Error – The request contains bad syntax and cannot be fulfill at this server.
5xx: Server Error – The server failed (for internal reasons) to fulfill an apparently valid request.
6xx: Global Failure – The request cannot be fulfilled at any server.
Figure 2: Architecture
Page 3 of 11
Implementing a Voice Over Internet (Voip) Telephony System
4.
SIGNALING STANDARDS FOR CONVERGED NETWORKS
Converged networks are composed of a number of elements (Figure 3). Suppose we wish to communicate over an IPbased infrastructure. The communications path will include a Voice over IP client application; a local network that
supports IP; and a wide area network that supports IP, such as an ISDN or a T1 line. The communication path gets
established by signaling. Signaling is defined as the procedure or procedures undertaken to establish (or set up), manage
(or supervise), and terminate (or disconnect) a communication session between two endpoints. There are several
assumptions built into these procedures. First, it must be assumed that the two end-points have a need to communicate,
and that need is being driven by some higher layer protocol or process (such as an application like an e-mail client that
needs to communicate with the e-mail server, or a human who needs to call home). Second, it must be assumed that
these two endpoints have the ability to reach each other, share a common addressing scheme, and have some way of
determining each other’s address. Third, the signaling procedures may have to traverse several networks, possibly using
different protocols, in order to reach the destination. For example, if the call is initiated on an IP-based network but
terminated on a analog telephone attached to the PSTN, both IP-based and PSTN-based signaling will be involved
(figure 4).
H.323 Terminal
(Connected via PPP)
H.323 Terminal
(Connected via PPP)
PPP Access Server
Channelized T1/E1
UTP-3 cable
PSTN
Collapsed backbone hub
Router
H.323 Terminal
(Connected via PPP) H.323 Terminal
(Connected via PPP)
H.323 Gatekeeper
Voip-H323 Gateway
IP
Network
T1/E1, T3/E3 OC-3
Analog
DNS Server
PSTN
Analog Phone
ISDN
Wireles
s
Executive Phone
Wireless Phone
PBX
Figure: 3 Voice Over IP Network Elements
Page 4 of 11
Implementing a Voice Over Internet (Voip) Telephony System
Thus the signaling functions can be divided into two broad categories: signaling that occurs within the telephone
network, and signaling that occurs within the packet network. Signaling within the PSTN is defined by a protocol
known as Signaling System 7 (SS7), defined by the ITU-T for international calls (5) and by ANSI for calls within the
United States (6). PNTN signaling is divided into two elements. The first part occurs between the telephone set and the
local central office switch and is known as subscriber loop signaling. Loop signaling conveys indications of on/off hook
status, ringing signals, and so on to the subscriber’s terminal. The second part, known as inter-exchange signaling,
conveys call information between central office switches.
Signaling within the packet network can be accomplished using some combination of four protocols: the H.323,
developed by the ITU-T; the Session Initiation Protocol (SIP), developed be the IETF; the Media Gateway Control
Protocol (MGCP), developed by the IETF; and MEGACO/H.248 protocol, jointly developed by the IETF and the ITUT. Depending on the network architecture and the components involved, one or more of these protocols may be
deployed, although, some provide very similar functions and would not necessarily be used simultaneously.
PSTN
Analog
Telephone
IP Telephone
Voip-PSTN
Gateway
Voip-Neowork Signaling
Inter-exchange Signaling
(SS&)
Subscriber Loop
SIgnaling
Figure 4: Signaling Systems and Messages
5.
THE H.323 MULTIMEDIA STANDARD
H.323, was developed by ITU-T and is currently in its fourth revision. The original title of the ITU-T H.323 standard,
approved in 1996, was lengthy but described its purpose: “Visual Telephone Systems and Equipment for Local Area
Networks Which Provide a Non-guaranteed Quality of Service”. Therefore it has two key elements: visual telephone
systems (in contrast to just audio telephone systems) and their use over LANs that do not provide a guaranteed quality
of service, or QoS. H.323 assumes that the transmission medium is a LAN that does not provide guaranteed packet
delivery. A typical Ethernet would be a good example – if two Ethernet workstations transmit at the same time, a
collision occurs. Since the probability of such a collision is difficult to predict, defining a specific quality of service is
also difficult. Other standards in this family address other network types, such as H.320 (ISDN), H.321 (ATM), and
H.324 (low bit rate connections), or, the case of H.322, networks that provide QoS guarantees. Thus, the H.323 standard
is designed to work with the local and wide area network types that are most commonly found – those that do not
provide guarantees on the QoS provided. In addition to the network implementation standards, there are other standards
that fall within the H.323 recommendation. These include: H.225.0, Terminal to Gatekeeper signaling functions; H.245,
Terminal control functions that are used to negotiate channel usage, capabilities, and other functions; Q.932, Call
Page 5 of 11
Implementing a Voice Over Internet (Voip) Telephony System
signaling functions to establish and terminate the call and T.120, Data conferencing, which might include shared
whiteboarding and still image transfer applications. The various building blocks that comprise a typical H.323 network
are illustrated in Figure 5. The building blocks imply each of the functions is in a distinct box. However, one physical
box often contains more than one functional element. For example, both MCU and Gatekeeper functions could be
located in the same physical device. A typical H.323 environment might include Gateways to other networks, such as
the PSTN or ISDN.
H.323 MCU
H.323 Terminal
Packet Based Network
H.323
Gatekeeper
H.323 Gateway
H.323 Terminal
H.323 Terminal
Figure 5: H.323 Building Blocks
6.
H.323 SIGNALING
Call signaling is defined in H.323 environments to establish a call, to request changes in the bandwidth of that call, to
determine the status of endpoints associated with the call, and to terminate or disconnect the call. The call signaling
messages are specified in H.225.0. H323 entities are identified using two levels of addressing structures, a Network
address and a TSAP identifier. The Network address is a unique identifier for that entity on the network and is specific
to that network environment in which the entity resides. Fore the case of IP-based networks, the Network address would
be the IP address assigned to the device. The TSAP identifier is used to multiples several Transport Layer connections
into and entity that has a single Network address. The term TSAP comes from the Transport Service Access Point – an
addressing scheme used at the OSI Transport Layer and defined as part of the Open Systems Interconnection Reference
Model. For IP applications, the TSAP could be the UDP or TCP port number. H.225.0 defines the transmission of
H.225.0 messages over various transport protocol stacks, including UDP/IP and TCP/IP, and gives examples of
addresses to be used.
The Gatekeeper is the device that controls access to the network. When endpoints are initialized on networks that
contain a Gatekeeper, they register their presence with the Gatekeeper. The logical channel that is used to carry that type
of communication between endpoints and Gatekeeper is called the Registration, Admissions, and Status channel, or
simply RAS for short. The RAS channel is known as un unreliable channel, meaning that for IP-based networks it
would use UDP/IP (the most efficient connectionless transport) instead of the more rigorous TCP/IP transport (called a
reliable channel). Since it is possible for multiple Gatekeepers to exist on a network, each endpoint uses a process
known as Gatekeeper Discovery, which may operate either manually of automatically, to determine which of the
Gatekeepers to register with. The manual process provides a static association, such as from a configuration file. The
automatic process is called Auto Discovery.
7.
GATEWAY CONTROL PROTOCOLS: MGCP
SIP and H.323, that are primarily deployed to control end stations, such as multimedia terminals or video-conferencing
systems. These protocols may be resident within the applications or operating systems of these end stations, enabling
the end stations to initiate, control, and terminate a call. However, when dissimilar networks are involved in the
communication path, such as a workstation attached to an IP network calling an analog telephone connected to the
PSTN, gateways between those networks must get involved. A second category of signaling protocols is thus required
between the telephone gateway to control their operation and establish paths between those dissimilar networking
environments.
Page 6 of 11
Implementing a Voice Over Internet (Voip) Telephony System
The Media Gateway Protocol (MGCP) was developed by the IETF (7). The MGCP specification details the commands
and parameters that are passed between the MGC (call Agent) and the telephone gateway to be controlled. The call
control element is referred to as a Call Agent in MGCP. Thus, the purpose of MGCP is to send commands from the Call
Agent to one of the above types of gateways in a master/slave fashion. MGCP does not define any communication
mechanism for synchronization between Call Agents. MGCP further assumes a connection model and defines both
endpoints and connections. Endpoints are sources or sinks of data and can be either physical or virtual. Endpoints
identifiers have two components: the domain name of the gateway that is managing the endpoint, and a local name
within that gateway. Connections can be either point-to-point or multipoint in nature. Further connections are grouped
into calls, where one or more connections can belong to one call. The connections and calls are established by the
actions of one or more Call Agents.
The information communicated between Call Agents and endpoints is either events or signals. An example of an event
would be a telephone going off hook, while a signal may be the application of dial tome to an endpoint. These events
and signals are grouped into packages, which are supported by a particular type of endpoint. One package may support
events and signals for analog lines, while another package may support a group of events and signals for video lines.
Some of these packages are, generic media, DTMF, MF, Trunk, Line, Handset, RTP, Network Access Server,
Announcement Server, and Script. Each on these had specific functions and parameters.
8.
SIMULATION #1 WITH WESTPLAN SIMULATOR
Figure 6: Voice over IP modeling using Westplan
Figure 7: Link Summary
Page 7 of 11
Implementing a Voice Over Internet (Voip) Telephony System
Figure 8: Westplan Network Optimization
Figure: 9: Westplan Optimization Results
9.
ANALYSIS OF THE SIMULATION DATA
9.1 Project wide VoIP calculations:
The following calculations apply to the project wide Voice over IP variables and are used for the bandwidth calculations
on each link:
Voice IP datagram calculations: The selected interval of 20ms (2 samples) and the voice activity percentage of 100%
result in 50 IP datagram per second being generated which contain active voice samples.
The size of the voice payload in each datagram is 160 bits (20 octets) using the G.729B (CS-CELP) 8k compression
scheme. IP, UDP and cRTP (4 bytes) add an overhead of 32 bits, making the total size of each datagram 192 bits (24
octets). The Voice Activity was set to 100%. Therefore, no Silence Insertion Description frames will be transmitted.
RTCP IP datagram calculations: 0.2 control packets are generated each second. This is the maximum frequency
suggested by RFC 1889. From RFC 2508, we assume that the RTCP payload size will be 496 bit (62 octets). IP and
UDP headers add an overhead of 224 bits (taking the chosen header compression scheme into account), making a total
RTCP IP datagram size of 720 bits (90 octets).
Page 8 of 11
Implementing a Voice Over Internet (Voip) Telephony System
9.2 Link Traffic analysis:
Link properties and traffic analysis are summarized in the table 1 table 2 and table 3 below.
Node
Transmission medium
Entry Network resource
Ames PSTN - Waterloo IPBX
DesMoines IPBX - Waterloo IPBX
Ames PSTN - DesMoines IPBX
DesMoines IPBX - Fayette Gateway
Fayette Gateway - West Union PBX
Independence PSTN - West Union PBX
Fayette Gateway - Independence PSTN
T1 (24 B channels);
Voice over IP (PPP)
T1 (24 B channels)
Voice over IP (PPP)
Analogue
T1 (24 B channels)
T1 (24 B channels)
1 trunk
512 kbps
1 trunk
256 kbps
15 trunks
1 trunk
1 trunk
Entry network
voice channels
24
40
24
20
15
24
24
Table 1: Link Analysis
Node
Ames PSTN - Waterloo IPBX
DesMoines IPBX - Waterloo IPBX
Ames PSTN - DesMoines IPBX
DesMoines IPBX - Fayette Gateway
Fayette Gateway - West Union PBX
Busy hour offered
traffic
25.100 Erlangs
15.200 Erlangs
229.360 Erlangs
43.760 Erlangs
32.760 Erlangs
Entry network
blocking
0.170
0.000
0.896
0.560
0.564
Required voice
channels
36
24
252
57
45
Independence PSTN - West Union PBX
Fayette Gateway - Independence PSTN
78.800 Erlangs
11.000 Erlangs
0.701
0.000
95
19
Required
link resource
2 T1 trunks
302 kbps
11 T1 trunks
716 kbps
45 analogue
trunks.
4 T1 trunks
1 T1 trunk
Table 2: Traffic Analysis
For the VOIP (PPP) link Bandwidth required per voice channel can be calculated in the following way:
Each PPP frame adds an overhead of 56 bits (7 octets) to an IP datagram (including one flag). Accordingly, the PPP
frame sizes are: PPP frames carrying Voice IP packets = 248 bits. PPP frames carrying RTCP IP packets = 776 bits. By
multiplying the frequency of the packets (and PPP frames) with their size, the bandwidth occupied by each type of
frame can be calculated. The total bandwidth required is the summation of the three bandwidths: Voice bandwidth =
12.4 kbps. SID bandwidth = 0 bps. RTCP bandwidth = 155 bps. Total bandwidth per voice channel = 12.555 kbps.
Node
Link type
Entry network
facilities
Entry network
channels
Busy hour
traffic
Blocking
experienced
Optimum
voice channels
Ames PSTN Waterloo IPBX
DesMoines IPBX Waterloo IPBX
Ames PSTN DesMoines IPBX
DesMoines IPBX Fayette Gateway
Fayette Gateway West Union PBX
Independence PSTN West Union PBX
Fayette Gateway Independence PSTN
T1 (24B)
1 trunk
24
25.100
0.170
36
Entry
network
facilities
2 trunks
VoIP (PPP)
512 kbps
40
15.200
0.000
24
302 kbps
T1 (24B)
1 trunk
24
229.360
0.896
252
11 trunks
VoIP (PPP)
256 kbps
20
43.760
0.560
57
716 kbps
Analogue
15 trunks
15
32.760
0.564
45
45 trunks
T1 (24B)
1 trunk
24
78.800
0.701
95
4 trunks
T1 (24B)
1 trunk
24
11.000
0.000
19
1 trunk
Table 3: Link Analysis
Page 9 of 11
Implementing a Voice Over Internet (Voip) Telephony System
For the traffic analysis we assume that, calls arrive at the system randomly (Poisson arrivals). The ratio of sources to
lines is greater than 8 (infinite sources). Call holding times are of fixed length, or are exponentially distributed and
blocked calls are cleared.
In the simulation the Network consists of 6 nodes, 7 links and blocking target is 0.010. Busy hour factor is 17% and
total busy hour traffic is 379.460 Erlangs (offered). We tried to optimize the network too. The voice over IP parameters
are: Voice activity 100%, CODEC G.729B (CS-CELP) 8k, Packet interval 20ms (2 samples), Transport protocol cRTP
(4 bytes) and Control protocol is RTCP.
10. SIMULATION #2 WITH WESTPLAN SIMULATOR
In this simulation we tried to implement a VOIP system from Fayette, IA to New York, NY using VoIP PPP links only.
Calls can route through DesMoines to New York directly or it also can go through, DesMoines to Chicago and finally
New York.
Figure 10: Network topology for simulation #2
In the simulation the Network consists of 4 nodes, 4 links and blocking target is 0.010. Busy hour factor is 17% and
total busy hour traffic is 3000.0000 Erlangs (offered). The voice over IP parameters are: Voice activity 100%, CODEC
G.729B (CS-CELP) 8k, Packet interval 20ms (2 samples), Transport protocol cRTP (4 bytes) and Control protocol is
RTCP. All the links consists of the following characteristics:
Link type: VoIP (PPP); Entry network facilities: 64 kbps; Entry network channels: 5.
11. CONCLUSIONS
In this report we present a summary of the implementation of a VOIP system. Our major conclusions are as follows. In
terms of functionality and services that can be supported, H.323 and SIP are very similar. Fewer interoperability issues
are expected among its implementations. H.323 has better compatibility among its different versions and better
interoperability with PSTN. The two protocols are comparable in their QoS support (similar call setup delays, no
support for resource reservation or class of service (QoS) setting). SIP's primary advantages are its flexibility to add
new features and its relative ease of implementation and debugging. Finally, we implemented a VOIP system using
Westplan simulator and analyzed the traffic characteristics. For the simulation we have considered a number of issues
that may arise during the implementation phase of the network.
Page 10 of 11
Implementing a Voice Over Internet (Voip) Telephony System
REFERENCES:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
http://www.cs.columbia.edu/sip/papers.html
http://www.ietf.org/rfc/rfc3665.txt?number=3665
http://www.cs.columbia.edu/sip/
Wenyu Jiang, Jonathan Lennox, Henning Schulzrinne and KUndan Singh, “Towards Junking the PBX:
Deploying IP Telephony”, New York, NY 10027, USA
International Telecommunications Union – Telecommunications Standardization Sector, Introduction to
CCITT Signaling System 7, Recommendation Q.700, March 1993
American National Standards Institute. Signaling System 7, General Information. ANSI T1.110, 1999.
Arango, M., at al. “Media Gateway Control Protocol (MGCP) Version 1.0.” RFC 2705, October 1999
Munch,
Bjarne,
IP
Telephony
Signaling,
August
1999,
White
paper
available
at
www.ericsson.com/datacom/emedia
Galitizine, Greg. “Pulling Together – Interoperability through Open Standards.” Internet Telephony (October
2000), pp 62-66/
Elachi, Joanna, Standards Snapshot: The Satate of the Big 3 in Voip Signaling Protocols, November 27, 2000.
White paper available at www.commweb.com/article
Mark A. Miller, P.E., “Voice over IP Technologies: Building the Converged Network”, M&T Books, ISBN 07645-4907-3. pp 211-245.
Handley, M., at al. Session Initiation Protocol, RFC 2543, March 1999.
Voice over IP Forum. “IMTC Voice over IP Forum Service Interoperability Implementation Agreement 1,”
December 1997
RadiSys. “C6X Solutions for a Voice over IP Gateway.” White paper available at
www.radisys.com/files/voip.pdf
RADVISION, Inc. “H323 Gatekeepers.” White paper available at www.radvision.cpm/papers
Westbay Engineers Ltd. “Network Design.” White paper available at www.erlang.com
----------------------------0o0--------------------------
Page 11 of 11