Develop Reference

How can I bridge phone calls to VoIP?

I want to have one stationary device like an android phone that can use a standard local SIM card and forward all calls to a second device over some kind of VoIP protocol. When someone calls the phone number of the stationary device, I want my second device to ring and handle the call through something like linphone, element, or whatever. Ideally, it should be possible from the second device to initiate a call from the stationary device's phone number as well. Bridging SMS too would be nice, but I already have a solution for this on android.
There are many use cases like
when traveling abroad, being able to bring the latter device and receive/make calls via the stationary device at home
forwarding multiple phone numbers to a single device and e.g. switching off the work number when away from work
having privacy when the location of SIM cards is logged, by making calls over wifi from somewhere else than the stationary device
when traveling somewhere with bad mobile coverage but available wifi, without having to think about how the second device handles it
Are there any existing projects for doing this?
If not, then what would be necessary to make something myself? Is the best solution something like connected an android device by bluetooth to something running asterisk like was discussed here? Or has something changed in the past 11 years, maybe the existence of some working linux phones makes this possible on a dedicated purism or pinephone device?

I think you can achieve this with Brekeke SIP Server. I am using their solution to achieve something similar to what you want to do.

there are multiple ways to achieve it technically, but the most practical solution to your use case will be to use a VOIP Gateway device.
Actually we can not use a mobile phone as gateway between SIM and VOIP calls.
so you can buy a voip gateway example GOIP (single SIM) and put your sim, connect to your home internet and configure. your phones softphone (eg linphone) will be able to directly register on it and you will be able to make/receive calls and sms.
there will be a new problem as mobile OS platforms are more and more restrictive about power, your sip client will not be able to receive calls while in background for that you will need push, so you can use twillio's mobile sdk to make a client that works fine then forward your calls to twillio from gateway. since there is no number or telecom services involved, cost on twillio should be minimal.

A more common way to do this is with an operator service, rather than implementing it yourself.
The operator is able to see the routing to your number and simultaneously call multiple numbers you have set up. Different operators will have different names and details so you would need to speak to your local operator.
For example BT in the UK (who I have no affiliation to - just an example) provide a service called 'Follow ME': https://support.ringcentral.co.uk/s/article/9010?language=en_GB
If you do want to do it yourself than an open source PBC like Asterisk is indeed a good starting point.

How to receive incoming message over wireless LAN network and launch web browser?

I am a little stumped. I've been trying to find a way for a wireless device (i.e. Android/ios/Windows mobile devices) to receive a message from a central server and then launch the device web browser.
The Scenario: a server on a WLAN network monitors a certain system. when something on the system goes wrong, the system stops what it is doing and sends an error message to the server and wait for the user to enter a response on the server before it resumes what it was doing.
Now, I want to send a message from the server(when the system it is monitoring crashes) to the wireless devices, so the user does not have to go to the server all the time to continue the system but can just do it over the wireless device (in the web browser).
Just to clarify, I know how to send a message out from the server to everybody connected to the wireless network, i just don't know what to do with that message on the devices...
Any ideas or solutions would be HIGHLY appreciated...
Thanks in advance

