DOC

Verification of Voice over IP

By Rachel Harper,2014-12-26 01:34
7 views 0
Verification of Voice over IPof,IP,ip,voice,over,VOICE,OVER,Voice,Over

    Chalmers University of Technology

    Master Thesis Report

    Verification of Voice over IP

    (In Network Integration Solution area)

    By

    Ibrahim Qazzaz

    Supervisor

    Lars Romin

    Examiner

    Bengt Wedelin

    _______________________________________________________________________________

    April 1999

     1(80)

     Verification of VoIP Uppgjord (även faktaansvarig om annan) - Prepared (also subject responsible if other) Nr - No. NA/EBC/EN/DAS Ibrahim Qazzaz

    Dokansv/Godk - Doc respons/Approved Kontr - Datum - Date Rev File Checked NA/EBC/EN/DAS Lars Romin

    Content

Foreword

Introduction

Chapter One

     Project Assignment

Chapter Two

     IP

Chapter Three

     What is VoIP

Chapter Four

     Approaches of VoIP

Chapter Five

     System Description

Chapter Six

     Proposed Tests for Integrating VoIP with BC10 PBX

Chapter Seven

     Transacted Tests

Abbreviations

References

Annexes (A-E)

     2(80)

     Verification of VoIP Uppgjord (även faktaansvarig om annan) - Prepared (also subject responsible if other) Nr - No.

    NA/EBC/EN/DAS Ibrahim Qazzaz

    Dokansv/Godk - Doc respons/Approved Kontr - Datum - Date Rev File Checked NA/EBC/EN/DAS Lars Romin

    Foreword

    This report was written as a prerequisite for the Master degree in Digital Communications and Technology at Chalmers University of Technology Gothenburg / Sweden. The project was supported

    and done in Ericsson Business Network AB in Stockholm.

    Verification of VoIP meant for me transacting a subjective test and that is what I did. My conclusion is that VoIP is very promising, but many improvements should have taken place before have it commercially released. Moreover, it will be an attractive choice if a VG is built in a PBX as an integrated part.

     3(80)

     Verification of VoIP Uppgjord (även faktaansvarig om annan) - Prepared (also subject responsible if other) Nr - No.

    NA/EBC/EN/DAS Ibrahim Qazzaz

    Dokansv/Godk - Doc respons/Approved Kontr - Datum - Date Rev File Checked NA/EBC/EN/DAS Lars Romin

    Introduction

    It is a hot topic. VoIP according to its hardliners- will alter the used techniques for telephony. VoIP is not very new from theoretical point view, at least in the sense of merging data and voice. VoIP saves both cost and bandwidth, and again for both operators and end users.

    This report does not presume specialized background of readers, and hence after first chapter which is the proposal of the thesis, three chapters could be skipped by

    experienced reader- were written to clarify this “jargon”

    Chapter 5 describes briefly Ericsson’s system of VoIP and relates to ITU-T

    recommendation H.323. While chapter 6 is a report that was handed to project supervisor as a preliminary idea for tests to be done, chapter 7 is touches the transacted tests and analysis.

    Footnotes are used extensively to avoid any expected ambiguity or misinterpretation. The [ ] sign is used to denote a reference number.

    A list of abbreviations and another for references are given before few useful annexes that include forms, questions and announcement messages that were used in the subjective test.

    Finally, I would like to express my deep appreciation to many people in Ericsson Business Network AB, Ericsson Radio Access AB, Ericsson Telecom AB, and Ericsson Software (Erisoft) AB whom without their supports and advice this work would not see light. For any comment, please write to email:

    Ibrahim.Qazzaz@etx.ericsson.se.

     4(80)

     Verification of VoIP Uppgjord (även faktaansvarig om annan) - Prepared (also subject responsible if other) Nr - No.

    NA/EBC/EN/DAS Ibrahim Qazzaz

    Dokansv/Godk - Doc respons/Approved Kontr - Datum - Date Rev File Checked NA/EBC/EN/DAS Lars Romin

    Chapter One

    1Project Assignment:

    Verification of Voice over IP

    (In the Network Integration Solution area)

1.1 Background

    The most recent approach to the market is going from selling products to

    selling solutions.

    In order to build confidence into a solution, verification of the solution is

    needed. Integration tests of all products included, needs to be performed.

    Earlier products have only been tested separately and not together with other

    products, used in typical customer environments.

    The aim with solution verification will be to shorten the time to market and

    increase sales. Another important aim is to get the Local Companies’ and

    increase customers’ confidence in Ericsson products. They should also feel

    that our products as well as partner products are of high quality, integration

    tested and are working well with each other as a solution. All work must be

    documented.

1.2 Problem

    The Network Integration Solution area is one critical customer solution area.

    These solutions generally involve products from many different vendors taking

    different roles in the network, such as switches, transmission products and

    gateways.

    It is difficult to specify how to verify the solutions. The verification should

    determine if the solutions have the high reliability and the high capacity

    expected.

    It is also important to determine the results of the verification and what parts

    should be presented to the customer.

