• Like
  • Save
Voip testing methodology v00a
Upcoming SlideShare
Loading in...5
×
 

Voip testing methodology v00a

on

  • 410 views

Voip testing methodology, Traffic Generators, VoIP Probes, Big Data, Call Centers, Telco, VoIP

Voip testing methodology, Traffic Generators, VoIP Probes, Big Data, Call Centers, Telco, VoIP

Statistics

Views

Total Views
410
Views on SlideShare
325
Embed Views
85

Actions

Likes
0
Downloads
1
Comments
0

3 Embeds 85

http://www.linkedin.com 80
https://www.linkedin.com 4
http://lnkd.in 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Voip testing methodology v00a Voip testing methodology v00a Document Transcript

    • VoIP Testing Methodology: Has your company defined a methodology for testing IP networks? By Daniel Soroko - http://www.linkedin.com/in/danielsoroko The fraction of voice over Internet Protocol (VoIP) based telephone calls, among the totality of voice based communication acts, has been significantly growing during the last years. In wired -as well as wireless communication applications- VoIP is expected to completely replace former circuit switched telephony approaches, and is, thus, a major factor to be considered when designing sophisticated communication networks. Today, measurement of the performance and effectiveness of SIP infrastructure relies on the administrator's skills and experience with telephony infrastructure. This experience could fall short, due to an increasing demand in the implementation of special services like queues, IVRs, transcoding, and conferences. The increasing utilisation of SIP-based VoIP technologies in the rapidly growing development of converged networks are the main reasons for creating a methodology that would allow administrators to measure the performance of SIP servers precisely, and to detect signalling or media problems. The main question is: Has your company defined a methodology for testing IP networks? A suitable IP network – testing methodology allows your company to ensure that reliability and quality exceed service level agreements and customer’s expectations all the time. Also it's the primary source of data for maintenance tasks, and for engineering tasks (sizing). For these reasons, measurement tasks on the networks become more and more important every day. The test methodology should be embedded in the traditional tasks of operation and maintenance of a telecommunications network, it cannot be treated as separate or as a mere auxiliary activity. People should think about network quality at all times, not just when there are problems. Where to apply this methodology? Normally a VoIP network testing methodology is defined for its use in the following network operations: - New equipment capabilities certification. - Check equipment behaviour after HW and SW evolutions. - Preventive maintenance (typically routing issues tests and load tests). - Corrective maintenance (typically invalid signalling patterns or QoS problems). For each of these network operations, testing methodology must define specific tests. What are the most common tools used to perform the tests? The most common tools used for these tests are the traffic generators and VoIP probes. The first mentioned tool, allows you to generate complete calls (signalling + media) or only signalling patterns in your network. The second one, allows you to capture, analyze and measure the signalling and media flows.
    • There are two ways to obtain this kind of tools: to rely on special proprietary solutions or, to try to use some of the tools provided by the open-source software community to develop a new methodology. The first choice offers good possibilities as proprietary solutions offer comprehensible test scenarios and also come with easily readable automatic output results. Thus, the whole testing process is user friendly. However, this choice also has disadvantages. Proprietary solutions are usually less flexible when the network topology is modified, and in many cases the cost of its licenses is a limiting factor. In addition, each producer uses his own methodology. Therefore, the output results from proprietary solutions from two different producers are incompatible and also incomparable. The second choice offers significant independence for the user, who is free to choose what will be measured and how. This freedom of choice can result in the same problematic incompatibility of results as the proprietary solutions. However, this freedom can easily be used in the testing scenario to reflect the parameters of any standard. Open-source testing tools differ from proprietary solutions, because these commercial companies will never be as flexible as the open-source community. Final comments: This document is a summary originated in the author's experience in the development and implementation of these testing methodologies in ITT Standard Electric, Telefónica and Ericsson. This document is not intended to be exhaustive, it is only a summary to raise the issue. Each reader must draw their own conclusions on this issue. "Test methodology should be one of the pillars in the operation, maintenance and evolution of telecommunications networks. One should think about quality at all times, not just when problems arise." This is the first stage, at ground level. Has your company really defined a methodology for testing IP networks? Big data technology is present, can your company use it in its network? Can your company capture 100% of audio flows at its call centres to apply Speech Analytics techniques using the approach defined in Big Data techniques? Epilogue: "To measure is to know." "If you cannot measure it, you cannot improve it." (Lord Kelvin) "Knowledge is power" (Sir Francis Bacon) //DS: Daniel Soroko (for more details about the author see: http://www.linkedin.com/in/danielsoroko)