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.
Related
As far as I know, wear smartwatches are designed to be companion devices that stay connected to your smartphone. Without a phone around, though, they aren't entirely useless.They'll still function as watches, for one, giving you the time and the date.
But I am not sure if there are any changes to this in any of the latest updates. So I want to know if it is possible to pair two smart watches and send messages using messageapi without the help of a smartphone.Just curious to know ?
Ideally, I want two watches to interact using messageapi to send messages. Is it possible to do without a smartphone?
Well, if talking about pairing two watches with each other, you definitely CAN NOT do this.
But, if you want to extend the abilities of an android smartwatch, you may add some features based on WiFi connection. Since a watch can be connected to a WiFi network, you're able to send messages and do some other stuff with it.
Also you should check up the Together feature, but as I may say, it's built on the interaction of two handhelds, but not wearables.
I am developing an application which connects devices over bluetooth and exchanges messages. It works fine for paired devices, but I would also like it to automatically pair devices that are not paired. Like for example it could store and use the same PIN for pairing requests, I just dont know how to manage this request programatically in my applciation, how to automatically set and send the PIN when you get a pairing request and how to initiate such a request with the predefined PIN code.
Any snippets or thoughts would be highly appreciated! :)
EDIT:
I know its risky, I am developing this app for emergency situations only where no other means but bluetooth is available. Also is there maybe a way of premature pairing with devices without even connecting to them? Like lets say there is a list of MAC Addresses of those devices and I can use them to generate a bond with that devices so that they appear paired on my device?
You can't do this. To do what you want to do would create a huge security risk. Think about it, my device just comes anywhere in bluetooth range of yours and now I can send you anything I want without you knowing? You can't really do this and I highly recommend not trying to subvert it.
Reflecting the setPin method allowed me to send the pin automatically to the other device. I had to implement it in a broadcast receiver that is listening for pairing requests. Although I cant get rid of the dialog it just stucks there on the screen and I dont know how to close it (programatically) and continue the bonding procedure since this dialog is called from inside connect() which is a blocking method. I am not giving up on it yet though :)
With Bluetooth version 2.1 and above there is a method of pairing called the 'just works' association model. This is the lowest security method of pairing and has no protection against man-in-the-middle attacks.
However, this will provide a secure, encrypted link without the need to exchange pin numbers or verify device ID.
The API on different platforms may differ but the underlying HCI messages require that you indicate that your device (or one of the devices) has the following IO capabilities:
No Keyboard, No Display.
As you might have guessed, this is a mode for very
simple devices that use Bluetooth, such as a speaker or headphones.
If you can find the API to configure that, then the 'just works' association mode of Secure Simple Pairing will be used for pairing.
The next step is to store the link keys e.g. bonding. Many devices e.g. mobile phones, will still create a dialogue box to the user to ask if they want to 'remember this device', as user authorisation is specified by the BT specifications... but that's another problem.
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.)
This is more about an explanation then it is about asking a question. What I am wondering is if its possible to write an Android application that can communicate with another Android phone, given the phone number of the phone I want to communicate with. By communicate, I mean I want to be able to send data to the phone and have my application on the other phone be able to recive it.
If its not possible to do this, then I guess my alternative is to have my application "sign" the phone into a server. Then I'm assuming the server can act a proxy to communicate with both phones.
Any clarification would be helpful!
Check out the BUMP api. It allows you to establish a connection between two (I think more are also possible) devices, and it gives you a channel over which to communicate. The devices need to be "bumped" first, but then it's all fair game.
Any reason why it has to be by phone number? That and i'm pretty sure you can only send data over WAN or local bluetooth/wifi.
Perhaps try something along the lines of a server that has phones sign into it and keeps track of the phones IP addresses allowing them to communicate almost directly to another (kind of like a dynamic DNS hah!).
Look into SMS. I haven't coded for mobile phones in years but I seem to recall that most phone operating systems let an app intercept SMS messages, react to their contents, and prevent the user from seeing them.
As long as you're not sending lots of data, SMS might do the trick.
I'm interested in fleshing out an idea for a Android phone app, and I'm wondering if this is possible. So I would have the app running in the background on Phone A, then when it finds another Android phone B, it saves certain information like time, GPS location, just state variables.
But if the other phone is also running the same app, the two phones connect and share trivial non-private information.
Hypothetically, would this be possible? Would I go through a local ad-hoc Wi-Fi connection, or constantly broadcast Bluetooth?
If both people have the same app, you could do it in a round about way. If two people installed the app on their phone and agreed to have their gps coordinates shared, you could upload both sets of gps coordinates to a server as the people move around. The server could then compare which people are close to each other. When the user wants to share information with another user, the phone just needs to ask the server who is in their vicinity and sharing could be done over the internet. This is essentially how Bump works. Bumping two phones together triggers a call to the server to see who else is bumping in that vicinity at the same time. After phones close by are discovered, you might be able to trigger bluetooth pairing and sharing if you don't want to share over the internet.
Bluetooth is the easiest way for two phones to communicate directly with each other. However, both phones would have to be paired through the Settings->Wireless->Bluetooth menu. You would experience better range and speed with WiFi, but this requires a router as far as I know.
I found out how this can be done, use the viewranger app on both phones, create a user and log into the app on both phones. I set this up with myself as the user. Then the second phone (the one with broken gps) is used to track the user who is in my back pocket.
The user in both cases is me.
The problem with this is that a phone signal is required.