1.3 Objectives

    The master thesis project has the following goals:

     1 By Lars Romin (project supervisor).

     5(80)

     Verification of VoIP Uppgjord (även faktaansvarig om annan) - Prepared (also subject responsible if other) Nr - No.

    NA/EBC/EN/DAS Ibrahim Qazzaz

    Dokansv/Godk - Doc respons/Approved Kontr - Datum - Date Rev File Checked NA/EBC/EN/DAS Lars Romin

    1. To set up criteria and find methods for measuring the load on the IP Network

    generated by the voice over IP applications, which are included in the 2Network Integration solution area using MD110 release BC10 and the new

    IP Gateway product. These criteria and methods should be the basis for

    future verifications.

    2. To set up criteria and find methods for measuring voice transmission quality

    when transferred over a loaded IP Network.

    3. To document the Network Integration solutions to be verified. This

    documentation must include specifications of all the hardware and software

    in the test scenarios. Technical descriptions of the servers, release

    information about all products and the Network Integration related MD110

    configurations etc. should also be included. The results from the

    measurements should also be part of the document.

    4. To define scenarios within the Network Integration Solution area that are to

    be verified.

    5. To perform verification and integration tests in the defined scenarios while

    measuring the IP Network traffic.

    6.To document the possible limitations of different methods and scenarios.

1.4 Plan and Follow up

    A detailed time schedule and plan regarding pre-study, literature studies

    needed and course of action shall be documented.

1.5 Equipment

    In order to perform measurements, the Network Integration Solution

    Verification laboratory shall be used.

    The laboratory must be equipped with MD110 and IP Gateway products of the

    latest releases as well as hubs and routers.

1.6 Scope and Limitations

    No measurements have to be performed on the MD110, only measurements

    on the IP Network will be performed. No function tests on products will be

    performed.

    Assistance in building up the laboratory will be provided.

    Defining the solution verification process is not an aim of this project.

     2 The commercial name for the Private Branch Exchange (PBX) of Ericsson.

     6(80)

     Verification of VoIP Uppgjord (även faktaansvarig om annan) - Prepared (also subject responsible if other) Nr - No.

    NA/EBC/EN/DAS Ibrahim Qazzaz

    Dokansv/Godk - Doc respons/Approved Kontr - Datum - Date Rev File Checked NA/EBC/EN/DAS Lars Romin

    Chapter Two

    IP

2.1 IP and Internet

     3Internet Protocol or IP is the most common data communication protocol.

    It is the underpinnings of Internet, which witnesses the ever vast booming.

    Originally, IP is a part of a suit of protocols built by Department of Defense

    (DoD) Advanced Research Projects Agency (DARPA) Internet Community, 4better known as TCP/IP.

    The Internet became widely known and talked about in the early to mid 1990s.

    It is a world - wide collection of interlinked (hence the word Inter is emanated)

    wide-area networks, with associated local area networks. In the 1970s it was 5better known as the ARPANET, when it was the first network to establish the

    viability of wide-area computer communication. It later became known as the

    Darpanet communication. Despite it became known as the Darpanet, the term

    Internet is preferred today. Up to the mid-1990s it was largely a research,

    military and educational network, with a very limited and restricted amount of

    commercial traffic over it. This situation changed dramatically in the middle of

    1990s with the growth of interest in the provision of World Wide Web pages.

    The use of Transmission Control Protocol (TCP) and Internet Protocol (IP), but

    particularly the latter characterize communication over the Internet, with a

    variety of other protocols on top. All the protocols in the suite are generally

    collectively known as "the TCP/IP protocols" (even if they do not actually use

    TCP), or more accurately as "the Internet protocols".

    Originally, TCP/IP was very much aimed at wide-area networking, but its

    adoption in the early 1980s by the UNIX developers led to its wide spread use

    in the late 1980s on local area networks.

    As a network layer protocol suite, IP is widely used on Ethernet networks. 6IP was defined in RFC 791; the current version of IP is IPv4. A new version,

    called IPv6 or IPng is under development.

     3 Protocol is a set of formal rules describing how to transmit data, especially across a network. Low level protocols define the electrical and physical standards to be observed, bit- and byte-ordering and the transmission and error detection and correction of the bit stream. High level protocols deal with the data formatting, including the syntax of messages, the terminal to computer dialogue, character sets, sequencing of messages etc.

    Many protocols are defined by RFCs or by OSI. 4 The connection to TCP will be reached soon. 5 Or network of ARPA. 6 RFCs are Comments submitted to IETF for the purpose of discussing, setting and ratifying evolution of Internet.

     7(80)

     Verification of VoIP Uppgjord (även faktaansvarig om annan) - Prepared (also subject responsible if other) Nr - No.

    NA/EBC/EN/DAS Ibrahim Qazzaz

    Dokansv/Godk - Doc respons/Approved Kontr - Datum - Date Rev File Checked NA/EBC/EN/DAS Lars Romin

    The Internet protocols are vendor independent, and their specification is controlled by open public discussion, that is not dominated by any specific vendor. They are also widely implemented by a variety of vendors and hence fulfil the definition of "open" as used in OSI. It is remarkable to know that there is no formal document specifying the architecture of the TCP/IP-related (Internet) specifications, so there can be different views by different authors on the de facto architecture, and particularly on its relationship to the OSI architecture.

    2.2 Ethernet Frame

    Because of close relevance between IP and Ethernet, it might be reasonable to show the composition of an Ethernet frame, as illustrated in figure 2-1 below.

    Destination Source Destination Preamble CRC Preamble Address Address Length Data Address

    8 bytes 6 6 2 0 - 1500 4

    Figure (2-1) Ethernet Frame

    The preamble is a predefined sequence of 1s and 0s used for synchronization. CRC is for checking.

    2.3 OSI and IP

    OSI is a model of network architecture and a suite of protocols (a protocol stack) to implement it, developed by ISO in 1978 as a framework for international standards in heterogeneous computer network architecture. The OSI architecture is split between seven layers (up direction).