You can do this a few different ways:
1) Using commercially available Push Notifications (Google & Apple for example). The advantage is your application will work outside of your wireless LAN, but the disadvantage is you're using their platform, which is restricted in its ability and functionality (having designed and built a couple of these platforms myself I can attest to their limitations - they were going for "least common denominator" when they designed and implemented theirs).
2) If your app is only going to run on a LAN (you control the network) you can put your own system together. The advantage here is there is almost nothing that cannot be done (except on iOS which has several limitations related to the topic). The disadvantage, though, is this is a lot of work.
3) Leveraging an existing platform that might have been designed for a different purpose but can easily be used with minimal changes for your own purposes, and offers a nice compromise between options #1 and #2 (this will require some additional backend/middleware servers to add to your mix). Look at XMPP and Jabber as an example.
Once you have this piece of your architecture in place - receiving pushed data - the only missing item is invoking the handset's browser (or browser type component in your own native application) in response to the received payload.
** As possible alternatives it's worth noting that most mobile platforms allow your native application to directly interact with the handset's IMs or e-mails. For example, you can write code that intercepts a specifically formatted IM, with a small payload, and use that as a "poor man's push engine." I have put together little POCs (proof of concepts) for clients using this technique on Windows Mobile, BlackBerry, and Android (not sure what's possible with iOS in this regard) as it's quick and easy.
The hard part is the pushed data (but several available options on how to handle this requirement), the easy part is invoking the browser.

Phone-to-phone communication on Android

I am building an app that converts text messages to speech and sends them to the destination. At the other end, the speech is converted back to text messages.
I imagine it may be easy with Twilio but I don't want to use internet connection. A simple call should be enough to transmit the data.
Any idea on how I should proceed with this?

I don't think this is really possible to do, your tasks would be pretty heavy ...
TTS- that's no problem android has a library for that TTS and recording it
Make a phone call and monitor state Make phone call monitor state
Send your synthesized message - can't quite find a way to do this, seems problematic sending recorded messages over phone network it has been suggested that you could play the recording over the speaker and the microphone might pick that up, seems like a good way to introduce even more errors into the system though
On the other end something must answer - Answering a phone call
Record incoming call - this seems to be highly problematic on a non-rooted phone Recording incoming calls? or Recording incoming calls
Take the recording and do reliable STT without the benefit of a server back end, also highly problematic since the translation errors even on high end server apps are sometimes quite comical
So without a rooted phone with a custom rom I don't think all of this is possible even if you could overcome the poor quality of a double translation TTS -> STT
Twillo seems to be about making calls over the net vs. the phones digital network not about sending text (in essence) over a phone connection
Seems like a whole lot of extra work just to avoid an internet connection charge (of about 2 seconds and few bytes!)

Android Communication: Phone to Phone Application Control over 3G

I'm currently working on an android project and I am trying to find the best way to go about setting up communication between two android phones.
One android phone will be docked on a mobile platform e.g. an R/C car. I want this phone to receive simple control signals ("forward", "backward", "left", "right", "gotoCoordinate") sent from another android phone. I also want the docked phone to be able to return status signals.
Preferably I want the communication to happen via GPRS. I'm aware of the difficulties concerning P2P-communications and I'm currently looking into "Android Cloud To Device Messaging." (http://code.google.com/android/c2dm/index.html)
I'd like to hear about your experience with Android C2DM (glad to hear about delay from transmit to receive) and your thoughts on utilizing it in my project. I'd appreciate other suggestions on how to go about this. I'm expecting to have to deal with relatively high latency using this method, but of course preferably lowest possible.

C2DM makes no guarantee about the "delivery or order" of the messages, and it is limited in the number of messages you can send (a high limit, but still a limit). It's not really for low-latency stuff like controlling an RC car. It's better for non-realtime events.
http://code.google.com/android/c2dm/
For lower latency stuff using GPRS you can setup a third party server on your own and have both phones communicate through it. I've done that for several Android apps using straight up TCP sockets and it works reasonably well (and it would be even faster/better if you went UDP). Using GPRS may still have too much latency, depending on your needs, but it's a tradeoff (it's very convenient, almost always there, other methods are not).
The ideal way to do this would be to combine whatever is available and fallback gracefully, and test the latency once connected to make sure the network is up to par, or bail out. For example, use the local WiFi network if it's available. That is to say, have both devices "register" with a third party server as they startup, then if they're both on the same WiFi just have them communicate directly (run a server on or both, and clients on one or both, get information about discovery and such from the registration). If they are not on WiFi then fall back to GPRS, but realize there will be more latency, of course. Finally, once any method has been established send some test messages to check latency.
I know this isn't really an "answer," it's more of a stream of consciousness about this, but it wouldn't fit in a comment, and I thought it might help ;).
(Full disclosure: I've worked on Android apps that connect multiple mobile devices and multiple TVs, some over GPRS, some Wifi, some directly. I work for a company (MOVL) that makes a platform for stuff like that, it's more focused on mobile-TV-mobile, but it supports mobile-mobile also. In all it's not too hard to do yourself with regular networking, the tricky part is getting the latency down and picking the correct method for each device.)

Data Transfer between Mobile Phones Across Connected Voice Call

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.