The CODEC Translator

Under Correlation & Over Correlation in Your Voice Monitoring System

2014-03-26T09:50:00.001-07:00

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

2012-04-11T08:13:00.000-07:00

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 Windowsis 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

2012-04-04T08:52:00.000-07:00

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:

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.
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:

Start at the endpoint that is experiencing the poor-quality audio where you suspect packet loss.
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.
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.
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

2012-03-28T12:36:00.002-07:00

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

2012-03-03T22:41:00.014-08:00

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

2012-02-25T14:51:00.002-08:00

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

2012-02-05T07:19:00.000-08:00

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

The One-Way Audio VoIP Dilemma

2012-01-25T13:24:00.000-08:00

One-way audio is an annoying anomaly where one person can hear the other caller, but that caller can't hear them. It is uncommon in non-VoIP telephony, but seems to occur frequently in systems that have just been deployed.

In traditional TDM voice transmissions, the circuits are reserved for two-way voice transmission, but in VoIP each voice stream is independent. Should one of the streams be lost, deferred, or misdirected, the call the results on has one active stream in one direction.

The most common reason for one-way audio is the result of improper negotiation of the RTP voice stream by a server that is behind a firewall - an unaccommodating firewall.

In a future post we will talk about how to isolate the offending firewall and how to work with the system or firewall administrator to set NAT parameters appropriately so that both RTP streams can be negotiated successfully.

Attacking VoIP Call-Quality Issues

2012-01-05T22:02:00.000-08:00

Call-quality issues are a bit trickier with VoIP than with traditional telephony.

One of the main problems with VoIP are the negative effects of the delays in transmission of packets. The latency is always inherent in converting a call to and from VoIP. But no matter how quickly that conversion occurs, if there are several, the cumulative effective latency can have noticeable degradation in quality. An end-to-end cumulative latency of great than 200 milliseconds (ms) causes human perceptible delay and results in conversations with participants that repeatedly interrupt each other.

Fluctuations in latency are also common on VoIP networks. This is commonly referred to as jitter. Jitter is in most cases caused by a leg in the call path that is sharing traffic with other applications or calls. The most common symptom of jitter is called "clipping."

A normal conversation sounds like this:
"Hi dear, shall I stop at the store to pick up some milk?"
but clipping produces:
"I ear, all op de ore ick om ilk"

In future posts we'll explore how to isolate latency and jitter to one or many legs of a VoIP call.

The Essence of VoIP Issues

2011-12-15T09:52:00.000-08:00

In the telephony world VoIP is a hybrid.

A VoIP solution usually has dedicated Internet connections, dedicated T1 voice circuits, and at two or or more points in a call a digital to analog conversion.

On top of these common telephony components, you add the complexities associated with IP packets: latency, real time transport of packets, call control channels translations, and dial plan nuances.

One of the first questions to ask yourself when troubleshooting a VoIP call is whether or not a problem exhibits itself on all of your calls or just select ones.

In future posts we will begin to begin to isolate trouble to the various components of the call circuit and learn what clues to look for with each isolated issue or problem.

The True Customer Experience of a Voice Service

2011-11-18T13:57:00.000-08:00

Customers perceive the quality of a voice service and the reliability of a voice service based on many different experiences. Such experiences may be good or bad, but very often customers notice only the bad experience – obviously as they buy a service that is meant to work 100% at any time and from anywhere.

Bad experiences are often caused by network related problems:

• Calls with degraded voice quality
• Interrupted or Dropped calls or VoIP Dropped calls
• Unsuccessful call attempts
• Missed calls that did not ring or calls that were not signaled

Also end device related problems bring negative user experience:

• Empty battery on smartphone
• End device & VoIP Endpoint crashes
• Inability to setup 3 party conference call

For all voice operators, over-the-top (OTT) and legacy networks, these end-device related troubles are very important. Because in the end the customer does not care at all why something is not working! He will blame it on his voice service provider anyway.

As a result when considering the management of customer experience in next generation voice networks, it is very important to look beyond your own network infrastructure. Internet connections, utilization and network problems on the customers’ corporate LAN and end devices cause a large portion of the problems. So it would definitively not be a good idea to consider a service running well, simply because in one’s own network, all systems are up and running.

Instead operators also need to manage:

• End device & VoIP Endpoint firmware versions
• App/softphone software versions
• IP link quality characteristics
• Performance and problems at your Customers’ premises
• Error logs from the end device

Very often problems can be solved by optimizing configurations, codec settings, centralized firmware updates or pro-actively contacting the customer about up-coming problems with his device or software. So a tool is needed that see the endpoint or VoIP device as well as the network. But for all of that, a customer experience management system must provide the full set of information about how the customer truly perceives the service End-to-End.

When looking at customer experience management for VoIP networks, operators should choose a holistic approach and carefully select software solutions that are designed to look far beyond the usual scope and take care about the most important stakeholder in this game – the customer.

VoIP Service Assurance Available in the Cloud

2011-11-14T19:50:00.000-08:00

Due to the huge amounts of traffic, telephone network analyzers are complex systems with beefy hardware requirements, complex setup procedures and the need for constant monitoring. For bigger networks the costs to run them is easily worth it, but for smaller networks deploying them might not be feasible. Be it for lack of time to learn how to run them, or because of a too big initial investment.

A recent trend in IT is the introduction of cloud services including for example cloud based service assurance or cloud based VoIP troubleshooting. In this setup the main part of the analyzer system is run in a central system, where it is managed by a knowledgeable and dedicated staff experienced in network monitoring and efficient VoIP troubleshooting. This leads to rapid deployment times and minimal investment to the point where one can just 'Try before you buy' so in other words, troubleshooting on Demand. The advantage of economy of scale brought by cloud based Network Management or cloud based Network Monitoring makes the most advanced analyzers available for even the smallest VoIP providers, leveling the playing field for all. You can even install it at the last minute in just a few seconds and use it when you have a problem

