Under Correlation & Over Correlation in Your Voice Monitoring System

One of the big contributions of a Voice Monitoring System to reducing costs in voice operations is the ability to bring all legs of a VoIP call from all segments or even geographical parts of your network together in one message flow or ladder diagram. Sometimes the process is not perfect. Most commonly seen is under correlation.This is where some of the legs of the calls are not correlated together. In some monitoring systems the user can see multiple instances of the same call. In other monitoring systems, it is not evident and pieces remain missing. When a SIP call passes through an SBC (Session Border Controller) implementing theBack-To-Back User Agent [B2BUA] functionality, the call ID will be changed. This usually presents a problem to monitoring systems attempting to correlate the two legs of the call together. However the caller or called part of the User Agent i.e. the phone number may remain the same or at least some part thereof. The format of the caller or called number may change in which case the correlation function needs to use only the common digits, which weakens the process. Alternatively, the SDP session ID may remain the same and be used for correlation. Correlating the same value in a given field is time sensitive. Such values rotate and need to be reused. In addition, calling and called numbers maybe redialed, causing separate calls. So the call merging function needs to look only within a given time interval, to avoid pulling pieces of different calls into the same call record or ladder diagram. Sometimes all values are uniquely generated by a network element. This leaves no common values to search for relating to the same call. Fortunately, Palladion, now known as Oracle Communications Operations Monitor (OCOM) is a little different from other voice monitoring systems. it has a totally customizable Call Merging Algorithm or correlation function which is user scriptable or configurable. This means regardless of how your network is setup or how your network elements treat the SIP signaling protocol packets, Palladion can always find some common information in the different legs of the SIP call to pull it altogether. Sometimes over correlation is seen. This occurs when legs or segments from different calls are correlated into the same call record. This may be because the parameters on which correlation is achieved are identical between different calls over the time correlation interval. However, now with some fine-tuning or a bit of scripting, we can ensure 100% accurate call correlation. This means that instead of taking an hour or two to troubleshoot a complex problem involving a trace, with Palladion/OCOM, it takes you 1-2 minutes.

If you need help with such optimization, please do contact us!   Sincerely, Richard Jobson, Teraquant Corporation www.teraquant.com

Solutions for SIP NAT/Firewall Traversal for VoIP

SIP-based communication does not reach users on the local area network (LAN) behind firewalls and Network Address Translation (NAT) routers automatically. Firewalls are designed to prevent inbound unknown communications and NAT stops users on a LAN from being addressed. Firewalls are almost always combined with NAT and typically still do not support the SIP protocol properly.


The issue of SIP traffic not traversing enterprise firewalls or NAT is critical to any VoIP implementation. At some point, all firewalls will need to be SIP capable in order to support the wide-scale deployment of enterprise person-to-person communications. However, in the short term, several solutions have been proposed to work around the firewall/NAT traversal problem. The bad news is that many of these solutions have serious security implications. The good news: there are other solutions that allow you to remain in control to various degrees. It is important to consider to what level you are prepared to surrender the control of your corporate or carrier infrastructure when choosing a NAT/firewall traversal solution in your network.
As you envision your solution, you should consider these questions:

• Who should be in control of my security infrastructure: the firewall administrator, the user or a peering service provider?
• Do we want a solution that is predictable and functions reliably with SIP standard compliant equipment or is it sufficient with a best effort solution that works in certain scenarios and maybe only with specific operators?
  

Universal Plug-and-Play (UPnP) – The SIP client or Windows
is in control

Universal Plug-and-Play (UPnP) for NAT control allows Microsoft Windows or a UPnP-capable SIP client to take control of the firewall. Both the client and firewall must support UPnP. This is a viable alternative only for those that can be sure there will never be anything malevolent on the LAN. UPnP is only supported by few firewalls and SIP clients. Due to the inherent high security risk in allowing a third party software to take control of the firewall this method is rarely used and in practice only for home users.

STUN, TURN, ICE – The SIP client is in control

