I am a newbie so please be gentle with me. Before I delve into FreePBX to much, I would like to know if the following would be possible …
I have a friend who lives in the country and relies on Satellite delivered internet connectivity. Unfortunately along with this high speed delivery method comes a great deal of latency, making it impractical for SIP / VOIP connections.
I thought that the following may solve the issue if it is at all possible? …
Using a standard telephone line which is always dialled up (it would be a local untimed call) and some old 56k modems connected to Raspberry Pis at each end to handle and route the data – Would it be possible to somehow route a VOIP ATA over the 56k connection data link and into a remote FreePBX server.
I understand that modems are completely different to ATAs. The modems would purely be in place to provide the data link between the ATA and the remote FreePBX server.
Is a 56k connection enough for this application and is it technically possible?
Thanks in advance for any comments or suggestions.
While I don’t understand what you are trying to do, keep in mind that 56k modems are not analog at both ends. They require an ISDN line at the server to get the 56k download. The upload is much slower. If you hook a typical 2 wire phone line and use 3Khz of bandwidth (300-3000hz), applying Shannon/Hartlet theorem you get about 26k of throughput via a line with 20db s/n ratio. Noise and transients are going to reduce that. In reality the modems will have to connect in analog using v.32 coding. This will get you to about 28k with tcp/IP and SLIP or PPP overhead.
So even more math, if you diddle with the frame size you can probably get average speech with g.729 encoding down to a 4k frame that will fit without fragmentation into a SLIP frame (slip is lighter than PPP). To be this efficient you will need to customize the Linux serial protocol stack.
So you should be able to get 3 calls and the SIP signalling into the 3Khz of bandwidth available on a dial up connection.
Cellular voice bearer channels do the QCELP voice(Qualcomm code excited linear predictive) coding of CDMA being the highest quality and most efficient by far. It would be awesome if you could have the CPU power to run a more efficient coder than g.729.
Now if the subscriber lines go through a digital concentrator as many do today you are basically screwed.
The latency of the SAT connection should not be an issue as long as jitter and packet loss are under control. Don’t forget Cisco has a Call Manager on the International Space Station.
If I have not put you to sleep already I can recommend more reading. Long before SIP came into existence I did my graduate work in digital transmission systems. I spent my first 20 years in paging/cellular where every bit of bandwidth had to be preserved. Code space and processor bandwidth was at a premium in mobile devices also.
Thanks so much for taking the time to read and reply to my post. You certainly did not put me to sleep – on the contrary what you shared was very informative, and certainly seems to be based on a well established foundation of practical experience.
To clarify a few things for you – The latency I was talking about is purely the delay of the conversation audio. We have made Viber calls (which are peer to peer and not via a Viber server) , via the satellite internet connection and the delay over the conversation is really annoying.
My mate lives in the country which has no mobile phone coverage, and he lives to far from his telephone exchange to get ADSL.
So the idea was to see if we could (just for kicks) use two 56k modems (I have two old RS232 MultiModems - Model No: ZBAMT5634ZBA) to establish a permanently dialled up data connection which acts as a remote extension to a FreePBX Server. The FreePBX Server has access to good ADSL (for SIP delivered trunks) and potentially a GSM gateway.
[VOIP ATA]<---->[RASPBERRY PI]<----> [56K MODEM] |----------{PSTN TELEPHONE LINE}----------| [56K MODEM]<---->[RASPBERRY PI WITH FREE PBX SERVER]
The data link would only be required to carry one remote extension voice channel and the associated SIP signalling.
The simplest solution is analog to analog. Connect a POT line to the server via an fxo card (with DISA and a strong pw) so that the remote guy can dial into that, and then get out again to the rest of the world through the server.
Makes no sense to convert analog to digital back to analog over a POT line when you can do it directly…or am I missing something?
That would certainly work, but would cost a call every time a call was made. If it was an ‘Always Up’ connection it would be more economical and also just appear as an extension.
Quick note, The ISS is about a 500 mile round-trip. Communications satellites about 45000 mile round-trip. Given that c is immutable and the fair chance that there is buffering involved, getting usable full duplex calls is unlikely, and don’t use echo cancellation. Maybe depending on range good old 2 meter radio and an interface from here. . .
Well, you are in luck with all of this. On the dial up connection you can use the USB port for a modem on the R Pi and create your PPP connection to the ISP within the OS. Build a g.729 connection down an IAX trunk and give it a shot.