system toolbox » voip

koliko sam upratio ona druga strana nema problema sa echo-om, ja čujem echo kod sebe ali ovo nisam skroz načisto

testirao officesa -> officeze, tu je zvuk kaže saša odličan, a i ja nemam echo-a

u sip.conf sam se ograničio na alaw kao najkvalitetniji codec

[general]
srvlookup=yes
context=demo
;allowoverlap=no                        ; Disable overlap dialing support. (Default is yes)
bindaddr=0.0.0.0                ; IP address to bind to (0.0.0.0 binds to all)
canreinvite=no
;srvlookup=yes
language=bs
localnet=192.168.45.0/255.255.255.0
disallow=all  <<<<<<<<<<<<<<< prvo zabraniš sve codec-e
allow=alaw    <<<<<<<<<<<<<<  pa onda jedan po jedan dozvoliš
;allow=gsm

testirao sam sa allowed only alaw as officeze i mob-vsasa i nemam echoa imam ok zvuk

http://www.voip-info.org/wiki/view/Causes+of+Echo

In Brief:

Its most likely your echo is caused by the far-end point. The loudness of the echo on VoIP calls is no worse than PSTN calls. The difference is that because of the inherent delay induced by VoIP, echo is much more noticeable.

Remember, for echo to be noticeable it has to be both loud AND delayed. In the normal PSTN world echo is loud, but NOT delayed therefore you don't notice it. Its for this reason Telcos almost NEVER have echo cancel for local calls (hardware echo cancellers are expensive so why put them where you don't need them?). This is why in many cases you will notice bad echo on local calls but not on long distance or calls to cell phones. Long distance and Cell phones always have echo cancellation. Some local calls may also have it which is why echo is often intermittent.

Solution: The only thing you can do is implement echo cancellation as close to the far end point as possible. Since you don't control the Telco, most likely that is whatever you have connected to the PSTN (Asterisk box).

This page http://www.aussievoip.com/wiki/index.php?page=EchoInfo has a very good explanation.

The phenomenon known as echo - whereby one or both parties hear what they just said a few milliseconds later - is one that seems to affect VoIP users frequently. It can range from being mildly irritating, to being utterly unacceptable.

It's important to fully understand the causes of this effect, before you can take measures to eliminate it. This page attempts to explain clearly where echo comes from. Only once you've read and understood the explanation given here should you consider Asterisk echo cancellation.

Typical telephone connection

Leaving VoIP out of the equation for a minute, a typical peer-to-peer telephone conversation looks a lot like this:

