A long shot with arduino and SIP Phone over network with voice?

hello i know this is a long shot but i was wondering if there was a way to talk in voice from a arduino to a cellphone over network with voice some kind of sip phone or something using internet and wireless maybe not using a GSM shield? i know there is something like Asterisk i see out there but from what i see it controls from the cellphone to the arduino with leds turning off and on but i would like to do with voice talking back and forth from arduino to cellphone? or maybe from cellphone to cellphone using the arduinio as the server who know this is why I'm asking if anyone got any pointers or have done something like this please met me know thank you.

The Arduino is not a good choice for such project because the processing power is too low. Use one of the embedded Linux platforms (Raspberry Pi, Cubieboard, PCduino, etc.) to play with VoIP.

I don't see what your problem with Asterisk is and how that should be related to cellphones and blinking LEDs. Please describe what you want to achieve, "some voice talking back and forth" isn't a very precise description.

Hello pylon i don’t have a problem with Asterisk i never used it before i just only heard of it the other day and what people are using it for to control leds through pbx and stuff so i didn’t know what i can use to start a project like this voip project i also have Due boards and i have 2 sam20 boards both in the 84 mhz rang cpu i have some mega’s as well. So in doing a project like this i do not know what i would actually need as far as hardware or software that is what I’m asking for.

My Goal what I’m trying to do is make a link up between whatever 2 or 3 locations i can talk in voice my friend at his house from my house. or from my house to my brother house Just one place at a time. yes i can do this with skype or a cellphone and any other software that does voice online. but i thought this be fun to build and try it out to see if i can do it.

For simple setups like you're describing a server isn't really necessary. I don't see how an Arduino would fit into that project because I don't know of any implementation of VoIP (whatever protocol you take) for Arduino even if the Due might reach the processing power needed. You first problem might be to get NAT less connectivity between the sites. Take a look at some VPN solution (OpenVPN is probably the easiest to start with). Then get familiar with any of the embedded Linux platforms (I would suggest a Cubieboard http://www.cubieboard.org as it has surely enough processing power and lots of hardware interfaces), there you'll find enough software support (given you don't want to implement everything from skretch).

Okay gives me a lot to think about. But what I would like to do is not only talk in voice but to call them as if it was like a phone similar to a cellphone. I will look more into this I have sew a video of some one streaming audio from one arduino to another on the same network so maybe something like this can work for me figure out a way to stream it both way and some how have it connect to different network not sure I would like some more input on this subject if you have more please let me know I would love to here it. Or if anyone else haves or done something like this please let me know I would like to here it also thank you.

I can give you some pointers but this is about the limit of the time I have to spend on it.

It is 15 years since I was dealing with this stuff 8 hours a day but I keep my toes in the water, reselling and supporting a SIP hosting service. You have several problems to address and there are different network protocols which deal with each of them. There is a little bit more to it than streaming from one Arduino to another over a LAN, as you have to interpret and comply with a raft of international Telephony standards.

SIP - Session Initiation Protocol. You can think of SIP as the virtual equivalent of a physical telephone line. SIP deals with registering your telephone with a SIP server, like Asterisk, which functions similar to a (PBX) switchboard or public telephone exchange. Handsets use SIP to register with the SIP server, like plugging a traditional phone into the wall socket which is onward connected to a physical port on the local exchange switch. Once the phone has registered, SIP is used to pass the traditional line signals which control the call set up and tear down. Idle, off hook, dialling, number passing, busy, on hook. SIP is also used to send VOIP meta data , such as negotiating a common codec and the bandwidth for sampling and throughput. By convention, SIP uses UDP port 5060. SIP messages are plain text, resembling HTTP and SMTP. SIP uses very little bandwidth but there is a lot of text parsing to do, which will be a challenge within the limited RAM and runtime of a small micro-controller.

SIP is to VOIP what the FTP control channel is to file transfer. That is, SIP does not pass voice samples. Voice samples are sent back and forth using RTP or the encrypted version SRTP.

RTP - Real-time Transport Protocol. Uses UDP ports 10000 to 20000 by convention. Both SIP and RTP are transport agnostic and may be run over TCP but few installation do that. You can think of RTP as a wrapper around a voice sample, with some meta data in the headers. The challenges you have with RTP are throughput and bandwidth.

For baseline comparison, when you make a call on POTS (Plain Ole Telephone System), your voice reaches the local exchange and gets digitised into amplitude companded mu-law PCM, before being shipped around the inter-exchange network at 64Kbps. IIRC North America use A-Law encoding, resulting in slightly lower bandwidth. Automated voice services and answering machines will typically use ADPCM (Adaptive PCM) to drop the sample width, so the file size and ultimately the necessary bandwidth, at the cost of sound quality. The drop in quality is not linear. Dropping one bit is hardly noticeable but the second bit is noticeable the third very noticeable and the stream soon sounds a bit rubbish.

Voice occupies about 4.1Khz, which Nyquist suggests is a minimum sample rate of ~8Kbps. The very lowest sample rate used in voice telephony is half-rate GSM, at 6.1Kbps but it sounds awful and many people are of the opinion it is not acceptable. You also have to allow for the RTP sample window (20 to 30 ms), meta data and IP headers, which adds up to a G.729a codecs 8Kbps sample rate, taking up ~20Kbps over uncompressed RTP. As you have such a limited CPU, you will want to do all the compression during digitising and stream the pre-compressed samples. With a limited vocabulary, the exact words can make a big difference on the minimum bandwidth you can get away with.

To summarise that lot, the filesystem, CPU and network interface all have to be up to streaming your voice file, at least as fast as the minimum acceptable RTP packet rate, otherwise the voice stream will break up and drop out, much like a mobile with poor reception. My educated hunch is you will struggle to meet this lowest acceptable rate.

Let’s be optimistic and imagine that you have sorted your SIP and RTP challenges.

To route your call to a mobile phone, you will need a gateway to the PSTN (Public Switched Telephone Network). You could build yourself an Asterisk server, sign a peering agreement and make sure you are compliant with telco obligations. It is much, much easier to sign up to an existing SIP provider. Then you only have to worry about making your device emulate a SIP phone. If your device is behind a (cheap) firewall and sharing an IP, you can use a protocol called STUN (Simple Traversal of UDP through NAT) to find your SIP and RTP endpoints. Personally I would try to avoid using a VPN, as the encryption introduces additional latency and processing overheads.

Good luck.

hello MattS-UK thank you very much for the information there I'm reading through it still a lot of it blowing my mind but some of it i do understand.well not sure is can do a voip or sip from arduino to arduino. or some kind of two way streaming of audio over the network. well got a lot to think about. thank you