By deploying a VoIP traffic analysis in the cloud, you can usually achieve up-times far better than by using a complicated local setup and you can make sure that your running costs stay predictable. With today's technologies, security and data safety are a well-managed issue, all traffic streams being encrypted. A centralized software setup or hosted service assurance makes updates easier and your service provider is also able to diagnose and fix problems more efficiently by having complete access to the stack.

Cloud-based service assurance or network monitoring or VoIP troubleshooting can now be made available on a pay for use basis. Basically, you pay when you login to troubleshoot a problem on your network. If you do not have a problem, do not ever log in, you do not pay a cent. If you do login, for a small charge for one use, you fix the urgent problem that is troubling your customer. The return on investment for use of the network troubleshooting service is instant. The advantage of having paid the Per-Use fee is obvious to your management, because you have just fixed a difficult problem impacting your voice service. Keeping your customer, your customer and allowing you to move on to creating a new service or engineering your network

Cloud-based network monitoring gives you universal visibility and centralized and universal access to the analysis. One Installation and setup is so rapid it can be used on-demand when needed i.e. VoIP troubleshooting on Demand. In summation, cloud computing brings lots of advantages to VoIP service providers, (ITSP’s) who could not previously afford or justify the expense for a traffic analysis. With generally better availability, a transparent pricing structure (based on usage) and better support options, cloud solutions are surely an understandable trend in today's VoIP software stack market.

Network Visibility Matters

2011-11-10T07:27:00.000-08:00

“Knowledge is power” as the phrase goes and effectively, no matter what you want to achieve in your network management, a truly in-depth knowledge about your network processes is THE key asset when it comes to offering an excellent Customer Service and troubleshooting or to managing the overall network health with ease. Network knowledge and visibility allows you to find problems in minutes rather than hours, reducing operations costs and impressing your customer with rapid resolution of problems.

Today’s fast evolving telecommunication market with its multiple video & audio streams, a fast growing user base and geographically dispersed deployments is challenging and keeping an eye on the entire network doesn’t seem to be an easy task. Often, telecommunication operators are recurring to different systems or are not able to track back single network incidents which don’t provide a satisfying network visibility in the end.

First, choosing a solution that is able to process all signaling messages traversing the network in real-time and that instantly correlates multiple sites and network protocols is vital. Also, you will want to know the detailed status of the entire network health, the different application layers of the network, the end user devices and all the segments that a media stream is traversing through. A fully correlated end-to-end overview of all parts in the network can easily be provided when distributed agents are installed locally enabling a quick root-cause detection of network issues.

Talking about visibility, it is not only helpful to have an overall view of what is happening in the network, drilling-down into single calls, users, end devices and network devices is very valuable information as well. The perspective should be changed easily from a high-level overview for e.g. the operations department down to a granular and in-depth view of an individual user and its history which is helpful information for the customer service or support department. A filtering option will furthermore provide a high value to track users or to search for specific devices, numbers or customer groups, we which are known as realms.

A powerful network management tool should be able to provide past information about historical data, process data in real-time and should also allow a current and future proactive network management. Finally, a future-proof solution is a system which is easily integrated into an existing infrastructure reducing hereby the complexity, and instead of installing more hardware, it should be a lightweight solution that smoothly grows with the network.

A real-time intelligence software suite increases the ROI of LTE, IMS and VoIP deployments. It provides fixed and mobile operators a full end-to-end visibility and supports a multi-site and protocol call correlation.

Visualizing a VOIP Security Attack

2011-11-06T06:35:00.000-08:00

Visualizing a cyber attack on a VOIP server from Ben Reardon, Dataviz Australia on Vimeo.
Prevent a VoIP security attack on your systems!

One Way Audio and the Inability to Receive Incoming VoIP Calls

2011-11-02T20:16:00.000-07:00

As a VoIP Service Provider, you will no doubt have heard customers complaining about these two problems. In one case, the customer makes a call or Receives an incoming call and can hear their calling party. However, the calling party complains they cannot hear you. This is possibly because the VoIP Endpoint phone has a problem or there could be routing problem in the network.

More commonly, this is a problem with the firewall belonging to the enterprise. The enterprise network Administrator prefers not to allow incoming data sessions and for the VoIP session, the incoming RTP uses a different port to the outgoing RTP. The UDP port number used by RTP is negotiated by the SDP inside the SIP signaling at the commencement of the session or phone call. The actual details are subject to the implementation and configuration of the network and sometimes outgoing and incoming UDP ports for the RTP may be dissimilar.

Re-configuring the firewall and ensuring that the RTP port is the same for incoming and outgoing RTP streams will rectify this problem.

A similar problem, but more difficult to isolate, is where a customer complains they can make outgoing calls but their colleagues say they called your customer but their VoIP phone did not ring. The user can make outgoing calls. Failure of the incoming call is caused by REGISTRATION of their VoIP phone having expired on its registration server.

When a VoIP endpoint successfully registers on the registration server or the network, the registration server includes in its response, a time frame during which the REGISTRATION is valid. The VoIP endpoint/phone should RE-REGISTER with the registration server before half of the time period has expired.

Frequently, there is an imbalance between when the endpoint believes it should renew the registration and when the registration server expires the registration. A tool which can track the state of registration [New, Unauthorized, Expired or Gone] is invaluable in being able to find these stealth problems.

