I want to know if there is any way to communicate users without internet connection to a server.
I thought it might be possible through SMS and machine-readable encoding. However this question confirms that iOS apps allows sending but not reading SMS: iphone app reading sms
I've also read a lot about using USSD but it seems that mobile opened messages aren't possible in iOS (dial USSD code from iphone programatically) and while in Android is possible to call a code programatically there is no USSD API to, nor it's possible to send USSD messages silently.
Is there any way to transfer data between my app and my server with only basic voice-sms signal?
You are correct that SMS could be used to communicate with the server, if the server has access to a GSM modem. For large volumes of SMSes, you'd expect to have an internet connection between your server and an SMS gateway that connects directly to the messaging centre in the mobile network, instead of a modem.
This is the model of the SMS voting servers.
You can send/receive SMS as long as you have a GSM network, and you're right; no IP connection is needed.
The Android platform lets you send and receive SMSes - see here.
Disadvantages are that SMS can be expensive, and has no guaranteed delivery, and no guaranteed delivery time. It's not suitable for real time communication.
USSD is another form of communication between a mobile device and the network that's built directly into the GSM network, but USSD messages are owned or licenced by the network operators, and aren't free for customers to use, as SMS is.
EDIT: USSD isn't a native protocol in CDMA, but various implementations are available from different operators. For example, here's a patent application describing an idea for one such system, which does not appear to require an IP connection. Googling "USSD CDMA" also gives various news items about commercial implementations, technical details unknown. I think you just have to find out what your target operator(s) offer.
I haven't worked directly with WAP, but a glance at the WAP Protocol Stack shows that it can indeed run over CDMA, or GSM without an IP connection. There is also a very useful Wikipedia article. My experience testing MMS is that it usually doesn't work without an IP connection, even though it is supposed to (according to that Wiki article, with WAP/SMS). So I would question how far European operators or mobile devices are supporting or testing WAP. Whether WAP is a practical choice could come down to pricing/availability at the end of the day, rather than technical issues.
Well, there are yet other options, depending on the amount of data you need to transfer back and forth to the server.
Instead of sms, for short amount of data you could try to implement an Asterisk PBX, whith your mobile calling your server and then sending other DTMF digits as your data, which would be interpreted by your Asterisk PBX (like an interactive phone audio menu from your cable company). Asterisk is GPL open-source.
Another option (an expensive one and with heavy work to do), would be to generate an audio signal encoded with your data content, and dial a phone number linked with an attached fax/modem pci board on a server, sending that audio like a call. It would'nt need to be a long call, as you could fit lots of data in a short bursts of audio stream.
Your server could check that data by acessing the content on the receiving end. Simply recording the call from the attached fax/modem pci board, or you could use an Asterisk PBX server on a local computer to save the audio file and then process by your server software.
Anyway, you would need to create a new protocol and data encoding type, like you mentioned "machine-readable encoding".
So, for the data types you could just save a lot of short audio files on your mobile and play them as your datatypes, but it would be easier to just go for the DTMF already mentioned above. Or you could encode like this: get the sound spectrum allowed to use through the voice call (Wideband/Narrowband), and divide it by the amount of single characters or chunks needed (take a look at how to encode in base64, to have some ideas). Then create a function to just encode your data as a short audio stream (read about PCM encoding and also read more about Fast Fourier transforms, if you want to complicate (but speed up) even further.
Create a simple protocol like this: first audio packet is a sequence of tones that makes a request, authenticates, and waits for acknowledgement response from the server (which could be just by not dropping the call 1 second after that). The 2nd audio packet is the size of the first frame of data, then the 3d audio packet onwards is the data itself with the size shown before. And so on. Have a look at the ftp protocol description for simplicity. Then you need to refine it so that the time of every packet above is the least possible while mantaining confiability.
For costs saving on voice calling, you could also explore phone number options, like Google Voice, Skype or any Voip service.
Related
Context to understand my need: I moved to an area without good cellular data coverage but with good cellular voice coverage.
I want to send small amounts of digital data over voice. Preferably over Android phones.
I was trying a way to connect my phone acting as a dial-up modem, but actually I don't think that is possible to use Android as Dialup/FAX Modem
Anyway I don't need that because I have my own servers and I can configure a PBX to receive calls and translate "voice" (sounds) to digital data and send something in response.
Could be great to use all TCP-IP through voice in my phone, but my question accepts answers that just translate "voice" to small amounts of ASCII bytes (or less than ASCII) that my server could send to internet in a predefined way.
So my idea is to programming something for both (Android and server), but maybe exists another easier way to do it (with or without a PBX) or somebody knows of a ready-made library that I can base my invention on. I'm open to start from some good point.
Extra: Also this "feature" could be used in emergencies. And also is a good idea to encrypt data through voice (that is something that you can't do because GSM encryption is broken).
I am searching for a way to send fax via android phone.
Sending fax uses converting voice to data, its been done for years on land wire phones
by calling to remote fax playing the voice we all familier with and thats it.
So how\is it possible that the android phone will call to othe fax and convert some img file
to voice and will play this voice one it called to other fax?
Seems to be an hard work.
I would use a web serivce (yes, need to be paid)...
http://www.interfax.net/it/dev/webservice
Try to look at this:
http://code.google.com/p/freeboxmobile/
good luck
FAX is a bi-directional protocol that goes through several stages of handshake before the actual image data is sent. Even if you could write an Android app to listen and "speak" the correct audio tones, the QOS (quality of service) of cellular voice is lower than that of land lines and would not succeed. The only FAX capability offered by some mobile service providers allows you to receive a fax to your mobile number and it will get stored to voicemail. From there you can forward the message to a land line to print it out at a later time.
As others have mentioned, your best bet is to use a web (cloud) based API for sending and receiving faxes.
I'm trying to figure out if this is even possible:
I'm interested in writing a simple game that could be played in a peer-to-peer setup, rather than having to go through some intermediary server. I was thinking of using something similar to how SMS works, but I don't know if those routines are accessible.
From what I understand, SMS is just a data packet with a specific structure, and on a certain port, that gets sent to a phone number as the unique identifier, rather than an IP Address. If that is the case, is it possible to use similar routines to what SMS uses in order to send messages to another phone, but in such a way that SMS will not pick it up, and if the app that would understand that packet is not running, then the data would just get ignored?
You can write Apps that send SMS and receive SMS. Some things to keep in mind:
SMS tend to be expensive, especially when compared to IP traffic.
The user must grant the permission to send and read SMS to the app. He probably won't do, beacuse he knows it's expensive.
Even if the users contract offers a SMS flat rate, providers may limit the actual number of SMS being sent or forbid automated, high-traffic usage.
SMS might be much slower than IP packets.
If a user tries to play with someone who hasn't installed the App, that poor person will have his SMS inbox flooded with those SMS.
So it's mostly a bad idea to use SMS for that purpose. Some alternatives if the users are close enouth to each other:
Use bluetooth.
Use Wifi (Most android phones won't allow ad-hoc connections, but some phones can act as acces points so that others can connect to it).
Maybe: Use NFC (only some of the newest phones have this, and I don't know if you can use NFC that way).
Use P2P over internet (which requires at least one provider to allow incoming connections on their network with a public IP, e.g. no internal NAT).
Use a server that handles the traffic between phones.
I require a fast reliable method of sending control commands (simple data, possibly only a few dozen possible commands) to a remote system which is using a smartphone* as its onboard computer. I have deemed standard data packages used for mobile internet data transfer as too unreliable of control purposes, however I have noticed that once a voice call is initiated it is much more reliable. Has there been any development into sending data between phones across a connected call, and if not are there any known reasons a modified dialup modem in software form couldn't be used?
Furthermore, could this protocol be robust enough to send back low res video and other simple numeric data?
*Smartphone - A phone with significant processing power and ability to run custom programs (most likely with an Android based OS however am open to suggestions)
Have you tried SMS? while you won't get video data it may work for small chunks of data. Also if the small chunks are from the phone to a server, you may try sending DTMF down the line (however I've yet to see that working.
Other than that it's customised hardware.
Hmmm...this reminds me of those old TV games like Hugo...there you had a voice connection and I think the commands were given by the different tone of the key pressed from 0-9. Maybe you should try something similar.
Im going to develop one android application which transfer music file, contact exchange, voice chat, text chat etc.. through WiFi. Which protocol will suit my application UDP or TCP. Because both protocol having some merits and demerits. Can u give me some suggestion, it will helpful for me..
Thanks in advance
If you don't know which is better for your application, then you should use TCP. When you get to understand TCP and its limitations better, then you may want to delve into the arcane world of UDP.
If one was the best (universally), the other wouldn't exist anymore...
If you want to make sure, that the data you send is really delivered correct to the client: use TCP.
If you're application is performance critical and/or bandwith is a limiting factor and the data packages are small (fit in one frame), use UDP.
In your case, I'd use TCP/IP, because for streaming or big data it is necessary that all frames arrive in the correct sequence (or can be ordered by the client).
TCP.
UDP does not provide reliable transfer, which sounds essential for the applications you describe. For example, if you're exchanging contact details and half a phone number isn't received on the other end - which is very possible with UDP, how would you recover from that?
TCP:
This protocol is the most commonly used, the reason for this is its reliability on packet delivery, as each packet is guaranteed to arrive at its destination. its more commonly used for things like streaming media, where you do not wish to have data last/
With TCP, its slightly slower than UDP and has more features:
Ordered data transfer - the destination host rearranges according to sequence number
Retransmission of lost packets - any cumulative stream not acknowledged is retransmitted
Error-free data transfer (The checksum in UDP is optional)
Flow control - limits the rate a sender transfers data to guarantee reliable delivery. The Receiver continually hints the sender on how much data can be received (controlled by the sliding window). When the receiving host's buffer fills, the next acknowledgment contains a 0 in the window size, to stop transfer and allow the data in the buffer to be processed.
Congestion control
Source # Wikipeida > Transmission Control Protocol -> Data transfer
TCP would be the most best choice to start of with as its the most comment and has a wider range of features
You should use TCP, since you want to make sure your packets actually arrive.
TCP has a little processing and bandwidth overhead but makes sure your packets really do arrive and resends those which have not been reported to be arrived.
UDP is most commonly used in scenarios where the arrival of all packets is not mission critical, e.g. if you update movement data in an action game like a 1st person shooter. But even then, I'd use TCP these days.
The application you are talking about has a large spectrum of requirements in terms of networking. You might want to consider using:
TCP: for the delay tolerant needs e.g. non-realtime file/message transfer
UDP: for delay intolerant needs e.g. voice
With TCP, retransmission is built-in that which you don't get with UDP. You don't want to be retransmitting voice packets (as example).