These are all protocols proposed by the IETF for solving the firewall/NAT traversal issue with intelligence in the clients together with external servers. With these methods, pinholes are created in the NAT/firewall for SIP signaling and media to pass through. It is also the responsibility of the SIP client to emulate what the protocol should have looked like outside the firewall. These methods assume certain behavior from the NAT/firewall and cannot work in all scenarios. In addition, they remove control from the firewall, which must be sufficiently open to allow the users to create the necessary pinholes.

Session Border Controllers at Service Provider – The service provider is in control

Most service providers use some sort of session border controller (SBC) in their core network to perform a number of tasks related to their SIP services. One of these tasks is to make sure that the SIP services can be delivered to their customers. They may use STUN, TURN, ICE for this by acting as a server component for these protocols. However, not all clients support these protocols so the SBC may also use far-end-NAT traversal (FENT) technology for NAT traversal. The FENT function will aid remote SIP clients by transforming any SIP message by rewriting all relevant information and relay media, as well as keeping the client on the NATed network reachable. This solution only works with firewalls that are open from the inside, and may not work with all equipment and in all call scenarios. FENT is best suited for road warriors working at a hotel or at a conference, rather than at fixed location where there are more reliable and secure solutions. FENT also removes control from the firewall, which must be sufficiently open to allow FENT from the service provider SBC to work.


SIP-capable Firewalls or enterprise SBC – The firewall administrator is in control

This is a long-term solution where the problem is solved where it occurs, at the firewall or in tandem with an existing firewall using an enterprise session border controller. When deployed at the enterprise edge the SBC offers the same security and control as it does for the service provider's core network. The enterprise SBC typically has a built-in SIP proxy and/or back-to-back user agent (B2BUA) functionality to give unparalleled flexibility in real-life enterprise deployments. Most vendors of SBCs for service providers have products that can be deployed at the enterprise and then there are other companies that have developed products for the enterprise market from the very beginning.

For an enterprise, there are special security and functional requirements that make the SIP-capable firewall or enterprise SBC the solution of choice. First, it is the only solution that allows the firewall to maintain control of what is traversed between the LAN and the outside world. In addition, it is becoming more and more common to have a SIP server on the LAN. In fact, all SIP-based IP PBXs are SIP servers. In order for these SIP servers to communicate over IP with the outside world, the firewall simply must be SIP-enabled. As many IP-PBXs have done their own SIP-extensions outside the SIP standard it is very important that the firewall or enterprise SBC be adapted to support these extensions.


Due to the complexity of real-life installations, it is highly recommended that you deploy specialized SIP-enabling devices such as SIP-proxy firewalls even in the SOHO and SMB markets, even if it might not be motivated from a security policy perspective.


With the explosion of these various solutions and protocols, comes another potential headache. What do I do if something goes wrong? How do I find the offending service or equipment if jitter occurs or my users start experiencing one way audio? What is causing echo on the conversation? Before considering a large scale enterprise or service provider deployment, you should also consider a robust troubleshooting package. You might determine that additional test equipment is needed, but you will likely find that hosted troubleshooting packages are much more cost effective and future-proof.

Packet Voice Quality Problems and Answers

Almost all packet-based voice quality issues are attributable to some type of degradation on the packet network that the voice traffic's RTP stream traverses. Voice traffic brings to light network problems that might otherwise go unnoticed when just carrying normal data traffic. This is because in voice compressor-decompressors (CODECs) packet loss and variable delay in the IP telephony network must be minimized. Let's explore some common network issues that result in poor voice quality and what you can do about it:

Packet Drops

Packet-based telephony demands that speech packets find their destination within a predictable amount of time. There is very little tolerance for them to be dropped somewhere along the way from the source to the destination. In a properly designed network with Quality of Service (QoS) provisioning in place, packet loss should be nearly zero. All voice CODECs can tolerate degrees of packet loss without adversely affecting voice quality. Upon detecting a missing packet, the CODEC decoder on the receiving device makes a best guess as to what the waveform during the missing period of time should have been. Most CODECs can tolerate up to five percent random packet loss without noticeable voice quality degradation. This assumes that the five percent of packets being lost are not being lost at the same time, but rather are randomly dropped in groups of one or two packets. However, losing multiple simultaneous packets, even as a low percentage of total packets, can cause noticeable voice quality problems.