>)--<-+                              4-wire trunk                                     +>-(<
      |                       -------------->--------------                       |
      |   2-wire local loop   |                               |   2-wire local loop   |
    Hybrid <---------------> Hybrid                         Hybrid <---------------> Hybrid
      |                       |                               |                       |
      |                       --------------<--------------                       |
 o)-->+                                                                               +<--(o

Caller                                                                                Callee

This shows a (slightly simplified) connection, with two-wire segments between the two subscribers and their local exchanges, and a 4-wire (transmit and receive pairs) line between the exchanges, and within the telephones themselves. There are "hybrids" at each end to divide the 2-wire local line into the 4-wire trunk, and to connect the telephone microphone and earpiece to the 2-wire local lines.

The 2-wire local loop is often known as a POTS (plain old telephone service) line.

Sources of echo

There are several points in the above system where echo can be introduced.

From the Caller's perspective, these are:

• Within the caller's telephone; a certain amount of the signal from the microphone is fed straight back to the earpiece. This is often done by design, and in any case, is not a problem here - more on why later. A particular special-case of this is a poorly-configured analogue (eg TDM400P) card - for example, the default (FCC) is not suitable for the UK.
• At the hybrid at the callee's end. An improperly balanced hybrid won't correctly filter out all of the transmitted signal, and will reflect some of it back down the other half of the trunk. Imbalance may be from poor design (common) or unpredictable impedance conditions on the POTS line (very common). The latter includes factors such as:
  o wet or damaged POTS cable
  o bridge-taps (something done by the telco, seldom seen any more)
  o cheap analog phones attached to the local line
  o some expensive analog phones on the local line
  o use of lengthy untwisted wire within the subscriber's premises
• At the handset at the callee's end. If the callee isn't holding the handset against his head, or if the handset is poorly designed, it's possible for the microphone to pick up the sounds coming from the earpiece, and reflect the audio back down the line.

It's worth noting that each of these points only introduces echo in one direction; each distinct echo-introducing component will only produce echo for one user - which, as can be seen from the list above, may or may not be the nearest user. It's also worth noting that not all of the above sources are necessarily bad - see the next section.

The importance of latency

Knowing potential sources of echo is not, in any way, the whole story. For echo to be a problem, it needs to be both (a) loud and (b) delayed from the original noise. Consider this: what would happen if, every time you spoke, you heard yourself speaking and thought someone was trying to interrupt you! To this end, the human brain is pretty good at filtering out the sound of your own voice, and actually expects to hear it. However, now imagine that somebody is repeating exactly what you just said a second later. Sound irritating? It is! The point to take away here is that, if echo comes back quickly enough, you won't notice it - but if there's a bit of delay (the cut-off's pretty sharp - I think it's around 50ms?) you'll soon begin to notice it, and with significant delays - over 100ms or so - it makes conversations extremely difficult.

In general, then, you want a small amount of immediate echo. This feature is known as sidetone, and is discussed further in Echo and Sidetone. It's the reason that a telephone will generally feed some of the microphone signal back to the earphone, as discussed above.

However, what you don't want is any echo coming back after an appreciable period. Looking again at the diagram above, and sticking with our estimate of 50ms as being the maximum acceptable echo path, and assuming that the signal travels down the wires at the speed of light (near enough for our purposes), you'd need a distance between you and the thing causing the echo of:

50 ms * 3.10^8 m/s / 2 = 7500km ~= 4600 miles

(Note we divide by two as it's the round-trip time, not the one-way time, which we're interested in.)

In short, you're unlikely to notice any problems with echo in a national call without any funky VoIP behaviour. However, factor in a satellite link (RTT of about 540ms), or a call to the other side of the world, and very real problems are possible. Furthermore - and here's where things finally get interesting for these pages - VoIP systems invariably introduce tens of milliseconds of latency into the traffic they are carrying, and the more network hops, or the greater the network congestion, the greater the latency.

To summarise this point:

• Latency must be present in the system for echo to be noticeable
• Echo is heard at the opposite end of the latency to where it is introduced.

The role of VoIP in echo problems

Suppose that we replace the caller's telephone with a funky new VoIP system, thus:

VoIP traffic
 >)-<- D-to-A =======<====== A-to-D --<-+                              4-wire trunk                                     +>-(<
                                       |                       -------------->--------------                       |
                                       |   2-wire local loop   |                               |   2-wire local loop   |
                                      Hybrid <---------------> Hybrid                         Hybrid <---------------> Hybrid
                                       |                       |                               |                       |
                                       |                       --------------<--------------                       |
 o)->- A-to-D =======>====== D-to-A -->+                                                                               +<--(o

^^^^^^^^^^                ^^^^^^^^^^
  VoIP phone                 PSTN-VoIP gateway

As we know, an unbalanced hybrid will cause part of the signal coming in on the 4-wire side to be sent back on the return path of the 4-wire side. So look what happens if the Hybrid in the PSTN-VoIP gateway is imbalanced: The caller's voice now travels out over a VoIP link, is reflected back by the hybrid, and passes back over the VoIP link, before arriving at the caller's ear. It's now more than likely that this will be perceived as echo.

Of course, not all PSTN-VoIP gateways have a two-wire interface to the PSTN. The TDM400P and its associated modules have a 2-wire interface; the TE4xxP cards use a digital link and therefore have a 4-wire interface (eliminating two of the hybrids in the above diagram). However, anybody who says echo isn't possible with a 4-wire interface to the PSTN (and plenty do) is talking nonsense. We've already established that echo can easily originate at the far end of the call, and this situation is no different - you've only eliminated one potential source of echo.

Solutions to the echo problem

There are essentially three ways of dealing with echo problems.

Elimination at source

Basically, this means trying to ensure that all of the hybrids are balanced. For hybrids on your side of the network, this is something you can work on, and Asterisk Echo Cancellation: FXO and FXS lines includes a few notes on doing this, which you should certainly look at if your Asterisk has a two-wire interface. However, a hybrid can never be perfect, and there will almost always still be some echo left in the network.

Echo suppression

An echo supressor is a simple voice-activated switch which turns off transmission from talker to listener whenever the talker is silent. This, however, is not as wonderful a solution as it might seem, both because it copes poorly with the situation when both ends speak at the same time, and because the choppiness and clipping of speech which can result from the switching action can be almost as distracting as the original echo. This, however, was the solution generally used in early intercontinental telephone systems.

Echo cancellation

Echo cancellation uses a mathematical approach to subtract exactly the right portion of the transmitted signal from the return signal to eliminate the echo. This is discussed at Echo cancellation in Asterisk.

NGS switches

I'll also mention in passing that it seems telco's are beginning to introduce switching technology based on packet-switched, rather than circuit-switched, protocols - typically ATM. Such switches will introduce a certain amount of latency themselves, and therefore implement echo cancellation. The point is that, because calls may or may not be routed over such switches, this can make echo problems intermittent, and therefore even harder to track down.

http://www.aussievoip.com/wiki/index.php?page=EchoInfo

http://www.rowetel.com/ucasterisk/oslec.html

Introduction

Oslec is an open source high performance line echo canceller. When used with Asterisk it works well on lines where the built-in Zaptel echo canceller fails. No tweaks like rxgain/txgain or fxotrain are required. Oslec is supplied as GPL licensed C source code and is free as in speech.

Oslec partially complies with the G168 standard and runs in real time on x86 and Blackfin platforms. Patches exist to allow any Zaptel compatible hardware to use Oslec. It has been successfully tested on analog and PRI x86 hardware (e.g. TDM400, X100P, Sangoma A104 etc) and on the IP04 embedded Asterisk platform.

There is also a project underway to use OSLEC with mISDN.

Oslec is included in many distributions, including Debian, Gentoo, Trixbox, Elastix, and Callweaver.

http://peter.schlaile.de/mISDN/

mISDN patches
Hi!

Here you'll find patches for mISDN that I produced on my way to a working (read: echo free) solution for our telephony system.

http://www.trixbox.org/forums/vendor-moderated-forums/aastra-endpoints/acoustic-echo

...

Thu, 06/14/2007 - 6:10am

I'm assuming you hear the echo on the 9133i and not at the other end of the call...

An echo delay of 250ms would suggest that the echo is being generated by the far-end device ( 250/2 = 125 which is an average end-to-end transmission time in an IP call). However, that doesn't tie-in with the delay increasing over the length of the call - actually about the only thing I can think of that would cause this would be a an echo canceler gone awry.

Since you hear the echo on both trunk (analogue? PRI? SIP?) calls and local end-point to end-point, the only common factors are the trixbox server and the 9112i. I suggest making a VOIP call, but cutting Trixbox out of the loop. There are two ways of doing this - the first is by setting "canreinvite" to "yes" in the extension setup for both endpoints in FreePBX, this makes trixbox (Asterisk) drop out of the voice path once the call is initially setup. The second way is to dial by IP from the 9112i, directly to the other device. Simply take the IP address of the other device and dial it, replacing the dots with stars - eg 10*50*112*20 will make the phone setup a call directly to the SIP device at 10.50.112.20

Doing this test will help you determine if the echo is being generated by the 9112i or your trixbox server. Although there is another way to check this using a packet sniffer. What you need to do is capture the SIP and RTP packets that are sent between your devices for a call that experiences echo. One of the best tools for doing this is Wireshark. Once you have the capture, you can actually play back the voice paths in both directions using wireshark - this will allow you to tell if the echo is already in the RTP packets that are being sent to the phone.

http://www.wireshark.org/

Wireshark is the world's foremost network protocol analyzer, and is the de facto (and often de jure) standard across many industries and educational institutions.

Wireshark development thrives thanks to the contributions of networking experts across the globe. It is the continuation of a project that started in 1998.
Features

Wireshark has a rich feature set which includes the following:

• Deep inspection of hundreds of protocols, with more being added all the time
• Live capture and offline analysis
• Standard three-pane packet browser
• Multi-platform: Runs on Windows, Linux, OS X, Solaris, FreeBSD, NetBSD, and many others
• Captured network data can be browsed via a GUI, or via the TTY-mode TShark utility
• The most powerful display filters in the industry
• Rich VoIP analysis
• Read/write many different capture file formats: tcpdump (libpcap), Catapult DCT2000, Cisco Secure IDS iplog, Microsoft Network Monitor, Network General Sniffer® (compressed and uncompressed), Sniffer® Pro, and NetXray®, Network Instruments Observer, Novell LANalyzer, RADCOM WAN/LAN Analyzer, Shomiti/Finisar Surveyor, Tektronix K12xx, Visual Networks Visual UpTime, WildPackets EtherPeek/TokenPeek/AiroPeek, and many others
• Capture files compressed with gzip can be decompressed on the fly
• Live data can be read from Ethernet, IEEE 802.11, PPP/HDLC, ATM, Bluetooth, USB, Token Ring, Frame Relay, FDDI, and others (depending on your platfrom)
• Decryption support for many protocols, including IPsec, ISAKMP, Kerberos, SNMPv3, SSL/TLS, WEP, and WPA/WPA2
• Coloring rules can be applied to the packet list for quick, intuitive analysis
• Output can be exported to XML, PostScript®, CSV, or plain text

root@ifold:~# aptitude search wireshark

p   wireshark                       - network traffic analyzer