Wireshark will show you the time and relationship between such REGISTRATION messages. However, an advanced intelligent Service Assurance tool such as Palladion will track the state of each endpoint, and also the firmware release of each endpoint, allowing you to find these anomalies in seconds.

MOS [Mean Opinion Score] for High Definition or Wideband Telephony

2011-10-29T17:21:00.000-07:00

Mean Opinion Score [MOS] is a scale from 1 to 5 indicating speech quality - 1 is bad and 5 is excellent. MOS 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 ITU-T P.800. In over 16 years 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.5.

High Definition or Wideband Telephony speech uses the new POLQA speech quality metric for objective protection of MOS. The old PESQ algorithm has been used for narrowband telephony since it was approved in 2000. 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. You could conceivably measure a MOS value of 4.75 if you were measuring super wideband equipment.

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.

The picture shows the iLBC codec measured measuring 4.21 narrowband focus scale.

For more information on making PESQ and POLQA measurements, ensure you contact only renown 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 and correlates to human subjective experience

The most trusted vendor for speech quality metrics is Malden Electronics, available in USA through Teraquant Corporation – www.teraquant.com

See use in http://technorati.com - X84QTD2E9BS6

Can You Hear Me Now?

2011-10-25T10:11:00.000-07:00

PolQA is the new ITU-T Standard for Speech Quality Measurement which embraces Wideband or High Definition Telephony.

“Can you hear me now?”

We’ve all heard the refrain. How often have you been on a mobile phone & not been able to hear your calling party? How often have you experienced drop-outs on a VoIP call and missed that vital clue, that's important piece of information the caller mentioned which allowed you to understand their needs. May be you lost the business as a result. Good clear speech quality means productivity, both in business and in personal life. Everyone is critically busy these days and if you have to ask folks to repeat themselves, you waste time, first-rate meaningful conversation and miss information.

The existing telephony network uses 200-34000Hz analog bandwidth, digitized at a sampling rate of 8kbps. 8 bits of vertical resolution multiplied by 8kbps gives the traditional 64kbps bandwidth required for a voice channel. Compression by codecs such as G.729 and iLBC VoIP and specifically iSAC for Skype and GSM-FR & EVRC for wireless transmits narrowband traditional telephony at data rates as low as 4kbps.
So now we can compress voice sports to very low bandwidths and at the same time we have broadband Internet. so what can we do to improve speech quality.

Wideband or High Definition Telephony technology is now appearing in VoIP networks and wireless networks using voice codecs such as G.722 and WB-AMR. This provides speech with an analog bandwidth up to 7kHz and gives a richer listening experience. Those problems you currently have trying to recognize which of your young nieces or nephews is speaking to you is due to high frequencies filtered out with narrowband telephony. Wideband telephony will reinstate these, enriching your telephone conversation experience and improving productivity through speech clarity. This technology will eventually send telephony speech all the way up to 20 kHz, the limit of human hearing, equivalent to hi-fi music systems.

3gpp release 5 introduces AMR-WB codec which gives enhanced speech quality using data rates of only 16kbps. So wideband telephony or high definition telephony is being made available to wireless cellular networks.

Tools to Automatically Measure Speech Quality

Determining the subjective speech quality of a transmission system has always been an expensive and laborious process. The tool described in ITU-T Rec. P.862 Perceptual Evaluation of Speech Quality – PESQ provides a rapid and repeatable result in a few moments. PESQ is an objective measurement tool i.e. a computer measures the quality of the received audio in relation to the audio that was transmitted. PESQ predicts or has a very accurate close correlation to the results of subjective listening tests [i.e. human beings listening to speech files] On telephony systems. The resulting quality score is analogous to the subjective “Mean Opinion Score” (MOS) measured using panel tests according to ITU-T P.800. Strictly speaking, MOS is a score derived from human subjective testing. The PESQ scores are calibrated using a large database of subjective tests.

The ITU-T selection process that resulted in the standardization of PESQ involved a wide range of conditions, with demanding correlation requirements set to ensure that it has good performance in assessing conventional fixed and mobile networks and packet-based transmission systems.

Since ITU-T Rec. P.862 was originally released in 2000, further mappings of the PESQ score have been created. PESQ-LQ modified the score to improve correlation with subjective test results at the high and low ends of the scale where the raw PESQ score was found to be less accurate. A new mapping described in ITU-T Rec. P.862.1 was been released that further modified the raw score and correlated better to subjective testing.

PESQ Shortcomings - Time Warping

PESQ takes into account coding distortions, errors, packet loss, delay and variable delay, and filtering in analogue network components. The user interfaces have been designed to provide a simple access to this powerful algorithm, either directly from the analogue connection or from speech files recorded elsewhere.

PESQ Shortcomings
Noise Reduction: (Subjective > PESQ)

The performance of a network or a network element can be fully characterized using high quality analog test equipment and PESQ. High quality analog interfaces are needed because the test equipment itself very easily introduces impairments which are included in the measurement and drank the desk score lower than should be measured for the system under test or network element. Whilst it is possible to use phonetically balanced sentences and other test patterns, accurate and repeatable measurements of the active speech level, activity, delay, echo, noise and speech quality can be obtained quickly using artificial speech test stimulus in different languages, which comprehensively tests all voice sounds the codec may be incident with, but at the same time achieves the process quickly in a time efficient way. A graphical mapping of the errors provides a useful insight into how the signal has been degraded and exactly what kind of sounds course the codec core system and test problems.