Note: You should design your network for zero packet loss for packets that are tagged as voice packets. A converged voice/data network should be engineered to ensure that only a specific number of calls are allowed over a limited-bandwidth link. You should guarantee the bandwidth for those calls by giving priority treatment to voice traffic over all other traffic.

There are various tools and procedures that you can use to determine whether you are experiencing packet loss in your network and where in the network the packets are getting dropped.

1. Examine IP phone statistics:

• If you are troubleshooting at the phone experiencing the problem, access the phone statistics by pressing the help (i or ?) button on the IP phone twice in quick succession during an active call.
• If you are working with a remote user, open a web browser on your computer and enter the IP address of the user's phone. During an active call, choose the Streaming Statistics > Stream 1 options from the display.

2. Examine the counters RxDisc and RxLost shown on the IP phone (or Rcvr Lost Packets if you are viewing the statistics remotely using a web browser).

• RxLost measures the number of packets that were never received because they were dropped in the network somewhere. By detecting a missing RTP sequence number, the IP phone can determine that a packet has been lost.
• RxDisc corresponds to packets that were received but were discarded because they could not be used at the time they arrived. RxDisc can come from an out-of-order packet or a packet that arrived too late. 

3. If either of these two counters increments, you should investigate to learn why packets are being lost or discarded.

Regardless of how low your packet loss is, if it is not zero, you should investigate the root cause. It just might be a sign of a bigger problem that will get worse with higher call volume. Always remember that packet loss can be occurring at any layer of the OSI-like transmission model, so be sure to check for all layers possible in each hop. For example, if there is a Frame Relay connection over a T1 between two sites, you should:

• Make certain that there are no errors at the physical layer on the T1.
• Determine if you are exceeding your committed information rate (CIR) on the Frame Relay connection.
• Verify that you are not dropping the packets at the IP layer because you are exceeding your buffer sizes.
• Check that you have your QoS improperly configured.
• Ensure that your service provider not only guarantees packet delivery but also guarantees a low-jitter link. Some service providers may tell you that they do not provide a CIR but guarantee that they will not drop any packets. In a voice environment, delay is as important as packet loss. Many service providers' switches can buffer a large amount of data, thereby causing a large amount of jitter.

Another common cause of drops in an Ethernet environment is a duplex mismatch, when one side of a connection is set to full duplex and the other side is set to half duplex. To determine if this is the case, perform the following steps:

1. Check all the switch ports through which a given call must travel and ensure that there are no alignment or frame check sequence (FCS) errors. Poor cabling or connectors can also contribute to such errors; however, duplex mismatches are a far more common cause of this kind of problem.
2. Examine each link between the two endpoints that are experiencing packet loss and verify that the speed and duplex settings match on either side.

Although duplex mismatches are responsible for a large number of packet loss problems, there are many other opportunities for packet loss in other places in the network as well. When voice traffic must traverse a WAN, there are several places to look. First, check each interface between the two endpoints, and look for packet loss. If you are seeing dropped packets on any interface, there is a good chance that you are oversubscribing the link. This could also be indicative of some other traffic that you are not expecting on your network. The best solution in this case is to take a trace to examine which traffic is congesting the link.

Hosted/Web-based analysis tools are invaluable in troubleshooting voice quality problems. With these tools, you can examine each packet in an RTP stream to see if packets are really being lost and where in the network they are being lost. With such a tool, perform the following steps:

1. Start at the endpoint that is experiencing the poor-quality audio where you suspect packet loss.
2. Take a trace of a poor-quality call and filter it so that it shows you only packets from the far end to the endpoint that is hearing the problem. The packets should be equally spaced, and the sequence numbers should be consecutive with no gaps.
3. If you are seeing all the packets in the trace, continue taking traces after each hop until you get a trace where packets are missing.
4. When you have isolated the point in the network where the packet loss is occurring, look for any counters on that device that might indicate where the packets are being lost.

Queuing Problems

