|
Quick prototyping of wireless VoIP
|
|
By
Onno Kortmann
|
|
Audio DesignLine
(10/17/2005 6:43 AM EDT)
|
|
Developing prototypes of communications products can be an expensive and time-consuming process. A little ingenuity and repurposing of existing products can often provide a fast, low cost means of establishing a new product’s viability. It takes willingness to experiment with existing products and a realization that the results may not be “production quality” but will likely permit demonstration of concepts.
As part of a personal research project, I had a goal to build a wireless handset-to-VoIP PBX system. Commercial business telephone systems exist, but are cost prohibitive for low cost technology evaluation. The resulting wireless VoIP PBX is also a very functional system for personal use.
Voice over Internet Protocol (VoIP) is 'in' and as a service it is very often ridiculously cheap. Unfortunately the low service cost is not yet matched by low cost equipment for wireless handsets. To permit low cost experimentation our system is designed around a personal computer and modified DECT or other analog telephones.
Most PCs include audio capabilities of a fairly significant nature when compared to telephony bandwidths. Modern sound cards are equipped with everything needed to connect to a telephone in principle, i.e. simultaneeous high-quality analog input and output. But there are some problems: the voltage levels of a typical sound card in respect to the telephone system are incorrect and a phone needs a DC voltage to operate and go off-hook. Also, there is no proper software support for a phone that is connected to a sound card. For PC-based phone systems one still needs to dial via the PC's keyboard and not the phone's keypad, there is no 'hangup' or 'off hook' state for the phone (i.e. no dialtone), and the PC needs another channel (visual message on screen or another sound card) to indicate a ringing phone. All-in-all the PC phone lacks the operational characteristics of standard phones. This makes using the standard PC phone unsuitable for user interaction studies using VoIP.
To realize a prototype wireless VoIP systems we chose the open source PBX software asterisk. Several modifications must be made to get a DECT phone connected to the PC's sound card complete with dialtone, DTMF detection (i.e. touch tone dialing) and ringing the phone. The on/off hook state of the phone will be detected by the modified asterisk driver in order to complete the customary phone operation.
Asterisk itself also fully supports protocols such as SIP so that calls can connect to a SIP provider (web.de, sipgate etc...) through the PC. This can happen automatically and in the background so that it seems that the VoIP phone is just another phone connected to a regular phone provider.
Hardware 'hacking'
Hardware modifications to the wireless (DECT) phone changes are trivial.
First approach: transformers
The most straight-forward approach to interfacing the sound card with the telephone is a physical interface between the sound card and the phone without any modifications to the phone. Note that this approach is only possible with sound cards which possess a power amplifier onboard. The power amplifier is often visible as a separate DIP(-like) chip next to the slot cover and the sound cards main IC. An alternative is to use an external amplifier.
Figure 1. The obvious method of connecting a phone to a PC sound card has a few drawbacks.
For this approach to work, two important things have to be ensured. First, the sound card must generate a rather high voltage (10s of volts) to let the phone ring. Second, it has to generate a constant DC voltage so that the phone detects it is on line and this may be even needed just to get the microphone and/or speaker functioning. These two requirements can be met with this circuit:
With both transformers being small 230V (110V) <-> 6V...12V ones from the junk box, the capacitor being rather big (1000s of uF) as it acts as power supply filter here, and the diode can be any 1N4007.
The upper transformer T1 is driven by the left channel of the sound card and feeds the voice into the phone. Transformer T2's sole purpose is to generate a constant DC voltage at the capacitor on the secondary side. T2 is therefore continuously fed with a sine wave from the sound card, in the 50-60Hz range (whatever works best for the combination). The phone's output signal is picked up on the secondary side of T1 and fed into the sound card using the here optional coupling capacitor and resistor in the phone line. As all parts used here have a high enough internal resistance, it should work without the additional optional resistor. If you want the phone to be on floating potential in respect to the PC, which is generally a good idea, replace the ground connection between the secondaries and primaries with another capacitor.
With proper tweaking, the adapter worked somewhat, but a few problems popped up:
Echoing - It is probably impossible to separate generated and received signal with only passive components, at least a sophisticated active circuitry would be needed.
Imbalanced and sustained strain on the sound card's power amplifier - As the right channel is continuously providing power to the shown circuit, it has a much higher load than the left channel. And in regular use, this would be so as long as the PC runs (maybe 24x7). Components for the right channel output would age faster than for the left channel.
Unstable DC voltage - The phone more or less modulates the current on the line and this can stop the capacitor from providing for the wanted DC offset rather quickly. Replacing the diode with a full-wave bridge rectifier does not help much here.
The circuit only works with amplifier-equipped sound cards.
Direct modifications
Directly modifying the phone/DECT base station has various advantages. The most important is the nearly 100% removal of annoying echoes from the voice stream. Since the DECT phone I used had separate analog channels on the DECT controller for input and output, the echo problem shrank to the level of acoustic cross talk from the speaker to the microphone in the headset. With the proper settings the cross talk is barely audible even without using any further digital echo cancellation techniques.
Coupling at the right locations
Coupling the phone to the sound card should be done only using capacitors. Ignoring this advice may very well damage your PC, sound card and/or phone.
Speaker
Disconnect the phone from the line and power it only with the AC power supply (wall brick). To ring the phone the phone must be self-powered with a wall brick. Ring voltages may be dangerous.
Pick up the phone and listen for any, even very quiet changes in what you hear. Use your finger to probe around the phone's PCB, especially around the bigger ICs touching the pins of the ICs with your finger. If there is a slight buzz, you have found the right location. Now isolate to one single pin. There may be multiple such locations. Connect the output of the sound card to the phone by inserting a small capacitor into the phone circuit and attach the output from the sound card. Play music on the PC to verify correct connections; the music will play on your phone. The sound should be clear and undisturbed, though phone-like.
Microphone
For the signal path phone-to-sound card, take the sound card's input, add small capacitors, set the PC audio mixer setting in a way such that you can hear a buzz when touching the input. Probe the phone again to locate the audio output of the phone as for the speaker Ring tone detection circuit.
Hang the phone up. As the phone will ring using the telephone company’s frequency and voltage, it’s best to directly measure the ring voltage and frequency for your location. The frequency will be between 15 and 70 Hz. Generate a 15-70Hz signal and feed it into the phone via the jack. Add a DC offset with the same value as the peak to peak voltage of the ring AC. Do not connect the phone directly to the AC mains. Start with 0V. Increase the amplitude up to about 48V. At some voltage level, the phone should ring. If it does not, then your phone may require a different ring frequency or even waveform. If this is the case, then a different wireless phone will need to be used or the driver modified to produce the required waveform. To do this, the table with 32767 and -32768 in the driver needs to be changed.
Assuming that the phone rings at 50Hz, the most tedious part of the phone modification begins - the search for the low-level input into the DECT phone for the ring voltage. Use an oscilloscope to search for lower voltage AC signals on the phones PCB as the phone rings. The ring AC detection circuit probably resides in an IC. Once the right location has been identified, insert a small 50Hz AC level. If the location is correct the phone will ring. Note that the ring tone detection circuit may have a digital input so it’s important to properly limit the voltages using diodes to prevent damage to the chip.
Changes to the Asterisk OSS driver
For our research we selected the open source PBX package Asterisk. Asterisk is an 'open source full featured PBX' (private branch exchange). It can be programmed to switch hundreds of calls, handle SIP, other VoIP, and ordinary lines. Setup and configuration of Asterisk is beyond the scope of this article, but is addressed in the Asterisk documentation.
Several changes to the driver were necessary. The modifications detailed below should work for most circumstances. The patch to the driver is available online here. A precompiled shared object that should be able to be put into /usr/lib/asterisk/modules is available at chan_oss.so. The shared object should at least work during Debug/Testing. If it works, it should be sufficient to put this into the directory, start asterisk and do a "load chan_oss.so".
Important: For proper DTMF detection, set
OPTIONS += -DRADIO_RELAX
in the Makefile. By default, the asterisk OSS driver does not detect inband DTMF tones. DTMF detection is the driver's task and not a task supported by the core of asterisk. Only a few changed lines were needed for this. The necessary code is partially copied from the modem drivers (chan_modem.c and the like).
Stereo support
The driver's output format has been changed from mono to stereo to support the extra ring line. There are some checks to see whether a ring signal or another condition is played.
Ringing
With the hardware setup as described, generating the proper ring signal is straight-forward. As the driver already has a table with sounds to play to indicate various conditions, only a change of the ring tone to a 50Hz buzz was necessary.
Off hook/hangup detection
This was, by far, the hardest part in the driver. Since there is no separate signal coming into the PC that tells the driver whether the phone is off hook, the audio input signal itself needs to be checked for signs of a picked-up phone. The idea is: If the phone is hung up, no noise from the microphone and its amplifier enters the sound card. The sound card more or less only sees its own noise. In this state, the noise power level is very small. If the phone is picked up, the microphone and its amplifier is connected (either electronically or electromechanically through a relay) to the input line of the sound card. A lot more noise and background sounds will enter the sound card. The difference to the hung-up state is clearly distinguishable from the picked-up state. This enables off-hook detection without any additional components.
It should be noted that this approach may fail if one presses the 'mute' button on the phone as this may essentially do the same thing to the noise levels as a hang up. This only a minor flaw for the prototype system as that functionality is not critical to the evaluation.
>
Figure 2. Signal differential between the on-hook and off-hook states should be adequate for reliable operation of the prototype unit.
The red line should depict the phone in hung-up state with little noise and therefore a sharp peak around zero (or the sound card's ADC offset, this is often not identical to zero). The green curve depicts the noise in picked-up state which is broader due to the additional noise. By measuring the width (~ standard deviation of the peak), it is possible to determine the state of the phone. The noise going in the signal is gaussian as is expected.
To make this process more reliable, a few additional signal processing methods are implemented in the asterisk driver modifications. The first and important one is that the off-hook detection must be a lot more insensitive during phone rings. Otherwise when the phone rings, a lot of cross talk would trigger a pick-up indication, which is obviously not very practical for the phone user.
The second addition is detection hysteresis, meaning that a certain value is needed to trigger 'picked-up' state and a certain value explicitly below that is used to trigger the driver into 'hung-up' state.
Lastly, there is code that checks the number of times that the threshold must be crossed before the trigger gets really activated. This acts as a low pass filter to prevent mis-detections due to spikes and aliasing effects.
The detection of off-hook may not be reliable for a production solution. But, it is adequate for experimentation. The key in choosing the off-hook detection is speed of implementation. By minimizing the effort required to get the system operational more time can be spent evaluating final system capabilities.
Software setup
Configuration/module load
The compiled chan_oss.so module can simply be copied into the /usr/lib/asterisk/modules path. This is also possible with an already installed asterisk. Simply compile asterisk in the home directory (without "make install") and copy the file from channels/chan_oss.so
To load the module, put
load => chan_oss.so
in the modules.conf, as usual. Currently, the driver distinctly differs from the old chan_oss.so in that it does not support auto-answer shell commands. This is a simply way to verify that the correct driver is installed.
Mixer setup
Without the asterisk driver being enabled, and thus blocking the sound card, the 50Hz square wave can be played starting at low volume. The voltage at which the phone reliably starts to ring can be determined by gradually increasing the volume. The resulting volume is the output volume setting which is right for asterisk. Save this setting so it can be restored before the start of asterisk each time.
A neat tool do this is aumix. With the command
$ aumix -S
a file ~/.aumixrc is created (use the '-f' option to specify a different file name, see also 'aumix --help' as usual...) which contains all mixer settings. These settings have to be restored later on with
$ aumix -L
Write this into /etc/init.d/asterisk startup script, for example.
Setting the thresholds and timeouts and volume prescaler
All the following settings have to be made in the file /etc/asterisk/oss.conf. The specified configuration variables here all need integer arguments and have to be set in the [general] section of the configuration file.
After checking that the driver at least loads, the next thing to do is to enable asterisk to output the current 'standard deviation' value of the amplitude histogram detection function to the console. This is done by setting hd_disp_interval to a value different to the default of "-1" (no output), for example hd_disp_interval=30.
It is advisable to call asterisk with the command line arguments
$ asterisk -f -c -d
which results in obtaining a shell where things can be tried out. After enabling the stddev display, some numbers should appear onscreen which should change with a) hanging/picking up the phone and b) speaking into the phone.
Note the differences between hung-up and off-hook. Write down the values. Now, set hd_hl_threshold, the pick-up threshold level, to a value just below the observed values when the phone is off-hook but no one is talking. Similarly, set hd_ll_threshold to a value just above the value that appears when the phone is hung up. The variable hd_hl_ring_threshold is like hd_hl_threshold but used when the phone is ringing, i.e. there is cross talk on the input. Set this a bit higher than hd_hl_threshold.
After restarting asterisk, there should be messages that the phone has been picked up or hung up. If this does not work reliably, increase the values for hd_hl_seqmin and/or hd_ll_seqmin respectively. The detection will be a bit delayed to the actual action; this will increase with the values for *_seqmin.
If this works ok, try to use asterisk's example dialplan (that with the demo application and long introduction speech). DTMF detection should work. If it does not, check the value of "-DRADIO_RELAX" in asterisk's Makefile.
Test the complete signal path by dialing the echo application (600). There should be at most slight echoes. If there is too much echoing which can't be reduced by the sound card's mixer settings, use the configuration variable vol_divide to scale down the input signal received by the driver before it is given to the other parts of asterisk. The default variable for this is 3, which works well in my case. Note that I built a potentiometer into the phone to attenuate signals, but this is a relict of investigation. In all but the most extreme cases, this should be unnecessary with vol_divide or, perhaps further modification of the driver for throttled output.
Dialplan issues
Having a working phone is good, but the standard configuration of asterisk may not be what one wishes for simulating regular telephone operation. As a clear indication, there should be a dialtone which should be switched off after the first digit dialed. Other modifications may be desired to the drivers busy and congestion signals.
Asterisk has the dialplan for this. See the details in the appropriate documentation. Configuration of the dialplan (in extensions.conf) is easy and straightforward.
Playtone is a useful asterisk application for generating the dialtone, which has to be called with Playtones(dial). Contrary to what is stated in the documentation of the Playtones application, it has to be called as Playtones, not Playtone.
A simple extension map (+ all necessary includes etc. not shown here) that works could be similar to this:
[default]
;
; Default context
;
exten => s,1,Playtones(dial) ; start with dialtone
exten => 0,1,StopPlaytones ; dialing '0' stops dialtone and
exten => 0,2,Goto(dialing1,s,1) ; goes to the 'dialout' context
exten => 1,1,StopPlaytones ; '1' is a speed call
exten => 1,2,Dial(SIP/girlfriend,,rg)
exten => 1,3,Goto(prehangup,s,1) ; special handling after hangup
exten => 2,1,StopPlaytones ; and so is '2'
exten => 2,2,Dial(SIP/parents,,rg)
exten => 2,3,Goto(prehangup,s,1)
exten => 9,1,StopPlaytones ; '9' calls the echo application
exten => 9,2,Playback(demo-echotest) ; Let them know what's going on
exten => 9,3,Echo ; Do the echo test
exten => 9,4,Playback(demo-echodone) ; Let them know it's over
exten => 9,5,Goto(prehangup,s,1)
exten => i,1,Goto(prehangup,s,1) ; busy and wait for hangup - nothing more
exten => t,1,Goto(prehangup,s,1)
[dialing1]
;
; context while dialing out
;
exten => s,1,DigitTimeout,2 ; really dial 2 sec after the last digit
exten => s,2,ResponseTimeout,10
exten => t,1,Playtones(busy) ; If nothing happens
exten => _X.,1,Dial(SIP/${EXTEN}@myprovider,60,rg) ; dial
exten => i,1,Playtones(busy) ; happens for single digits
[fromsip]
; ; context reached from outside ;
exten => _X,1,Dial(Console/dsp,30,rg) ; simply dial the console (i.e. the phone!)
[prehangup]
;
; context after a call/action
;
exten => s,1,StopPlaytones
exten => s,2,Playtones(busy) ; hang up your phone
exten => s,3,Wait,36000 ; wait 10h and then maybe give the driver's busy signal
exten => i,1,Goto(prehangup,s,1) ; invalid number
exten => t,1,Goto(prehangup,s,1) ; timeout
Important things
Do not choose the very cheapest sound card brand, or better, check if the sound card
is full duplex, using simplex cards is not worth the effort. Repeated switching between input and output operation would be necessary. This is supported by asterisk's original OSS driver.
has a working linux driver. Working means that its full duplex mode is also working and that it does not lock up or cause unnerving noises etc. when operated for a while.
Stay away from the RF/high frequency/radio parts of the DECT base station. Changes there may affect RF signal quality, detune the DECT to non-allowed frequencies, decrease range, etc.
Simple modifications to inexpensive and readily available wireless digital telephones combined with open source software enabled a very quick-to-implement experimental platform for wireless VoIP telephony. The resulting platform permits investigation of a wide variety of phone interactions including VoIP in combination with standard analog telephone line calls. Similar modifications to off-the-shelf consumer products can be used to rapidly develop test systems for new concepts.
About the author
Onno Kortmann is a fifth year Master's degree candidate studying physics at the Christian-Albrechts-Universität zu Kiel. His thesis is concerned with scintillator material studies for particle physics
experiments. He also holds a ham radio license (DH1LOK). He can be reached at onno@gmx.net.
|
|
|
|
CAREER CENTER
|
Ready to take that job and shove it?
|
|
SPONSOR
|
|
|
|
RECENT JOB POSTINGS
|
|
|
For more great jobs, career related news, features and services, please visit EETimes' Career Center. |
|