1. Physical.

    2. Data link.

    3. Network.

    4. Transmission.

    5. Session.

    6. Presentation.

    7. Application.

     8(80)

     Verification of VoIP Uppgjord (även faktaansvarig om annan) - Prepared (also subject responsible if other) Nr - No.

    NA/EBC/EN/DAS Ibrahim Qazzaz

    Dokansv/Godk - Doc respons/Approved Kontr - Datum - Date Rev File Checked NA/EBC/EN/DAS Lars Romin

    This is shown in figure (2- 2) which also reveals the connection to Internet protocols suit. Each layer uses the layer immediately below it and provides a service to the layer above. In some implementations a layer may itself be composed of sub-layers.

    Today, when people talk about "open networking", they can mean implementation of either OSI or TCP/IP. Marketing brochures need to be examined carefully to see which is meant.

    (Whilst all the early TCP/IP protocols have equivalent or better OSI equivalents, there is no OSI equivalent for the protocol underlying the World-Wide Web, although the markup language used to author pages (HTML - Hyper-Text Markup Language) is based on an ISO Standard (SGML - Standard Generalized Markup Language).

How is the architecture of TCP/IP?

    It has strong similarities with parts of OSI, but is broadly much simpler. As with OSI, there is an end-to-end network service provided by the use of IP, with network switches understanding only the IP protocol and associated routing and management protocols. Beneath the IP layer there is whatever real

     Application

     Presentation Application

     Session

     Transport Transport

     Network Internet

     Data Link Network Network Interface Interface

     Physical

     Figure (2-2): IP vs. OSI

     9(80)

     Verification of VoIP Uppgjord (även faktaansvarig om annan) - Prepared (also subject responsible if other) Nr - No.

    NA/EBC/EN/DAS Ibrahim Qazzaz

    Dokansv/Godk - Doc respons/Approved Kontr - Datum - Date Rev File Checked NA/EBC/EN/DAS Lars Romin

    networks are around, and there is a series of specifications (Internet specifications are called, somewhat misleadingly, Requests for Comment 7RFCs that specify how to transmit IP messages over a whole range of real-world networks, including some vendor-specific ones). This part of the architecture then, is very similar to the OSI "Internal Organization of the Network Layer" described earlier. Above the IP layer, there is a layer corresponding quite closely to the Transport Layer of OSI, and containing TCP or another (very simple) protocol called User Datagram Protocol (UDP) as we will see later. On top of these there sit monolithic specifications for applications.

    The main difference between the OSI and the TCP/IP architectures is that in TCP/IP the Session and Presentation Layer functionality is not factorized into separate specifications, nor are application specifications normally broken 8down into a set of Application Service Elements or ASEs.

     It should be pointed out that, Network Interface layer is also referred to as Link

    Layer (LL).

2.4 Mechanism: Packet Switching

Stream of data (in the application layer) is fragmented into sets of bits, widely 9known as packets. Encapsulation of packets takes place: Header and trailer

    information is added in this stage to packets in order to form what is called frames.

    To state the more accurate notation [24]:

    * Packet, is the data unit that pass through the interface between Internet

    layer and the Network Interface layer, which means it includes IP header

    plus data.

    * IP datagram (or simply datagram) is the end- to end unit of transmission in

    IP. Therefore, an IP datagram comprises IP header followed by transport

    Layer data. Datagrams are self-contained independent entity of data

    carrying sufficient information to be routed from the source to the destination

    computer without reliance on earlier exchanges between this source and 10destination computers and the transporting network (connectionless).

     7 Was pointed to previously. 8 One can discern some elements of the ASE concept in the TCP/IP TELNET protocol, which is

    used both as an actual application (terminal login) and also to support other application protocols (file transfer and electronic mail). With this exception, however, Internet specifications above TCP or UDP tend to be self-contained. 9 Encapsulation: The technique used by layered protocols in which a layer adds header information to the protocol data unit (PDU) from the layer above. As an example, in Internet terminology, a packet would contain a header from the Network Interface Layer, followed by a header from the Network Layer (IP), followed by a header from the Transport Layer (TCP), followed by the application Protocol data. 10 The data communication method in which communication occurs between hosts with no previous setup.

Report this document

For any questions or suggestions please email
cust-service@docsford.com