Queuing delay can be a significant contributor to variable delay (jitter). When you have too much jitter end-to-end, you encounter voice quality problems. A voice sample that is delayed over the size of the receiving device's jitter buffer is no better than a packet that is dropped in the network because the delay still causes a noticeable break in the audio stream. In fact, high jitter is actually worse than a small amount of packet loss because most CODECs can compensate for small amounts of packet loss. The only way to compensate for high jitter is to make the jitter buffer larger, but as the jitter buffer gets larger, the voice stream is delayed longer in the jitter buffer. If the jitter buffer gets large enough such that the end-to-end delay is more than 200ms, the two parties on the call feel like the conversation is not interactive and start talking over each other.

Remember that every network device between the two endpoints involved in a call (switches, routers, firewalls, and so on) is a potential source of queuing or buffering delays. The ideal way to troubleshoot a problem in which the symptoms point to delayed or jittered packets is to use a hosted diagnostic tool at each network hop to see where the delay or jitter is being introduced.


Also remember that once you've made changes to your network elements and call paths that it is always appropriate to perform regression testing across your network with some type of automated voice quality test package. 

A Practical Guide to Revenue Assurance Management

Five Rules on how to enhance your Communication Service Provider Revenue



With the growing trend of LTE and an increasing mobile market, telecom companies today are facing the challenge of providing a variety of enhanced services to customers, but while staying profitable and securing their revenues. Revenue Assurance is key when it comes to ensuring long-term growth and the financial security of a company. But what does an efficient Revenue Assurance strategy look like? It doesn't need to be rocket science; but sometimes it helps to consider new methods to optimize a company's revenue.

Codec Translator accepted the challenge and has put together an easy guide of five rules for Communication Service Providers to ensure an efficient Revenue Assurance Management.





1. Look for hidden revenue

Have you ever thought of what happens if you don't pay your bill? Well, for some reason many Service Providers have a tendency to avoid invoicing some of their customers, not only because of unclear billing reports, but can also be because of their customer status. It is often reported that there is a specific customer base considered as "untouchable", even when this customer would not pay the bill. But why shouldn't correct billing apply to these customers?



A first step here in order to avoid this kind of revenue leakage is obviously a well working reporting tool for your billing records. Then, reflect what payment strategy is most appropriate for you. In a serious case of parties that are not willing to pay, you might possibly consider stronger contract bindings, or even penalties for non-paying customers or distributors for infringing their legal agreements.

Looking for the leakages in your billing strategy could make you easy money, all by just applying your standard billing Terms and Conditions.





2. Communicate with other departments

The bigger your company is, the more correct billing will become a serious challenge, especially when various customer bases are registered in different departments. Cross-departmental communication might be the key here to solve billing questions, and tools that provide a revenue transparency should be encouraged. You might be surprised and discover new invoicing models or customer groups that have not been invoiced so far, because they've been out of your department's scope.

Therefore, supporting open communication with other departments and by adopting standards and policies to help regulate communication will certainly help you enhancing the Revenue Assurance Management.





3. Revenue Protection is also fraud prevention

New ways of communication such as IP-telephony, messaging, and new services not only bring new opportunities, but also give fraudsters new opportunities to steal money. The Press and several fraud associations frequently report about significant losses in the telecom sector due to fraud attacks. One single fraud attack can have an impact of losses of up to five digits USD for just the one fraudulent call placed illegally in a Service Provider's network. Facing the potential for disastrous consequences in revenues and reputation, the telecom industry starts to rethink of prevention mechanisms to protect their customers from fraud attacks.



In order to reduce fraud as an obvious source of revenue leakage, installing a high performance solution that will protect LTE, IMS and VoIP networks of fraud attacks is a good investment. Today, light-weight solutions can detect fraudulent attack in near real-time, and the ability to block fraudulent calls as they happen reduces any further revenue losses.





4. Know your customers

Obviously, an appropriate billing infrastructure is crucial when it comes to invoicing customers. Moreover, it's good to know what services your customers most value. To better understand your customer's behavior, you will need a solution that provides an end-to-end network visibility, which displays user behavior in the past as well as trends of current usage. This information, together with the ability to group and organize your customers will help you to learn about your customer's preferences or any issues they might experience while using your service. The better you know your customer, the better your Customer Experience Management will be. A solution to measure the Customer Experience will not only help you to troubleshoot service issues, but also to understand what your customers really want and which of your services they value the most.





