We have "Interactive Voice Response (IVR)" set-up using asterisk PBX that interacts with callers, gathers information and routes calls to the appropriate recipient.
We have used Playback function in asterisk to play the IVR but the issue is that when we play the audio file, the volume is very low i.e it is not audible.
We have used the on-line tool "http://www.text2speech.org/" which help us to increase the intensity of the volume but asterisk needs a file with only "8 K Hz" sampling rate which decrease the volume intensity and again it is not audible.
Is there any tool specific for "8000 K Hz" audio file generation with high intensity volume that it should be visible clearly audible. Please help us in any other technique.
Thanks in advance.
Use SoX It's one of the best tool for sound along with ffmpeg.
I don't know your platform but here is a windows command:
sox.exe "input" -r 8000 -c 1 -t ul -w "output"
Asterisk works better with ulaw files, the command above will give you a frequency of 8000kHz.
There is 2 options
1) Change file to be louder. You can use sox or audacity(free editor for windows)
2) Change in dialplan volume using VOLUME function
Related
I have:
USB Sound which is alsa "Device" or "hw:1,0"
Asterisk console configured to use "plughw:1,0"
This works, letting me use the USB Sound for making and receiving voice calls via Asterisk.
I also want to use multimon to decode DTMF tones during the call. If I stop Asterisk I can run "aoss multimon -T DTMF" to decode the tones successfully but in order to do so I had to create an /etc/asoundrc file like so:
pcm.dsp0 { type plug slave.pcm "hw:1,0" }
Starting Asterisk, which grabs the "plughw:1,0" means I get an error trying to run multimon. I believe this is because only one app can access an alsa device at any one time.
I think I need to split the hw:1,0 into two new alsa devices, which I have been trying to do using alsa plugins (dmix/multi) but I'm afraid I can't get my head around how to get these configured!
p.s. I want to use multimon as I also have other use cases for using it on the same setup to decode other tones than just DTMF.
As #CL have pointed, you could use dsnoop for analysing the audio trhough multimon. The following extract has been taken from Basic Virtual PCM Devices for Playback/Capture, ALSA | nairobi-embedded
The dmix[:$CARD...] and dsnoop[:$CARD...] Virtual PCM Devices
A limitation with the hw[:$CARD...] and plughw[$CARD...] virtual PCM devices (on systems with no hardware mixing) is that only one application at a time can access an audio stream. The dmix[:$CARD...] (playback) and dsnoop[:$CARD...] (capture) virtual PCM devices allow mixing or sharing, respectively, of a single stream among several applications without the intervention of a sound server, i.e. these devices use native ALSA library based mechanisms.
I'm wondering if anyone has any experience recording an ARI bridge to separate files, unmixed (or at least to separate L and R channels of a stereo file). It seems this can be achieved by recording separate Channels but then these channels are not able to be bridged.
Recording two bridged channels always results in a mixed audio file.
I'd appreciate it if anyone could point me in the direction of successfully recording the In and Out channels of a bridge discretely, similar to the Monitor dial plan application. Or even bridging two channels that are already being independently recorded.
Are there any workaround for this that I'm not seeing?
I know I can get there without ARI but I'd love to use ARI. It can do everything I'd need it to do but this.
Thanks!
Application Monitor not mix channel.
Application MixMonitor do mix, but create stereo.
You can transfer you call to dialplan which do Mix/Monitor after that bridge it back via ARI.
From my understanding, what you have to do is create a seperate spy channel attached to each participant in the bridge. Then you can record the spy channel. And you can set the Spy to only monitor the direction you want. Then you would need to manually mix the calls down yourself afterwards.
Waking up an old post.
If you want to have ‘stereo’ recordings, i.e. channel A on the left and channel B on the right...
All you need to do is Record channel A and B separately and combine them after a call using a tool like SoX
Normal dialplan MixMonitor is the equivalent of recording a bridge with ARI
Normal dialplan Monitor is the equivalent of recording channel with ARI.
As someone who is very new to the opensource PBX projects like Asterisk and FreeSWITCH, I am grappling with some information overload. Have read the basic FreeSWITCH docs on Wiki, but still have few questions. Since I am not very familiar with the terminology, I will try to use close approximations.
Trying to create a small/minimalistic build of FreeSWITCH, that needs to run on an rather old laptop (Celeron 1GHz, 512MB RAM, 20GB HDD, already running Debian "Wheezy"), and set it up as a 6-port GSM-SIP/Jabber gateway. So, by "small" and "minimalistic", I mean one which doesn't have modules/optional-software that is not absolutely necessary (e.g. no need for IVR announcements, or Skype integration) -- to keep memory footprint smallest, and occupy less hard-disk real-estate.
The rough idea is to have 6 GSM ports (via 'GSM-open module', similar to chan_dongle) towards public telephony network, and about 60 SIP extension, and support upto 6 calls involving GSM ports, and about 6 SIP-SIP calls (intra PBX), on this setup. I have read that the CPU overhead of GSMopen module is pretty low, so I am guessing this is possible.
Can someone confirm this to be a realistic goal?
What might be the minimum set of modules to select for minimalistic build?
For modules not chosen during initial build, can those be added later? If so, would it require me to rebuild FreeSWITCH completely, only the modules, or that everything would be built, but only configuration changes would be required to ensure that modules are loaded, and configure?
Is there any rough estimate of what might be the maximum call-rate that could be supported in such a configuration? For SIP-SIP calls? Given the underpowered processor, and little RAM (as per modern standards), I am guessing that both shall be bottlenecks, but adding RAM might still be possible (even if costly and difficult).
I have read that "hooks" can be created using Lua/Python/Java etc.. However if someone share share few examples of what-all is possible using such hooks, it would make the concept clearer. Can one hope to write an application like "missed call log" or "redirect on no answer" using these hooks?
Can someone confirm this to be a realistic goal?
Yes, this is quite realistic. You need to target as little as possible transcoding, because that's where CPU resources are needed. But even with a 1Ghz Celeron, 6 transcoded sessions seem quite realistic. But it needs testing :)
What might be the minimum set of modules to select for minimalistic build?
Just start with the default list of modules, and add gsmopen (I have no experience with gsm gateways, can't help with that part). The memory footprint is pretty low, and you may need some of those modules later.
For modules not chosen during initial build, can those be added later?
as far as I remember, Wiki describes this process. You edit modules.conf and make the specific module.
Is there any rough estimate of what might be the maximum call-rate that could be supported in such a configuration? For SIP-SIP calls? Given the underpowered processor, and little RAM (as per modern standards), I am guessing that both shall be bottlenecks, but adding RAM might still be possible (even if costly and difficult).
It really depends on complexity of your dialplan. Each context consists of a number of conditions, which are doing regexp match on channel variables. So, the more complex your dialplan is, the less CPS you get. But for a 6-channel gateway, I don't see this a problem. GSM network will be much slower than your box :)
I have read that "hooks" can be created using Lua/Python/Java etc.. However if someone share share few examples of what-all is possible using such hooks, it would make the concept clearer. Can one hope to write an application like "missed call log" or "redirect on no answer" using these hooks?
You can control every aspect of FreeSWITCH behavior with FreeSWITCH. There are even examples when the complete dialplan is re-implemented by an external program (Kazoo does that).
The simplest mode of operation is when your Lua/JS/Perl/Python script is launched from within the dialplan: then it receives a "session" object, and you can do whatever you want with the call: play sounds, bridge, forward, make a new call and bridge them together, and so on. Here in my blog there's a little practical example.
Then, you can build an external application which connects to the FS socket and monitors the events and performs actions on active calls.
Also, it can be done in the opposite direction: you run a server, and FS connects to it with its socket library.
Also, you can have an HTTP service which delivers pieces of XML configuration to FreeSWITCH, and it requests those on every call (this would be the most CPU-intensive application). This way, you can feed FS from some internal database, and build fault-tolerant systems.
I hope this helps :)
You can also find me in skype if needed.
FreeSWITCH is not really memory-hungry, and you can simply start with the default set of modules (the best is to use the prebuilt Debian packages). For example, on my 64bit machine, the FreeSWIITH process occupies only 35MB of memory.
freeswitch#vx03:~$ uname -a
Linux vx03 2.6.32-5-xen-amd64 #1 SMP Thu Nov 3 05:42:31 UTC 2011 x86_64 GNU/Linux
freeswitch#vx03:~$ ps -p 11873 v
PID TTY STAT TIME MAJFL TRS DRS RSS %MEM COMMAND
11873 ? S<l 10:29 0 0 258136 36852 2.3 /opt/freeswitch/bin/freeswitch -nc -rp -nonat -u freeswitch -g freeswitch
I will go through the rest of your questions later today
Just any old GSM compatible SIM card (bonus for 3G USIM).
I presume I need some hardware? Can anyone recommend something cheap for hobbyist, and something more professional?
I presume that there will be full docs of an API with the h/w, so maybe this should be tagged "no-programming-related"? Sorry, if so.
Any good URLs or books (I am conversant with the 3GPP standards).
I'm not (black hat) hacking, don't worry, just not pleased with the likes of SIM Card Secretary, Data Doctor Recovery, etc, so would like to code my own, but might turn it commercial, or offer SIM card programming services (data recover from damaged card, etc) as a sideline.
Update: while I am primarily interested just reading my SMS for backup, it might be a bonus if someone knows of a cheap SIM card writer (so that I can back up all or part of the SIM and restore it later)
You can do that with any PC/SC smart card reader (and writer, as others pointed out) and a program that can read and parse the data for you.
Talking to a card is done via APDU commands (defined in ISO-7816)
The command set used by SIM (2G) and USIM (3G) cards is different, so you have to keep that in mind
The structure and format of the file system of a SIM card is defined in GSM 11.11 (for 2G) and ETSI TS 131.102 (for 3G) - all this documentation is public and available free of charge
The SMS are kept in a file called EF SMS, its name is 0x6F3C, its structure is defined in section 10.5.3 of GSM 11.11
Direct answers to your questions:
Here's where to buy a SIM reader, click on 'photos' to see pics of the device and screenshots of the software
SIM Manager is the program that does everything you want (including reading SMS, restoring SMS, it can even attempt to recover deleted SMS - if they're still physically on the card)
A SIM card SDK is available too. It is a DLL you can load and apply in your program. This thing does all the hard work for you, all you need is to create a GUI on top of it
I am one of the people from the team that created SIM Manager and the aforementioned SDK.
You'll certainly need a smartcard reader and from what I've been able to find out, pretty much any one will do because they all have to support the standard functionality. They also happen to be pretty cheap. Mine is an OmniKey (not sure what model because I don't have it here right now).
Presuming that you're developing under Windows, the Windows API has functions that make it possible to access smartcards. Here is an article on CodeProject that discussees this in greater detail as part of a set of several C# classes that give you access to a bunch of this stuff without having to tangle with the nuts and bolts. I think that the guy's example app is specifically for SIM cards, so that'll probably help.
There's lots of products and hardware to read and write SIM cards, have a look at http://forum.gsmhosting.com/vbb/f500/ in this forum you will find plenty of info concerning sim cards, mobile phones.. one of the bigest resource since 1999!
for hardware programmers, you can build your own like JDM or ICprog.. check kiscan.net for some info..
You can use simLAB tool for reading and editing almost any SIM file.
It works with every PC/SC smartcard reader. The tool also allows you to backup SIM file system.
Have a look at https://github.com/kamwar/simLAB
pySim
In the below example, we are changing the card’s IMSI to
901700000003080 (option -i) and we are specifying a new set of -n NAME
(Operator name), -t TYPE (Card type), -c CC (Country code), -x MCC
(Mobile Country Code), -y MNC (Mobile Network Code) and -s ID
(Integrated Circuit Card ID) values.
$ ./pySim-prog.py -p 0 -n OpenBSC -t sysmosim-gr1 -i 901700000003080 -c 001 -x 001 -y 02 -s 1791198229180000075
Is it enough just filling the new SIM card with new meta and will it working the same way as original? pyusb
Here is the full list of options:
$ ./pySim-prog.py -help
Usage: pySim-prog.py [options] Options:
-h, --help show this help message and exit
-d DEV, --device=DEV Serial Device for SIM access [default: /dev/ttyUSB0]
-b BAUD, --baud=BAUD Baudrate used for SIM access [default: 9600]
-p PCSC, --pcsc-device=PCSC
Which PC/SC reader number for SIM access
-t TYPE, --type=TYPE Card type (user -t list to view) [default: auto]
-a PIN_ADM, --pin-adm=PIN_ADM
ADM PIN used for provisioning (overwrites default)
-e, --erase Erase beforehand [default: False]
-S SOURCE, --source=SOURCE
Data Source[default: cmdline]
-n NAME, --name=NAME Operator name [default: Magic]
-c CC, --country=CC Country code [default: 1]
-x MCC, --mcc=MCC Mobile Country Code [default: 901]
-y MNC, --mnc=MNC Mobile Network Code [default: 55]
-m SMSC, --smsc=SMSC SMSP [default: '00 + country code + 5555']
-M SMSP, --smsp=SMSP Raw SMSP content in hex [default: auto from SMSC]
-s ID, --iccid=ID Integrated Circuit Card ID
-i IMSI, --imsi=IMSI International Mobile Subscriber Identity
-k KI, --ki=KI Ki (default is to randomize)
-o OPC, --opc=OPC OPC (default is to randomize)
--op=OP Set OP to derive OPC from OP and KI
--acc=ACC Set ACC bits (Access Control Code). not all card types are supported
-z STR, --secret=STR Secret used for ICCID/IMSI autogen
-j NUM, --num=NUM Card # used for ICCID/IMSI autogen
--batch Enable batch mode [default: False]
--batch-state=FILE Optional batch state file
--read-csv=FILE Read parameters from CSV file rather than command line
--write-csv=FILE Append generated parameters in CSV file
--write-hlr=FILE Append generated parameters to OpenBSC HLR sqlite3
--dry-run Perform a 'dry run', don't actually program the card
The source code is available.
Also the SIM card is just a smart card. You can use pyscard or pyusb to operate on it. I found this Q&A helpful.
I'm working currently on a small microhpone, connected to PC via an FPGA. The FPGA spits a raw datastream via UART/USB into my computer. I'm able to record, play and analyze the data.
But I can't play the "live" audiostream directly.
What works is saving the datastream in PCM raw-format with a custom made C-program, and piping the content of the file into aplay. But that adds a 10sec lag into the datastream... Not so nice for demoing or testing.
tail -f snd.raw | aplay -t raw -f S16_LE -r 9000
Does someone have another idea, how get the audiostream faster into my ears? Why does
cat /dev/ttyUSB0 | aplay
not work? (nothing happens)
Thanks so far
marvin
You need an api that lets you stream audiobuffers directly to the soundcard. I haven't done it on Linux, but I've used FMOD for this purpose. You might find another API in this question. SDL seems popular.
The general idea is that you set up a streaming buffer, then your c program stuffs the incoming bytes into an array. The size is chosen to balance lag with jitter in the incoming stream. When the array is full, you pass it to the API, and start filling another one while the first plays.
That would seem to be the domain of the alsaloop program. However, this program requires two ALSA devices to work with and you can see from its options that it goes to considerable effort in order to match the data flow of the devices, something that you would not necessarily want to do yourself.
This Stackoverflow topic talks about how to create a virtual userspace device available to ALSA: maybe that is a route worth pursuing.