Since the launch of PESQ in 2000, there have been many advances in codec design. Unfortunately, PESQ was not trained on these later designs and can produce scores that are lower than expected from subjective tests. Time-warping and voice quality enhancement techniques are particularly difficult for PESQ. The ITU agreed on a new standard, P.863 POLQA, in 2010. POLQA addresses many of the issues and produces reliable scores for codecs, both old and new. POLQA is Now available on a couple of speech quality measurement platforms but Malden is the only platform that provides a quiet, high-quality analog front-end and the only platform to be recommended.

Network Monitoring - It's Your Livelihood

2011-10-21T14:28:00.000-07:00

What are your daily duties as the VoIP network operations director? You have to keep your network up and running. You have to answer calls which may relate to situations like “X location is down” or “Y location is slow”. My we suggest that you proactively monitor your network as described below and perform tasks like:

Monitor your network and take actions with respect to situations like device and line failures.
Analyze line/physical facility utilization, errors on the facility and be sure about network performance and conformance to SLAs.
Be aware of what "talks to what" and when? Be sure how much bandwidth is needed for every single application riding your network (and the networks you traverse.)
Know your exact data flows over your networks.

If you have all this information at your disposal, people will think twice before they point finger at you.

But how can you achieve this?

You need a phased approach to understand network monitoring. I am not talking about network layers, but network monitoring layers. We have to involve deeply to monitoring layers before deciding about network monitoring software needs. A simple summary could include these:

Preconditions of network monitoring.

Up/Down monitoring

Performance Monitoring / SNMP monitoring

Who talks with whom? / Netflow monitoring

Data capture / Data sniffing

Preconditions of Network Monitoring
Network documentation is essential to monitor a network. Trying to set up network monitoring tools before going through the documentation is a complete waste of time. You will see everything green on the screen, but this maybe due to one of the redundant lines that are down. You will sit staring without knowing what is happening. Always remember, documentation comes first and everything follows.Suggested Network documentation tools: Powerpoint/Visio, NetViz

Up/Down monitoring
Design a map in which you can see some red and green lights glowing. Green means up and red means down. It is simple yet powerful. You will immediately come to know that there is some problem if the red light glows.This is based on ping. Almost every IP devices support echo/echo reply. So, you can monitor all IP devices in your network by using ping. Go one step further by monitoring one application at a time present on a device instead of whole device. All network applications utilize TCP/UDP ports. You can monitor the applications by trying to access with telnet to its TCP/UDP ports. The port being open suggests that the application is running
Suggested monitoring tools: WhatsupGold, nmap

Performance monitoring / SNMP monitoring
The lines are up, the devices are up, but life is not perfect. People may complain about the performance of data lines, but are they saturated or do they have plenty of spare bandwidth? Is there packet loss on the lines? Are routers running out of memory? We need SNMP to monitor the heart beat of the network.
Suggested monitoring tools: MRTG, Solarwinds Orion, PRTG

What is "talking" with what? / Netflow monitoring
You may realize that the line is full, but is someone or some applications increasing traffic load enormously. Who are they? Is it necessary traffic? In some devices, by using “ip accounting” command you can get an idea of current traffic sources and destinations. Nevertheless, to analyze and to optimize the traffic we need flow monitoring. We need to know source and destination IP addresses and TCP/UDP ports and number of packages/bytes.

Everyone blames the network speed until you publish an network usage report that clearly shows only 15% of the traffic is ERP traffic and rest comes from Internet access.You should know that flow monitoring tools requires more server resources, since they collect enormous amount of data.
Suggested monitoring tools: Fluke Netflow monitor, Paasler

Data capture / RMON – Sniffer tools
Sometimes you need to observe the exact data flow on the line and not just information about it. Just have a look at this sample scenario. After you find out that the web service causes inappropriately high network traffic, the owner of the application just can say “No, we are not pushing this much of data to network. We just respond Yes or No in this web service and it is just 100 bytes”. Therefore, you should sniff the data flow on the line. Maybe, you will find that web service responds yes or no (100 bytes) and with the definition of web service (6 kilobytes).
Suggested monitoring tools: Wireshark, Palladion

You can have a look at Network Monitoring Tools in Stanford University web site for a superb list of network monitoring tools. You can find another tidy list at Network Traffic Monitoring in Alan Kennington’s topology.org.

IP PBX Toll Fraud - Everyone Is At Risk

2011-10-17T19:20:00.001-07:00

It seems no one is safe. Every IP Telephony Service Provider [ITSP] I have talked to has suffered an IP PBX hack. End Users of VoIP phones most commonly do not remember or know how to change the password on their PBX or voicemail account. Default passwords for a PBX are usually the last four digits of the phone extension so hackers can easily cycle though to determine a weak or discoverable password. Once into the PBX, they can originate calls from anywhere on the Internet and pump traffic volume to numbers that will realize them fraudulent revenues

Voicemail can be configured to dial out eg when you hear the greeting “please wait while we attempt to reach your party”, of course the voicemail system is making an outbound call which is setup by the hacker to redirect to their intended destination.

The fraudster can resell such phone capacity. One of the nice advantages of VoIP is its built in features for Moves, Adds and Changes. When the time comes to move office, you can just pack you VoIP phone and take it with you. Plug it into the internet or your companies IP cloud and it will register with your IP PBX and you can make calls. If you travel, you can take your VoIP phone with you and plug it into the internet in your hotel room and makes calls as if from your desk. So The PBX has no concept of your physical location or who is using the phone and so fraudsters, once they hack your PBX can make calls from anywhere, using your account.

The Telecommunications industry has annual revenues of $2.1 Trillion. Telecom fraud is calculated to cost the telecom industry $40 Billion each year.