5. Set reachable goals

This simple life rule also applies to an efficient Revenue Assurance Management.

Whenever you decide to adopt a billing system, new systems for network monitoring, or fraud prevention mechanisms, you might need to consider opting for high performance, yet easy to use solutions. The lower the barriers are to implementing and using new solutions, the more likely you and your team will be to successfully adopting the new systems. This will not only be paying off your investment, but also fostering an enhanced Revenue Assurance Management.

MOS Results are Good but Customers Still Complain of Poor Speech Quality

When monitoring the speech packets of a VoIP network, i.e. the RTP stream, protocol analyzers or VoIP service monitoring systems may analyze the packets and calculate a Mean opinion score (MOS) which describes the quality of the speech. If customers call into your call center or NOC and complain about speech quality this is the first place you would go to analyze the problem. Finding the bad call the customer is referring to will take a few seconds with a good voice service assurance system.  Sometimes when you find the call, the MOS maybe 4.0 or greater indicating good speech quality.

How can we explain this discrepancy?

The method used to calculate MOS by a monitoring system which needs to monitor thousands of active calls and produce voice quality measurements or QoS of all of them is R-factor based on the E-model (ITU-T G.107). R-factor takes into account the codecs used by the endpoints (VoIP Phones) in the call. But most of the calculation is derived from what happens to the packet stream as it transits an IP packet network. So R-factor requires measurements for packet loss and jitter of the packets in the stream of VoIP (RTP) packets

How is packet loss and jitter detected in an RTP stream? The RTP packets contain a sequence number and a time stamp and from this packet loss and jitter can be calculated. It is however, important to understand that these measurements can only be made on the received RTP streams i.e. packet loss and jitter is only measured up to that point in the network where the monitoring system probe is connected.

RTP streams leaving your network going to your customer’s premises will not be measured unless you have a probe on the customer’s premises or their VoIP phones support RTCP. A sophisticated good voice service assurance system will also read the RTCP packets coming back from the customer’s probes and so that leg of the call can be included in the R factor measurement. Some monitoring systems will show you in which leg of the call the packet impairments are added.

If call quality is bad but MOS is good, perhaps you are not monitoring all legs of the call.

Another reason may account for this discrepancy. MOS or Perceptual Speech Quality does not include echo or overall end-to-end delay. So if the customer is experiencing echo, this will not degrade the MOS values. Similarly, if there is delay in the network (as opposed to jitter, which is short-term varying delay), this will not impact the MOS value. Network Delay in VoIP causes cold or stinted conversation, so this this could be a reason for your customer to call you.

If customers complain of poor speech quality but the MOS results are good, use your voice service assurance system to record the calls from this customers (with disclaimers and forwarding necessary of course) and listen to a sample for echo or delay.

Methods to Objectively Evaluate Speech Quality

This post gives an overview of methods to objectively evaluate perceptual quality of speech. The science of perceptual speech quality measurements assessment has been progressing for the past two decades. Current state-of-the-art for full referenced measurements uses the third iteration of the standard. Good-quality implementations of the standards of the algorithms contained within the standards will deliver the 97% correlation with the subjective tests database depending on implantation of the test set up.

Commercial test solutions exist to measure speech from acoustic, electronic analog and digital interfaces.

Mean Opinion Score [MOS] is a scale used in voice telecommunications predicting the perceived quality of a speech sample. MOS describes speech clarity or intelligibility. The measure does not measure delay across a network or Echo. The scales runs from 1 to 5, a score of '1' is bad and '5' is excellent. MOS [Mean Opinion Score] test sessions comprise 15 to 25 people listening to speech files of good quality and of poor quality with impairments and scoring them subjectively. This subjective test process is specified in the standard ITU-T P.800.

 

Mean opinion score (MOS)
MOS	Quality	Impairment
5	Excellent	Imperceptible
4	Good	Perceptible but not annoying
3	Fair	Slightly annoying
2	Poor	Annoying
1	Bad	Very annoying

 

