I have an application where I have about 10,000 pieces of monitoring equipment across the US that periodically dials into a bank of 32 phone lines. I have two receivers of 16 lines each that answer the call and temporarily stores a small alpha string. I then have a computer that polls the receivers and parses the string and copies it to a database.
I am looking to replace the phone lines and the receivers with a voip solution and rewrite the software to parse the data string.
Any ideas on where to get started?
Tom's suggestion about Asterisk is a good one for the overall system.
However you will still need to decode the data sent from your remote equipment from an audio signal to a data signal. That task is what the "dem" part of Modem stands for (Modulate/Demodulate). Either you do this with a canned hardware/software package (as you are currently doing with a commercial modem) or you have to emulate the modem in software yourself which will be extremely tricky to code at the very least if you attempt it yourself (heaps of standards that you have to comply with for a general modem solution, plus the solution needs to work in real time)
For the software approach could start with this page Linmodems.org (just a something I saw on google prompted by your question). Alternatively do lots of searches on google for software modems. Getting someone else's code is the best approach for this sort of code :)
Whatever you end up doing I suspect it will be rather custom.
A good place to start is probably Asterisk PBX.
I take it you don't want to replace the modems at the client sites (the easiest thing on the server side would be each clients had its own IP software stack, and used its modem to call an ISP and establish an internet connection, and then talk to your server using TCP or UDP or HTTP or whatever).
Assuming that you don't have IP capability on the client sites, Googling suggests that the relevent technology is called "Modem over IP" or "MoIP" (which Wikipedia seems to be confusing with "Mobile over IP").
VoIP consists of SIP for signalling (e.g. for call set-up and call tear-down) plus some codecs (e.g. H.323) for traffic (encoded voice) while the call is established.
I'm guessing that MoIP can keep the SIP signalling, but needs to use some different codecs.
V.150 Modem over IP White Paper looks like an introduction to the technologies. I don't know what vendors there are.
I presume you are looking to find a way to do this without mofidying the modem hardware at your remote sites. If this is the case you will have to find or write signal processing software to demodulate the encoded signal from the modem. Fortunately, signal encodings on a modem are designed to be easy to do this with.
Maybe somebody makes software modem libaries that do this sort of thing. The other parts of the problem will be emulating the handshaking on the modem so it plays nicely with the remote sites.
If you can modify the software (really just the number to dial, but it would have to include the data you want to transfer) at the 10000 sites (not likely!), you could in theory use DTMF in the "dial" string to key the data over into Asterisk. Ok, more than a bit hackey, but it would avoid having to have a software modem. Note: you'd want a checksum!! (and maybe send it multiple times) And a way to tell the caller if it was received correctly. Like I said, hackey but cute.
Related
I was always wonder what would it be my first question on StackOverflow since everything I'm looking for is already asked. (Find only one similar here Bluetooth data transfer between two countries )
BACKGROUND STORY:
From when it comes I’m a fan of Nokia N-GAGE. It’s a Nokia’s phone from 2003 with dedicated games. In its heyday 2003-2007, it has single-player, multi-player via Bluetooth and using a dedicated internet service N-GAGE ARENA for compete with people all over world.
N-GAGE ARENA servers were disabled about 2008 and as far i understand It isn't even worth trying to resurrect such a infrastructure. Mainly because it requires modifying the code of each game and that's illegal.
Multiplayer mode using Bluetooth work fine, but requires opponent 5m away max.
Nokia sold 1mln copy of this phone, and still are people all over world collecting n-gage games. I have a dream, I want to reactivate the possibility of playing multiplayer with people from all over the world.
PROBLEM DESCRIPTION:
I want to use the Bluetooth multiplayer mode by extending the usual N-GAGE to N-GAGE Bluetooth connection with an additional 3 elements. Two N-GAGEs, instead of connecting directly to each other as host-join, connect via a PC / smartphone applications that communicates with the server that transmits full data sent from the game of one user to game of the opponent.
I admit that I do not have full knowledge of technical limitations. In my opinion, as a software engineer, it is theoretically possible, but I want to consult you, people more familiar with the subject. Maybe someone is working on a similar project and can comment.
WHAT DO I KNOW:
The application would have to transmit all data from the Bluetooth connection so as not to disturb the illusion of a direct connection between N-GAGEs.
The application must enable the selection of an opponent on the basis of the game. The choice itself could be made on the basis of some kind of chat in which users first define what they are playing, who’s the host, and then the connection is made.
WHAT DO I WANT TO KNOW:
Does what I describe is even possible?
Is such capturing Bluetooth connection and forwarding is even possible?
Does the development of technology in these 15 years allow me to transfer Bluetooth connection real time through 2 additional devices and Internet connection?
I WOULD BE GREATFUL FOR:
Any technical tips, literature that can help me to understand my limitations.
Any constructive criticism. Of course before I start doing such a project I have to confirm that isn't a utopia. For me It’s a side project, I’m able to spend years on it, but don’t want to get to dead end after all effort.
Does what I describe is even possible?
Yes, yes it does. Your hardest part will be setting up a tranceiver to interpret the I/O. Your failure point would be super-encrypted messages and making transmission difficult...
If it's clear I/O you can signal this through any server and output it back to the tranciever to output. Confusing but possible just not sure of the design or how bluetooth sends its data.
Is such capturing Bluetooth connection and forwarding is even possible?
If a connection is possible then forwarding it is too. Considering this piping the transports.
Does the development of technology in these 15 years allow me to transfer Bluetooth connection real time through 2 additional devices and Internet connection?
Bluetooth real-time no... with added network latency, you're looking at anything from 1-200ms~. you may be able to improve it?
Overall I think if you can:
Connect the device to PC, and have PC talk back to device through blue-tooth
Read the data that goes in and out
Encryption proves little or none at all to be able to signal the data properly, tricky to explain you'll know though if there's a wall.
All should be possible it doesn't overly go against the grains but do more homework this is very valid.
So I'm kinda stuck here.
I have a radio station, but we are mobile. So I have a studio on wheels. The problem is, we have an antenna, but we always have to place that really close to our studio. Now I want to make an device that can stream the audio from the audio mixer to the internet and can be received by another device in another network and send that signal to the antenna (audio output).
to make this clear, I made a schema with raspberry pi's;
I want this to be plug and play So I only have to plug in the device in the modem (or network we have) on both sides and the devices should find each other.
I don't know HOW I can do this, so I need to know a couple of things:
What hardware should I use?
What software should I use?
What is the best configuration to accomplish this?
Can I use 2 raspberry pi's?
How can I let the devices find each other over the internet?
There need to be some features;
The system needs to be able to buffer the audio for 5-10 seconds
It needs to be direct, so it's live and not a file that needs to be played
The system must be failless (beside the fact the internet can die).
Plug and play is a must, I don't want to have a really messy configuration to do. (if possible, without any kind of portforwarding).
I would really appreciate help and a decent explaination.
regards,
Robin
Well, it depends on your capabilities as a programmer.
If you're really fixated on the RPi for it's convenient form factor, there's a ton of community support, so I'd start with something like this project to kick start you in the right direction. If you already know python pretty well, modify away and have fun.
If you have no programming experience, you'll probably want to put a desktop in place of the RPi and launch some instances of VLC. It's not necessarily plug n play, but you can get close enough by getting a command line VLC to launch at startup.
Either way, the more difficult problem here is the "over the internet" part. This would really need to be a server-client model, but who is your server depends on who is more stationary (I'm guessing Location 2?) because the client will need to know the IP address of the server somehow. There are dozens of ways to make this happen, but at the end of the day, you'll want to use sockets accomplish the
It needs to be direct, so it's live and not a file
... which unfortunately gets complicated. See this answer for confirmation. Would love to help with some tips on implementation, but we need more information about your willingness to "dig into the code", the necessity of the RPi, and whether the stationary location has a static web address.
While working on voip apps, I usually end up picking up one phone, talking to it, picking up the other phone and check if I hear myself. This even gets trickier if I'm doing apps with three way calling.
Using a softphone doesn't help.
Ideally, I want to be able to run multiple instances of some command line based sip ua wherein i can dial a number. Once the ua has dialed and the other party ha picked up, both agents exchange audio. But instead of having to hear some audio, the apps instead display some text which identifies the other end. Possibly some frequency pattern that can be converted to text. Then this text is displayed on the app.
Can something like this be done? I'm creating apps against freeswitch. Ideas how to debug voip apps are also welcome in the comments.
yes, absolutely. The easiest would be to have a separate FreeSWITCH server that is used for placing the test calls and sending/receiving your test signals.
tone_stream will generate the tones at frequencies that you need: https://freeswitch.org/confluence/display/FREESWITCH/Tone_stream
tone_detect can detect the frequencies and execute actions, or even better, generate events that you can catch over an ESL socket: https://freeswitch.org/confluence/display/FREESWITCH/mod_dptools%3A+tone_detect
The best way to generate such calls is to use a dialer script which communicates to FreeSWITCH via Event Socket. Here you can see some (working) examples that I made with Perl:
https://github.com/voxserv/rring/blob/master/lib/Rring/Caller/FreeSWITCH.pm -- this is a part of a test suite tat I build for testing a provider's SIP infrastructure. As you can see, it connects to FreeSWITCH, starts event listener, and then originates the call and also expects an inbound call. It then sends and analyzes DTMF.
https://github.com/voxserv/freeswitch-helper-scripts/tree/master/esl -- these are special-purpose dialers, you can also use them as examples.
https://github.com/voxserv/freeswitch-perf-dialer -- this one generates a series of calls, like SIPp does.
Another technique is to play a sample audio file and record the audio being received on the other end[call recording] and then comparing the two. This system works on setup where systems are located at various places and you are testing end to end quality.
There are lot of Audio Comparison tools [like PESQ] should help you not just detect the presence of Audio but also give stats about the degradation of various parameters in the audio stream.
This can be extended to do test analysis of FS patches as and when they are released and also for other hooks or quality standards you want to enforce.
I need a SIP server, hopefully simpler, more efficient and more secure than Asterisk or other full-featured PBX, to just terminate SIP calls and play audio, based on the incoming number. This would be in a linux environment.
I'm concerned about long-term support, and much-reduced attack surface. I'm a programmer but a no0b in the SIP world. I want to avoid the tons of security hassles of a full-featured PBX, let alone the crazy big bills after a hacker gets into it. Thanks in advance!
Personally I would build one with pjsip. Assuming you do not need built in registration server all calls would be handled by so called local account. You can use command-line pjsua with auto-answer and auto-play options for initial tests and then add some logic for audio wave selection and perhaps audio player allocation/deallocation (audio players could be active all the time and shared by multiple calls for efficiency if they e.g. contain something like background music).
For security disable not needed parts (TCP, TLS transports, not needed codecs?) and use port other than 5060. In my application I'm also using kind of application-level firewall that blocks requests from hosts that generate suspicious traffic (registrations, malformed SIP requests).
I read an interesting article about coding for the AR Drone 2.0 from Parrot. In this code they us nodeJS to talk to the drone. Therefore the code starts out with creating a Stream to /dev/ttyO0
I am starting out to learn more about the background of linux functionalities and would like to know:
How do you initially find out that the dev/ttyO0 is being used, for example on the drone which runs on linux. It is kind of reverse engineering I think, but what tools or commands are being used therefore?
When I want to reverse engineer a system like the drone, and find out which commands are being sent, is there something like a "sniffer" to find out what commands are being sent?
I know this is not a short and easy answer, but I would be happy to learn more about that or find out, where to learn about that. But initially the question about finding the right device would be very interesting.
Thank you
I don't know the answer to the first part of your question, but I can address the second part.
Yes, the AR.Drone uses TCP and UDP for all communications between the drone and the controller app, including commands, telemetry and video. You can use a standard network sniffer, like tcpdump or Wireshark. When you connect to the drone, its default IP address is 192.168.1.1. Configure the sniffer to capture all traffic to and from that address. Here are some highlights of what you can see:
Command/"AT" comms, UDP on port 5556: This port is used to send commands to the drone. Commands are in ASCII, and look like AT*..., for example AT*REF=7,256 or AT*PCMD=7,1,-1110651699,0,0,1050253722. Section 6 of the AR.Drone Developer Guide describes most (but not all) of the commands.
Navdata, UDP on port 5554: This is binary encoded data sent from the drone containing sensor data and information about the state of the drone. It includes things like air pressure, altitude estimate, position estimate, flying mode, and GPS (if your drone is equipped with one). Since you mentioned Javascript, the file parseNavdata.js in the node-ar-drone library contains code to parse navdata.
Video, TCP on port 5555: This is realtime video from the drone in an almost-but-not-quite H264 format known as PaVE. The format is documented in section 7.3 of the Developer Guide, and most libraries for talking to AR.Drones can parse the format.
Another thing you may notice:
FTP: The official controller app uses standard FTP to send an ephemeris file to the drone that contains info that helps GPS get a faster lock.