The calls come out of your IP PBX, to your ITSP, offering a SIP Trunking service (i.e. a service that routes calls from a VoIP environment to the PSTN and therefore to any expensive international destination offered. So your ITSP receives an invoice from the International carrier for all these international calls. Fraudsters often choose weekends or other times outside business hours to attack. This way, the attack goes unnoticed and the account is beaten to death whilst no one notices or cuts it off.

“How to lose your year’s profits in 15 minutes!” was the way one of our customers described Toll Fraud. The ITSP receives this rather large bill from the international carrier. If he demands payment from the enterprise which has allowed their IP PBX to be hacked, he will surely loose a customer. Small companies who typically have small telecom bills can afford suddenly to pay up for a $20,000 to $30,000 bill. Many events run into the hundreds of thousands.

Although the ITSP caught in the middle may be to share some of the costs with their customer and the international or long distance carrier, they cannot afford to lose customers and will not often impose the charges on their client. So this is a loss the ITSP usually has to take on the chin.

How can we detect it in real-time and turn it off in real-time to prevent the cost leakage? Advanced monitoring systems are now available which will not only detect the fraud attack in real-time but will also turn if off.

11 Million Euro Loss - 1 Million in Profits - VoIP Fraud

2011-10-13T16:21:00.000-07:00

Recent Voice over IP fraud attackers made over 1 million Euro in profits.
It seems that they simply were scanning for PBX servers with phone extensions that have weak passwords. Then they abused these accounts to make phone calls for "free", except that free has the price of 11 million EUR for the service provider victims!

Apparently, originally they used these accounts for their own personal phone calls. However they got greedy and between October 2009 to February 2010, they made 23500 calls / 315000 minutes to premium numbers. Then (from what I understood), they got even more greedy and used a Shadow Communication Company and prices for premium numbers that then linked to another site further obfuscating their "business." Using this scheme they recruited other people to make 1,541,187 fraudulent calls or 11,094,167 minutes of talk time.

They used other premium numbers affiliate networks at first and then, when they realized the potential, they set up a company in the UK - Shadow Communications Inc. - through which they were able to sign a contract on their own with a premium rate number provider and offer their own affiliates service, basically taking their "business" to a whole new level.

One of the original articles on this can be found here.

Storming SIP - VoIP Systems Are The New Target

2011-10-09T16:12:00.000-07:00

You Will Be Attacked - Reduce Exposure

When implementing a VoIP infrastructure or any kind of network technology, it is best to reduce the exposure to attack. The fact that the VoIP infrastructure is typically sitting next to other network entities makes the SIP network elements reachable and possibly vulnerable to an attack coming from the other network servers. The number of VoIP phones and PBXs on the Internet is constantly growing, and if the infrastructure does not require exposure to the Internet, then avoid it. To help you separate the VoIP network from the rest, various network switch vendors allow you to set up a VLAN specifically for VoIP. However, be aware that VLANs are not a panacea, and tools like VoIPhopper make it easy to demonstrate the fact that VLAN is not enough. Cisco published a white paper called VLAN Security, where they describe how to protect against a number of attacks aimed at VLAN technology. Segregating the VoIP network can also be done through the use of firewalls or physical separation. VPN tunneling has also been previously suggested because it provides both encryption and can also be used to separate the VoIP traffic from the normal traffic.

However, these solutions might not always be feasible – especially since one major advantage of VoIP is that it integrates with other network elements on the Internet. In fact, various VoIP vendors market the fact that you can use your existing network infrastructure without having to lay new cables. Whether or not this is a good idea depends on a large number of factors. When designing a VoIP infrastructure, it is therefore important to understand the requirements and mitigate depending on the case. For example, a hotel VoIP network will have different requirements than a corporate IP phone network, and therefore a systems designer can apply different security precautions during the planning stage. Some other suggestions and observations:

• It is of course good to make use of encryption mechanisms such as TLS and SRTP. Unfortunately, the encryption for SIP and RTP is not yet widely supported. Zfone by the creator of PGP is particularly interesting. We shall not be going through this subject in depth since it is not within the scope of the attacks described within this article, but it definitely deserves a mention.

• The importance of good passwords for IP Phones should not be underestimated. If the system does not require that end users set their own password, then do not allow this functionality. Instead, make use of some kind of password management and set their password to one that is unique and hard to guess. Applications such as KeePass, which is open-source and free, allow you to generate strong random passwords for you, as well as manage such passwords in a relatively secure manner.

• OpenSER, which is an open-source SIP server, has a module named pike. This module is able to block requests that exceed a given limit. This can allow for blocking of both extension guessing and password cracking. However one has to be cautious with such solutions. Attackers can make use of IP spoofing to intentionally block legitimate traffic. It might also unintentionally block legitimate traffic if its not properly conFigured.

• SIP allows extension lines which do not require authentication. If there is no justification for unauthenticated extensions, then make sure NOT to use this feature.

• Hardphones will get security fixes in the form of a firmware update, while softphones will get a new software release. Keeping up to date with the latest versions can be a pain, but it is certainly one way of making sure your system does not fall victim to attackers exploiting a security vulnerability in your SIP phone.

You Are Under Attack

Detection is a very important step in a security solution. A network IDS such as Snort, when placed at the right location, can be of great help when trying to detect that an attack is underway. Snocer, which describes themselves as providing Low Cost Tools for Secure and Highly Available VoIP Communication Services, has previously published some Snort rules for public consumption. These rules are also available in the latest Snort community rules. In this section we will describe some of them and explain how they can be effective in catching the attacks mentioned previously. We will also provide some new Snort rules which can also detect activity described in this article and not caught by the current Snort community rules.

The Snort rules by Snocer are quite easy to understand, and are able to provide generic detection. Each of the rules looks out for an excessive number of SIP messages coming from a single IP address over a short period of time. The different SIP messages are INVITE and REGISTER requests, and 401 Unauthorized messages.

The INVITE and REGISTER flood attacks catch svwar and svcrack being run with default options against a SIP proxy. To be able to catch a default svmap scan, we need to be looking out for SIP messages with an OPTIONS request, spanned over different hosts in a short time. Listing 20 shows one such rule that triggers an alert if the rule is infringed 30 times in 3 seconds. One should probably adjust this rule depending on the address space being watched by Snort. If Snort is watching a /29 mask, i.e. only 6 hosts, then one should change the count to 6 and number of seconds to 1 or less. On larger networks, increase the count number to decrease the chance of a false positive.

The rule on excessive number of SIP 4xx Responses attempts to catch the majority of attacks outlined in this article. What it effectively does is match responses which contain a client error. This may be a 404 not found response like the one given by an Asterisk box when running svwar to identify SIP extensions or users. It will also match a password cracking attempt on an Axon PBX, or an extension enumerating attack on a Brekeke PBX when using svwar with the OPTIONS method. Of course, it will not catch a network scan for SIP devices on one which does not have a lot of devices, simply because the number of responses would be low.

The ghost phone call can also be easily detected since it generates a large number of ringing messages. Of course a payload of this attack is audible, and therefore the benefits of adding this rule might not be immediately apparent since it makes itself so obvious. However, a Snort rule at this stage might be very useful during incident response, when trying to determine things such as the source of the attack. The rule should be modified depending on the network. For example, it does not make sense to deploy this Snort rule on a calling center that takes 50 calls every minute.

Snort is not the only tool to monitor your VoIP infrastructure for attacks. In fact, Snort would very likely NOT detect any attacks passing through encrypted traffic. On the other hand, monitoring the logs on your IP PBX might be a good way of detecting some attacks destined to the SIP gateway. J. Oquendo posted a BASH script called astrap which monitors the Asterisk log entries for excessive number of failed authentication attempts. This small tool will list the offender's IP address, the number of password failures, and the extensions that were targeted on the Asterisk.

A host intrusion detection system such as OSSEC can be equally useful in detecting and automatically mitigating attacks. At the time of writing, OSSEC does not come preconFigured to support Asterisk log files, but this functionality can be easily added. Listing 21 includes a sample rule file for OSSEC to show how it can be conFigured to detect username enumeration and password attacks on an Asterisk system such as Trixbox. Listing 22 shows the changes required to enable this new Asterisk rule. We include a decoder entry so that OSSEC will be able to extract the attacker's IP address and then use that to automatically block the attack by adding the appropriate firewall rule.

References

• http://www.ietf.org/rfc/rfc3261.txt – RFC 3261

• http://www.iptel.org/sip/intro/purpose – Purpose of SIP

• http://www.wormulon.net/ – smap

• http://sipvicious.org/ – SIPVicious tool suite

• http://tinyurl.com/rtjl8 – SIP peers external authentication in Asterisk/OpenPBX

• http://www.hackingvoip.com/ – SIPSCAN

• http://www.oxid.it – Cain and Abel

• http://tinyurl.com/yph6jy – Interview with Robert Moore

• http://tinyurl.com/56bwd – VLAN Security White Paper

• http://www.snocer.org/Paper/sip-rules.zip – Snocer, snort rules

• http://www.infiltrated.net/scripts/astrap – astrap

• http://www.ossec.org/ – OSSEC

• http://www.trixbox.org/ – Trixbox

Hat Tip - Sandro Gauci

SIP Peering KPI’s - How to Measure Answer Seize Ratio

2011-10-05T20:47:00.000-07:00

Service providers have for many decades measured key performance indicators for their SS7 interconnects with long-distance or international operators or peering partners. Such measurements are defined in ITU-T Recommendation E.411 "International Network Management – Operational Guidance" and E.422 "Quality of Service for Outgoing International Calls" and include Answer Seize Ratio [ASR], Post Dial Delay [PDD] and Network Efficiency Ratio [NER].

Name	Description
Counted	Number of calls
ASR	Answered calls (percent)
SSB	Subscriber busy (percent)
CGC	Circuit Group Congestion (percent)
SEC	Switching Equipment Congestion (percent)
CFL	Call Failure (percent)
RSC	Reset Circuit Signal (percent)
UNN	Unallocated Number (percent)
ADI	Address Incomplete (percent)
CLF	Clear Forward (percent)
LOS	Line Out of Service (percent)
rt	Response time (average)
wt	Wait time with answer (average)
wna	Wait time with no answer (average)
ct	Call time (average)
ht	Hold time (average)
Minutes	Total Call time in minutes

Table 1

Answer Seize Ratio [ASR] is used as a measure of network quality although the measurement also includes user behavior. In other words, if the call was not answered, the network could not be faulted, although the ASR measurement would be reduced by the uncompleted call, indicating lower quality. However, because for a given hour within a day, unanswered calls would always represent the same percentage, from day-to-day, this offset would be normalized out and carriers are able to monitor the trend of ASR and treat it as a relative measurement

Network Efficiency Ratio was designed to eliminate user behavior as a factor and better represent pure network performance.

Network Efficiency Ratio [NER] is defined as:

User Answers or Normal call clearing - Cause code: 16

+ User Busy - Cause code: 17

+ Ring No Answer - Cause code: 18 & 19

+ Terminal Rejects) - Cause code: 21