MOS is valuable for the characterization of any device where the voice is compressed and transmitted over networks. Such devices may be handsets, mobile phones and networks such as packet-based VoIP networks or wireless networks. Networks employing state-of-the-art codecs are optimized for the compression of voice and treat tomes such as DTMF tones in a different way from the voice. Therefore to the characterize quality of the network or the System under Test, real speech files need to be transmitted. Frequency response, levels, Echo and delay must be measured, but in addition to the perceived speech quality.

Subjective testing is obviously time-consuming and expensive. So algorithms have been developed to allow a computer to reference the pure incidented speech file and compare it with the received degraded file and calculate the MOS with a high degree of correlation to subjective MOS. The first such objective speech quality measurements were standardized in 1998 with the PSQM algorithm P.861 Objective quality measurement of telephone-band (300-3400 Hz) speech codecs. This was followed by ITU-T Recommendation P.862: Perceptual evaluation of speech quality (PESQ) which has gained widespread worldwide usage as a reliable method for characterizing most narrowband telephony systems.

The following are examples of Mean Opinion Scores for one implementation of different codecs:

Codec	Data rate [kbit/s]	Mean opinion score (MOS)
G.711 (ISDN)	64	4.1
iLBC	15.2	4.14
AMR	12.2	4.14
G.729	8	3.92
G.723.1	6.3	3.9
GSM EFR	12.2	3.8
G.726 ADPCM	32	3.85
G.729a	8	3.7
G.723.1	5.3	3.65
G.728	16	3.61
GSM FR	12.2	3.5

 

 

 

 

 

 

Wideband telephony networks are expected to improve the user experience including the intelligibility of voice conversations over highly compressed codecs as used in both packet and wireless networks. Hopefully the tardy phrase "can you hear me now" will become a less frequent part of our vocabulary. 

High Definition or Wideband Telephony is just now coming into common usage. G.722 is the Wideband Telephony codec for VoIP and WB-AMR is now being tested for wireless networks. However, they do need to be tested to tune codec implementations, packet loss concealment algorithms and performance in areas of poor coverage or high congestion.

Here are the analog frequency definitions for the different forms of telecommunications:

 

 

 

 

  

  






PESQ was never designed to address wideband networks. In addition, vendors of time warping code codecs [e.g. EVRC] and Skype and iLBC were not content that PESQ accurately measured the full quality of their codecs.

 

In 2006 ITU-T commenced work on a new standard to address the limitations of PESQ and during 2011 the POLQA standard, Recommendation P.863, was published.

 

 

 

 

Speech uses the new POLQA speech quality metric for objective protection of MOS. The old PESQ algorithm (ITU-T P.862) has been used for narrowband telephony since it was approved in 2000. PESQ was not designed for Wideband Telephony and also did not represent well the speech quality of time warping codecs. POLQA addresses all these short comings and provides a scale that goes all the way to 24kHz audio.

It is desirable to use the same scale so that laboratories can compare new results for wideband telephony with their old PESQ database. However, the question of human expectation comes into play because all these objective measurements performed by computers must correlate or predict subjective experience. If you watch a video on your smart phone, you might consider the picture quality as being good. Your expectations are put in the context of the small screen and the convenience of the video being played on a handheld smartphone. If you would give you the same video on your brand-new expensive high-definition 1080P TV, you would be very disappointed even if the pixel resolution had been scaled to the 62 inches screen size. Your expectation of quality is tempered to the format in which you are viewing it.

Similarly with speech and audio. If you were to participate in a MOS test and invited into a studio where there were high fidelity speakers, orchestral classical music playing and told and asked to rate the quality of the High Definition speech you are about to hear, your expectations would be set high and you'd be more critical. You would score the audio lower than if you had been asked to rate the speech quality of your most recent cellular phone call.

POLQA offers two scales, the narrowband scale and the super wideband scale. Super wideband telephony reaches 14 kHz analog audio frequency. The narrowband focus scale maps directly onto the old desk scale and exploits the higher scores not given by test participants in narrowband tests.

• NB: Maximum MOS value 4.25

• WB: Maximum MOS value 4.5

• SWB: Maximum MOS value 4.75

So a score of 4.5, on the narrowband POLQA scale is experimentally the best value you will ever obtain with wideband telephony equipment. For POLQA, the maximum MOS value in tests is 4.75 .

