Is it possible to call a whatsapp contact from other than whatsapp, say for example I have a sip provider. Can I use it to call a whatsapp number?
There is not, as far as I can tell, any directly supported way to do this. The whole Whatsapp paradigm is mobile-phone-centric to the extent that even tablets (running the same OS) won't work and the Chrome web app requires you to use your phone to authenticate it by scanning a QR code.
The closest I have been able to find is the yowsup2 library which has some tools that could probably be used to script up a SIP-to-Whatsapp bridge running on a Linux server. That would be IM text only though, since I don't think that library supports voice calls.
A PC running the Android development environment and Freeswitch/Asterix would have all the pieces you need to build a bridge for voice calls, but it would be a real project to put all that together.
If you can figure out a way to make Bluetooth-initiated calls go through Whatsapp (a big "if"), then you can accomplish a similar result with one of those BT-to-analog line adapters and an ordinary phone.
In Skype-land, this can be done by forwarding calls to a PSTN number (with the concomitant charges per-minute). I am not aware of Whatsapp having that feature.
For a while, it was possible to bridge Google Voice to SIP (when they inherited SIP subscribers from Gizmo5), and then they shut it down. So if the Goog takes working SIP interoperation and shuts it down, I wouldn't plan on any of the walls coming down around the Whatsapp garden anytime soon. If you want SIP you are on your own.
Related
I am struggling to find how to let google home do a local network rest call.
I have some ESP8266 laying around with mDNS and rest api in them.
Now with the google home I want it to send a rest call to the device.
I don't want any web hooks / services like IFTTT. I don't want the communication going through these 3rd party services.
It should work like this google home gets input (google service to understand is oke). It retrieves the action (local network, url rest call with body). Google home sends the rest api call to the local device.
No need to have port forwarding / firewall changes.
The Google Home does very very little on-device processing. Sending out local network calls is not one of the things it does. Almost all processing, including IoT controls through the Smart Home API, are done through cloud-based services.
Update
I can't answer "why" it doesn't do this, since I'm not one of the engineers that built it, but I can make a lot of guesses about why.
For starters - it increases the complexity of the software and hardware on the device dramatically. Right now, the device is really little more than a microphone and a speaker, with a little logic to detect the hotword and then stream everything else to the server, and then get a result back and play it. Most of the rest of the code is likely to handle setup and configuration.
If the device has to also be a general purpose IoT hub, then it needs software and hardware for Bluetooth and possibly other signaling systems. It needs to be able to keep track of the state of other devices on the network and manage that in between power cycles of the device (or even handle interruptions in power for the device itself). Some of the implications of that may need to open up the networking on the device to receive messages, not just send them. It has to have more extensive network configuration - to understand what local networking is and not just what the local router is and how to deal with that configuration (and that configuration when it changes). These are all possible, to be sure, but increase the complexity and, in some cases, lower the security of a device.
And that might be reasonable... if there was significant value in doing so. But you've already stipulated in the question that the voice processing could be done in the cloud, so once commands are sent to the cloud and parsed there - why not also do all of the above (device and state tracking, changing, etc) in the cloud? Particularly since most IoT devices maintain cloud servers anyway because people also want to be able to control or monitor their home devices when they aren't on their home LAN. Having a dual set of commands (some for when you're local, and some when you're not) does make sense in some cases - but also dramatically increases the complexity of both the controller and devices, so most just rely on the cloud, again.
So while I understand why some people would like to have a nice little system that can just sent your play local REST server a command now and then, the reality is that to do this for a consumer system isn't that reasonable.
If you really wanted a system that can do this - you can continue in the hobbyist spirit and build something with the Assistant SDK and your favorite IoT platform.
The “local” API for Google Home is a bit limited. Here’s a doc from someone who reverse-engineered the API.
Looks like they expose Bluetooth and Alarms/Timers, and some limited configuration stuff.
https://rithvikvibhu.github.io/GHLocalApi/
I'm trying to write a simple chat application for the iPhone (as an experiment). Is there a simple way for two devices to discover each others' IP addresses, and given the addresses is there a simple API or protocol that would let me send text messages back and forth?
I've investigated SIP (specifically Sofia and eXosip), but these tools exist as C libraries and are beyond my current ability to port them to the iPhone.
Update: I'm trying to connect two devices over the Internet (i.e. not over Bluetooth or a local wireless network, which is what GameKit does).
You're going to need a server that provides the match making service. Game Center makes this pretty easy, but your users will have to have Game Center accounts.
Alternatively, you can set up an XMPP (formerly Jabber, it's what powers Google Chat) server (I've never done this, but there are several available) and use the XMPP Framework for Cocoa. There are instructions for using it in iPhone apps here.
I'm sure there are other chat servers and client source also available. IRC and Mobile Colloquy come to mind.
Finally, you could write your own server using your favorite server language / framework. This isn't too hard (I've done it myself), but it's far from what I'd call simple, and I wouldn't use it for a production system.
There is support for exactly this kind of ad-hoc peer-to-peer networking in GameKit. Have a look at the second half of the GameKit documentation for details:
http://developer.apple.com/library/ios/#documentation/...
NSNetService is a good option.
Take a look at WebRTC Datachannels. WebRTC is a newer option with native iOS support a standard that is still being finalized, but it is more flexible should the iOS app need to communicate with browser or even android peers
I'm just getting started with mobile development, and after considerable searching I'm still confused about sending a message from my iPhone to another or an Android. For instance, in building a simple Tic-Tac-Toe game, if I want to notify the other phone of a move, what is the best way to do so? Wifi, bluetooth, 3G? And how?
Many methods seem to point to communicating through a web server, but I'd rather send them directly from phone to phone if possible. (this is for native apps of course)
If you don't want to have a server (or even if you do! It depends!) it sounds like you will want to use TCP sockets. Apple doesn't have a generic bluetooth API to use with iPhone-to-android communication and you'll have TCP access anyway with 3G. A 3G network connection is very similar to wifi and you should be able to check for the difference as needed with little change to your overall networking code. I'm not sure if bonjour is supported on android, but I bet someone has ported it for similar reasons already, and it is supported in iOS. Apple has a networking section for iOS that you may find informative.
Additionally if you want to stay within the iOS device only realm you could use GameKit to communicate via bluetooth.
Hope that helps some.
The easiest way is to create a web server with an API and the clients poll the server for new moves (or the server pushes the client an update). This is the only way you're going to be able to do it over 3G unless you can figure out the IP addresses of both phones (do phones even keep the same IP address for a long period of time?) and open up sockets between them and let one phone be the server and the other be the client (could cause potential cheating).
WiFi is not always there - by limiting your users' options to areas with access points, you'll lose sales. Not sure about Bluetooth - how prevalent is it on handsets, how much of the API is exposed. Your best bet, IMHO, is 3G. With some kind of a central presence server (Web or otherwise), with optional proxying. Read up on peer-to-peer networking.
As far as i know does the iphone only support incoming messages over push notifications.
This means, that you have to update the information, by requesting it from web services etc.
The bluetooth API of the iphone doesn't support this either.
I want to send some Text plus a image from one iphone application to other iphone app but restriction is I should not use a web server in between communication,Is there any way to fulfill it ?
Details: There are two independent devices and could be far enough say out of network. My requirement one app adds some text with a image and sends it to another iphone which can be at any long distance , and the app installed in another iphone will read that info and image into itself.
Actually there is a solution that meets your needs — and that fits to bbums answer:
Create a HTTP-Server on the iPhone, using cocoahttpserver. than you will ask some webservice like whatismyip.com for your public ip. with this your iPhone can be connected worldwide.
But very likely ur wifi-network is not forwarding your port to the iPhone. Ash.
And even if: Now it gets difficult. How to publish your ip from one phone to the other? hmmm... — I got it: I will exchange the information in a centralized space! In the web!
... wait — that would be a Webserver.
You see: Without any kind of server in the Web the users would need to exchange ip manually and have full admin power and knowledge about the local network.
So IMHO bbums answer is the only way to go.
PS: I am working with http server running on iPhones. In local network that works great, especially with bonjour. And you can use them over distance network — but only with reconfiguration of your router — something you shouldn't force your user to do
There is far from enough information to provide a specific answer.
two apps on two different devices?
are the two devices on the same network?
are the two devices both on WiFi?
do you need the user to receive a notification or something if the app isn't running?
If on same device, you can define a custom URL handler in the destination app and then openURL: in the source app to pass the data over. Encode your image and text into the URL, but be careful of size limitations.
If on different devices, there are many possible solutions, but answering the above questions will be critical to actually knowing what solution is appropriate.
Given your comment -- two apps, different devices, arbitrary networks -- then you are going to have to have some kind of server in between. Note that the recently added Game Center does have the ability to rendezvous two users, but it has a very particular user experience that may not be appropriate to your needs.
I would suggest that you investigate using push notifications to notify the receiving user of the availability of content. As for moving the content between, no direct connection is possible and you will have to have some kind of store-and-forward server in between. And, yes, a web server is going to be the easiest possible solution simply because HTTP is ubiquitous these days.
If there's no network of any kind available, but both parties have amateur radio licenses, then hooking the two devices up to HF packet radios might work.
THIS is super EASY.
I would code up some software that can turn data into modem signal, like the good old dial up modem. The device would actually make those annoying buzzing sounds.
You get the phone number for your friends nearest landline and call him.
He places his iPhone near the phones receiver in listen mode and you connect to his phone using your audible modem.
Bingo, via the power of sounds you have sent data which is decoded on his device and all for the very cheap price of a phone call, there are pretty cheap these days especially if you use Skype.
Easy Way (relatively speaking)
A way two apps on different networks can communicate without setting up a web server of some sort is as follows.
Use an existing third party storage system like DropBox.
Each app would need the login and password for your DropBox. Then both apps can read and write files that the other app can see.
An existing app that does this is a shopping list app called ShopShop.
The app on my phone and my wife's phone both link to the same DropBox account and the app keeps the shopping list synced up when one of us adds something to the list.
Background
There are a lot of App Store released iPhone apps that require an IP based server on the desktop so that the iPhone can connect to the desktop as a client. For example, there are many programs that emulate a keyboard, touchpad, or Apple remote on the iPhone so that a desktop computer can be controlled over wifi. However, many of these applications get around writing their own server by requiring the user to install some VNC server variant.
Question
What is the best way to implement a secure (encrypted) IP server on a desktop (Mac and Windows platforms) that allows for simple two way message passing between itself and an iPhone client on a wifi network?
Sample Use Case
An event on the desktop causes the desktop to push a small image or text to the iPhone. An event on the iPhone causes a short text message to be pushed to the desktop. Any single event can happen at any time (doesn't appear synchronized to the user).
1st Follow-Up Question
Would this type of project be best handled using something like XML or JSON over HTTP? Or is there a better protocol, like BEEP or Bonjour(XMPP)?
What is the best way to implement a secure (encrypted) IP server on a desktop (Mac and Windows platforms) that allows for simple two way message passing between itself and an iPhone client on a wifi network?
Not sure if there is a "best" way, but much code is already available to do xyz-over-HTTPS (TLS/SSL). In that case, the "xyz" can be any web-based message exchange protocol, such as XML, JSON, etc. via REST or SOAP, etc.
If you want to be able to push events to a non-jailbroken iPhone you can't do it other than via Apple's Push Server which causes a notification to the client program if it is running or otherwise displays an alert of some kind to the user.
Typical architecture has those notifications handled by the client program as an indication it should go and get some data from the server - Apple insist we do not regard the notifications as trusted delivery.
I suggest a read of this article on using Bonjour and local networking, whilst it's iPhone to iPhone it should apply to desktop OS/X also.