NER = -------------------------------------------------------x 100

(Total # of Call Attempts i.e. IAM’s)

SIP is a more flexible protocol and has wider uses than simple call control. Therefore, use cases differ widely and systems such as voicemail and call forwarding skew expected behavior for answered calls

Furthermore, SIP is a more flexible protocol and has wider range of response messages which can be used to specifically indicate certain types of failures from either servers, network devices or the movement or absence or other behavior of users. Accordingly, IETF has defined KPI's equivalent to Answer Seize Ratio and Network Efficiency Ratio. These are described under SIP End-to-End Performance Metrics draft ietf-pmol-sip-perf-metrics-04. For example, the equivalent of ASR is Session Establishment Ratio (SER)

Session Establishment Ratio (SER) is defined as follows, to quote the IETF

“This metric is used to detect the ability of a terminating UA or

downstream proxy to successfully establish sessions per new session

INVITE requests. SER is defined as the number of new session INVITE

requests resulting in a 200 OK response, to the total number of

attempted INVITE requests less INVITE requests resulting in a 3XX

response. This metric is similar to Answer Seizure Ratio (ASR)”

The SER is calculated using the following formula:

# of INVITE Requests w/ associated 200 OK

SER = --------------------------------------------------------- x 100

(Total # of INVITE Requests)-(# of INVITE Requests w/ 3XX Response)

Here is the message flow which defines the basic SER. if the session INVITE request results in an interim response, such as a 302 Redirect response, this should be subtracted from the denominator.

UA1 UA2

| |

|INVITE |

+----------->|------------------>|

| | 180|

| |<------------------|

Session Established | |

| | |

| | 200|

+----------->|<------------------|

| |

In SS7, the fate of the call is determined by the RELEASE message which ends the call. The fate of a SIP call is determined by the Response to each Request for each transaction within the SIP call. For example as above, session establishment is determined by a successful outcome from the call session establishment phase

The SIP Peering KPI’s RFC 6076 also defines Session Establishment Effectiveness Ratio (SEER) which is similar to Network Efficiency Ratio [NER] in the SS7 ISUP circuit switched world.

This metric is complimentary to SER, but excludes the effects of the terminating UAS or endpoint i.e. it excludes user behavior from the metric and therefore more closely reflects the performance of the network. SEER is defined as the number of INVITE requests resulting in a 200 OK response and INVITE requests resulting in a 480, 486 (Busy Here i.e. that endpoint is busy), or 600 (Busy Everywhere; i.e. the interconnecting network is busy or congested or down) to the total number of INVITE attempts less the 3xx, interim responses.

In order to simplify the formula, the following variable ‘a’ is used to summarize multiple SIP responses:

a = 3XX, 401, 402, and 407

The SEER is calculated using the following formula:

# of INVITE Requests w/ associated 200 OK, 480, 486, or 600
SEER = -------------------------------------------------------- x 100
(Total # of INVITE Requests)-(# of INVITE Requests w/ 'a' Response)

SIP response codes

2xx—Successful Responses

Eg 200 OK

4xx—Client Failure Responses

401 Unauthorized (Used only by registrars or user agents. Proxies should use proxy authorization 407)
402 Payment Required (Reserved for future use)
480 Temporarily Unavailable
486 Busy Here

6xx—Global Failure Responses

600 Busy Everywhere
603 ADD

Another very useful measurement defined by the IETF here is Session Defects Ratio (SDR), also graphed by Palladion by checking a box. ‘503’ SIP Response messages commonly indicate a route to one of your peering partners is failing due to congestion of the Gateway or SoftSwitch.

Session Defects Ratio (SDR) is the percentage of call attempts receiving the following responses, in relation to total call attempts or INVITES:

o 500 Server Internal Error

o 503 Service Unavailable

o 504 Server Timeout

The SDR is calculated using the following formula:

# of INVITE Requests w/ associated 500, 503, or 504
SDR = ----------------------------------------------------- x 100
Total # of INVITE Requests

In addition to this, some carriers like to plot Post Dial Delay, [PDD] and to generate an alert when this measurement exceeds a certain time threshold. PDD is defined as the time interval between transmission of the INVITE and reception of the ‘180 Ringing’ response message. The RFC prefers to define Successful Session Setup [SRD], the SIP equivalent of Post-Selection Delay (defined in E.721). This is an early indication of congestion soon to or about to occur on a given route and is a very useful KPI. Palladion can be configured to provide an SNMP trap or other notification to the Network Operations Center [NOC] of this imminent congestion so preemptive action can be taken.

Here is a table listing all the new RFC 6076 KPI’s with their SS7 or circuit switched equivalent:

SIP Peering KPI’s RFC 6076	SIP Definition	ISUP Equivalent	ISUP Definition
Registration Request Delay (RRD)	Time of final response – time of REG attempt	N/A Note *
Ineffective Registration Attempts	# IRA/total REG attempts	N/A
Session Request Delay (SRD)	Time of response – Time of INVITE
Successful Session Setup [SRD]	Time of response – Time of INVITE eg INVITE to 180	Post-Selection Delay (defined in E.721)	IAM to ACM (or ALERTING)
Failed Session Setup [SRD] and	INVITE to response indicating failure eg 4XX (excluding 401, 402, and 407 non-failure challenge response codes), 5XX, or 6XX message.	N/A	IAM to REL with a cause code indicating a failure
Successful Session Disconnect Delay [SDD]	BYE, to 2XX Ack	Time to Clear a good Call or CIC	REL to RLC
Failed Session Disconnect Delay [SDD]	BYE, to Timer F Expires	essage	Missing RLC i.e. expiry of ISUP T1 timer
Session Duration Time [SDT]	Time of BYE or time out – Time of 200 OK	Time of REL - Time of ANS	Average Call Hold Time (ACHT)
Successful Session Duration Time	200 OK response to an INVITE to BYE	See note below *
Failed session duration SDT	200 OK response to an INVITE, and the resulting Timer F expiration.	“awaiting Answer timer”	SS7 ISUP timer T9 (no response to ACM)
Session Establishment [SER ] Ratio	# of “good call” INVITEs ---------------------------------- X % Total INVITEs – interim 3xx Responses	Calls which connect Calls which fail	Answer Seize Ratio (ASR)
Session Establishment Effectiveness Ratio (SEER)	(# of INVITE Requests w/ associated 200 OK, 480, 486, or 600) ------------------------------ X % (Total # of INVITE Requests)-(# of INVITE Requests w/ 'a' Response)	NER = Answers (cc 16) +UserBusy-cc 17 + Ring No Answer (cc 18, 19 & 21) + Terminal Rejects) _____________ Total call attempts	Network Efficiency Ratio (NER) ITU E.411.
Ineffective Session Attempts (ISA) Invites resulting in:- o 408 Request Timeout o 500 Server Internal Error o 503 Service Unavailable o 504 Server Timeout	# of ISA x 100 ----------------------------- Total # of Session Requests		Ineffective Machine Attempts (IMA) in telephony applications of SIP, and was adopted from Telcordia GR-512-CORE [GR-512].
Session Completion Ratio (SCR) (a Session Completion is any SIP dialog that receives a valid response)	# of Successfully Completed Sessions x 100 ------------------------------------------ Total # of Session Requests	Call Completion Ratio (CCR)

Notes:

· * REGISTRATIONs are rare across SIP peering points as these interconnects are typically between two trusted environments. In addition SBC’s are used to protect the sanctity of each network. Similarly an interconnect between two SS7 networks is a trusted and secure interface, so accordingly, no equivalent of REGISTRATIONs exists in SS7, although the MTP3 protocol is used to establish routing between Signaling Point Codes and ISUP control messages to set up voice trunks

· ** Monitoring for short duration Successful calls in a circuit switched network has not been as important and for a VoIP network as speech quality is not so much of an issue in circuit switched networks. In a VoIP network, short calls are important to monitor because if speech quality is so bad, the callers hang up immediately and call back, ….hopefully.

References

· Basic Telephony SIP End-to-End Performance Metrics Request for Comments: 6076

· ITU-T Recommendation E.411 : International network management - Operational guidance

· ITU-T Recommendation E.422 : Observations on international outgoing telephone calls for quality of service

· Telcordia GR-512-CORE - LSSGR: Reliability, Section 12

Double Your Profits from VoIP Network Operations

2011-10-01T13:57:00.000-07:00

To run large VoIP Ops, you need switches; routers; SBC’s and App Servers to switch or route calls, billing systems, of course – these are the basic building blocks. But why should we spend money on tools & monitoring systems when some tools are free?

Assume for a minute, as a VoIP service provider you allocate expenses as follows:

25% Admin & Regulation
25% Sales & marketing
25% Engineering expenses & 1 yrs. Depreciation of CAPEX
25% cost of Network Operations
Say for sake of argument your EBITDA is 10% of revenue

If you were to reduce cost of Network Operations by 37%, you would double your profits from VoIP Network Operations:

37% x 25% = 9.25% x 100% of total costs

37% of Net Ops is 9.25% of total costs

9.25% + 10% (current EBITDA)

You just ~ doubled your profits

As a VoIP Ops Director or Engineer, Which one of these is you?

1. You wish you could clone yourself. There is enough work for two of you to do.

2. You are constantly distracted with operational problems. You are not able to complete the many engineering projects you need to?

3. You would like to double your company’s profits

4. you would like to solve problems in the network and make sure they never happen again

5. you would like to solve your customer problems proactively, without them needing to call to complain

If you are using one of the following methods to troubleshoot VoIP Network problems:

• syslogs and on board server or switch diagnostics

• Wireshark

• Old legacy network monitoring systems

• A tool that only provides a Ladder Diagram

Then you have the opportunity to automate Voice Network Operations, eliminating huge amounts of time and saving costs. Automation is key to maximizing profits from VoIP Net Ops. VoIP signaling is complicated and every equipment vendor implements differently. You need specialists to make it work but everyone has finite bandwidth. So give them the tools to succeed. Get VoIP Net Ops under control and their skills will go further. Streamline VoIP Net Ops and your bottom line will benefit. If there is a solution out there for the taking, then take it.

Some network operations teams have quantitatively measured the improvements and efficiencies that VoIP Service Assurance has delivered to them. Do the calculation. Apply these cost improvements to your business. Those operations teams have:

Reduced operations support costs by 37%
Reduced the number of Trouble Tickets by 60%
Resolved Trouble Tickets in 14% of the time previously taken
Empowered Tier 1 staff & CSR to solve issues independently, freeing up their time

Apply these calculations to your VoIP Network Operation. You could at a minimum double your net profit

All you need is the visibility to immediately see:

when a problem has occurred or is about to
which of your customers are involved
which parts of your network are affected (network devices; VoIP phones; trunks; SBC’s etc)
the root cause

If you can solve in 1-2 minutes what currently takes you 1-2 hours. If it currently takes you 60 minutes to find the bad call but you were to reduce that to 3 minutes, you are on the way to a competitive advantage from VoIP operations.

Root Cause Analysis is key to VoIP Net Ops efficiency. If your competitors solve 100 Trouble Tickets in 5 man x hrs. and you take 80 man x hrs., who will survive? You or your competitor?

If you can integrate the remedial action with your service infrastructure and OSS/BSS, then you can really move ahead of the pack.