In future years, the industry will migrate exclusively to using the super wideband POLQA scale as soon as users' expectations always expect high-definition or hi-fi quality to the communications audio.

	POLQA SWB	POLQA NB
14kHz 16 bit Linear	4.75
7kHz 16 bit Linear	4.5
AMR - WB	4
3.4KHz 16 bit Linear	3.8	4.5
G.711	3.7	4.3
EFR/AMR-FR 12.2kbps	3.6	4.1
EVRC 9.5 kbps	3.4	3.9
EVRC-B 9.5 kbps	3.5	4
AMR-HR 7.95 kbps	3.4	3.8

 

Applications for Perceptual Speech Quality Measurements 

Perceptual speech quality measurements are used to make End-to-End measurements, for any network where voice codecs are used to compress the speech or where speech transmission systems or networks may introduce impairments, such as weak radio signals or multipath or packet loss or packet jitter.

Examples of systems where Perceptual Speech Quality Measurements are valuable:

• Codec evaluation
• Frame or packet concealment implementation
• Headsets combining the digitization of sound
  
• VoIP phone assessment, both softphone and dedicated VoIP phones
  
• Mobile handsets
  
• Digitizing radio & Intercom systems
  
• VoIP networks
  
• Wireless cellular networks
  
• speech enhancement and noise reduction systems
  
• transcoders

A new important feature added to POLQA is its ability to measure the improvement of speech quality for speech enhancement and noise reduction systems.

The picture shows the iLBC codec measuring 4.21 and the narrowband POLQA scale.

In over 2 decades where these tests have taken place, no statistically significant number of participants ever scored any speech recording as being excellent or 5.0. The highest score typically obtained in any test was 4.54. So this measurement for iLBC of 4.21 is a good score for the codec.

For more information on making PESQ and POLQA measurements, ensure you contact only renowned and well-respected test vendors because the science of speech quality measurements requires expertise and experience in many different areas - audio, analog electronics as well as computing. It is easy to make a measurement but care is required to ensure that measurement is accurate correlates to human subjective experience and is put into the context of the environment, resolution, format etc.

one of the most admired vendors for speech quality metrics is Malden Electronics, available in USA through Teraquant Corporation – www.teraquant.com

More information can be obtained at:

http://en.wikipedia.org/wiki/POLQA

Some Key Facts About Communications Fraud

According to a recent study from the Communications Fraud Control Association (CFCA), a high number of Communication Service Providers are increasingly facing fraud attacks. Based on the results of the CFCA’s “2011 Global Fraud Loss Survey”, the annual Global Fraud Loss Estimate reportedly is $40.1 Billion (USD), whereas the real number is probably much higher.

The CFCA which is a not-for-profit global educational association with mission to combat communications fraud, describes the 5 most current fraud types as follows:

• $4.96Billion–Compromised PBX/Voicemail systems
• $4.32Billion–Subscription/Identity (ID)Theft
• $3.84Billion–International Revenue Share Fraud (IRSF)
• $2.88Billion–Bypass Fraud
• $2.40Billion–Credit Card Fraud

However, there are many other existing fraud types such as Identity Theft, Social Engineering, Roaming Fraud, SS7 Manipulation just to name a few.

When asked how many fraud incidents the surveyed telecom operators handle per month, 42.6% said less than 50 incidents, 13% report to have had 51-100 incidents, 24.1% (101-500 incidents), 3.7% (501-1,000 incidents) and 16.7% (1,001+ incidents).

With the migration to Next Generation Networks, the risk of new fraud attack methods keeps on growing and the need to protect these networks becomes an obvious necessity for network operators. Current available solutions to fight telecom fraud might still be limited, but to prevent fraud attacks efficiently, you might need a solution that runs in real-time to detect fraud incidents instantly, with a powerful technology to prevent any fraud attack on IMS, LTE and VoIP networks.

Source: all provided numbers and facts are based on the CFCA’s “2011 Global Fraud Loss Survey”.

For more information about the Communications Fraud Control Association, please contact fraud@cfca.org or visit the official website: www.cfca.org