We are developing a VoIP app and we want to switch to the Tokbox library.
Ours is like a telephone app just like Viber but for a specific audience. We need the app to behave like a telephone app. The user makes the call, the receiver hears the phone ringing, picks up the call and hangs it up when done talking. I could find a lot of resources on Tokbox online (for Android and iOS) but I couldn't find much info on a telephone with the library. Can anyone point me to the right direction or explain things a little bit.
Thanks in advance.
To implement a mobile telephony app (like Viber) where user A calls user B you need a couple of extra pieces in addition to TokBox platform.
First you need to make use of standard Apple&Google push notifications to initiate the call to B. For example you can use Google's service [1]. Typically A will send a HTTP request to your server to initiate the call to B and your server will use Google API to send the push notification to B.
At the same time your server should generate a TokBox sessionId for this call and send that sessionId and a token back to user A. User A can use them to connect to the TokBox session and start publishing while waiting for B to join it.
When B receives the notification then you can alert the user (ringing tone) and present any UI you want to him. When B accepts the call you can make another HTTP request to your server to get the sessionId and token for the call (that sessionnId and token could also come in the initial push notification) and join it.
At that point you have both users (A and B) connected to the same TokBox session, publishing audio&video and subscribing to the other stream, so you have a bidirectional audio+video call.
[1] https://firebase.google.com/docs/cloud-messaging/
Related
I am currently using the Twilio Client SDK for Android to make a call from Person A's android app (built by me) to Person B's phone. I am trying to figure out how Person A's android app can listen to DTMF tones passed in by Person B's dialpad and provide feedback based on the input. Right now it seems like the Twilio Client SDK for programmable voice does not support this use case.
One of the ideas that has been presented can be found here: How to gather Twilio DTMF input from call recipient on outbound call. However, I don't want Person B to have to be disconnected from the call. I also am not sure if I can set up a conference call and then initiate a call to Person B.
Another idea that has been presented is allowing a third party server to join this conference, and process the DTMF tones. Based on the input the server could send a push notification to Person A's app.
I'm not sure what the ideal solution is here and what is feasible. I'd like to start a conference between A and B and have my separate server listen in on the conference. But again, I'm not sure if this is valid.
There is a scenario where I have to communicate from one android device to another android device (Far Away). But without using any server or sms service. Although I do have an active internet connection. I found a way through GCM, as GCM service provide data upstream as well as data downstream.
I want to know is there anymore way of doing this ?
You need a notification service, and google has something like that for us...
how does this works??
Take a look at the image below,
you need to register your android app in the google service, and your web interface will need an id, so everytime you want to push something to the android, your web interface instead will push it to the google server with the Id of the app, then google (no matter how) will localize your app, and even if its not running, they will get the notification,
behind the scenes there is a couple of thing that you must do, bu nothing like launching rockets from the NASA.
I will suggest to take a look to some tutorials
in order to start with the registration of your app, get the api key etc etc..
In your case
you will need the id of the other phone, so you can push it data.
I'll start with the project idea I have in hand:
We are trying to make a simple application that requires the sending of messages between phones. Say there's phone A and phone B, and both have installed the application. Phone A sends a message to B through the application, and B receives it. B can do the same and send messages to phone A.
Since we want to target from Gingerbread and up, Wifip2p from google is not possible since it requires API 14 and up.
I read about GCM , and while I do understand the concept there's something I don't quite get yet. Every instance of the application registers with the server, the server then saves the ID so it can later use it to communicate to the GCM, and the GCM can use the registration ID to deliver the message to the phone.
What I don't understand is how phone A will be able to know the ID that corresponds to phone B, in order to tell the server to deliver the message to phone B.
I'd really appreciate the help, thanks.
EDITTED
Based no the answers, I think I'm not managing to express my question properly.
I understand that this systems bases itself in three factors: a server, GCM, and your device.
The device registers with the server, and the servers saves the device's registration ID which it will, later on, use to send it to the GCM so that the GCM can then send the appropriate message to the device.
What I don't understand is how the following procedure is carried out:
PhoneA wants to send a message to PhoneB, so phoneA would send this message to the Server, and the Server would later pass it on to the GCM who would then pass it on to phone B.
This explanation is nice, in the abstract vision of it all. But, how does phoneA tell the server that it wants the message delivered to phoneB. How does phoneA even know what ID corresponds to phoneB?
Hopefully this clears it up.
Phone A doesn't need to know the ID of phone B. Just make a method in your server that delivers a list of clients you are interested in (phone B, C, D, etc) when you connect.
When you send a message to your server, include the handle of the phone you want to deliver to. This should not be the other phone's GCM registration ID in my opinion, but rather a unique handle generated by the server.
For this to work, you need to either implement a your server -> phone A communication or use GCM to deliver the list of clients as a notification.
One user manages mobile users via a website interface. By clicking on a button on that website I have to display the current position of the chosen mobile user. So what I need to do is send something to the mobile app to trigger sending the GPS position to my server. My website then starts polling the database to check every 10sec whether the GPS coordinates have arrived.
Questions:
Is it possible to use Push Notifications for this purpose? I already implemented it, so everything would be there.
Can I do that silently, so that the mobile user doesn't get notified? I have found something called Silent Push Notifications - is that what I'm searching for?
I have to do it on Android and iOS.
On Android it is definitelly possible. There is no default behavior (such as alerts/badges/sounds) to notify the user of the app that they got a notification. When the app gets a push notification, a broadcast receiver is created and its onReceive method executed. You can have whatever logic you need in that method, though if you require a logic that requires a long time to execute (such as server calls), you should start an intent service from the receiver and do you logic in the service (get the location of the device and send it to your server).
On iOS I believe it is possible since iOS7. Until iOS7, the application logic for handling the push notification would only be triggered after the user clicks on the notification/alert to open the app. iOS7 enable the app to do background processing as a result of the arriving push notification. I believe you should use the {"aps":{"content-available"=1}} payload in this case (which is used for background content downloads), since you don't want any payload that would be displayed to the user.
For android you have some ways to implement the push service:
GCM - http://developer.android.com/google/gcm/index.html:
MQTT - http://mqtt.org/
implement your own persistent connection.
All of them have their advantages. If you need a ack that the mobile client got the msg you should use MQTT. It is also faster than GCM because of less overhead and you don't have the GCM server in between. On the other hand GCM is easy to implement and you don't have to worry about the persistent TCP connection from your server.
Also the silent way is possible because you just trigger a service each time. so if you don't want a notification, the user don't get it.
I am not sure about iOS. For iOS6 it was not possible to implement your own service, which is necessary to "wake up" your app. I am not sure about about iOS7. So for iOS6 you definitely need to use Apples push server.
(The following question is for mobile platforms in general (iPhone, Android, Blackberry))
We are integrating chat functionality into our existing application. I designed the system with a .Net web service and Sql Database to keep track of chat messages. Everything's working fine so far, when the chat window is open.
I need a way to notify the user of a new message when he/she is not currently viewing the chat screen (meaning either the app is not in the foreground or they are in another section of the app (not the chat screen).
Obviously, push notifications would be perfect here, but I'm not sure when I should be sending pushes.
How would the client sending the message know whether or not the other guy is viewing the chat screen? Should I just be sending pushed with every single message and have the receiving device decide whether or not it needs to pop up a window or display something in a nofication bar?
It seems like overkill to be pushing every single time a message is sent. How is this normally done?
Any ideas at all would be greatly appreciated.
Thanks.
First and foremost, keep in mind that your server will act as the broker for all messages passed between different chat clients. Here's how this could work:
User A initiates a message for user B
Message gets sent to the server.
Server determines that this message is for user B.
Server initiates a push notification and delivers the message to user B.
Now why would you need to push every single chat message? Because the only other way for your users to get notified would be to poll your server for new messages. Constant polling (at whatever rate you determine) is extremely bad in the mobile realm due to limited resources (battery, networking, etc.)
In a push notification scenario, it is up to your application to handle the logic of whether the user is notified on receiving a new message. What this means is that when user B receives a new message from user A, it's up to you to decide if you wish to notify B (i.e. bring your app to the foreground) or not. In either scenario, you want to use push notifications instead of polling.
On a similar note, user B does not necessarily have to know that user A's application (your app) is in the background which is why you will need to handle that logic (within your app) appropriately.
Push notification normally is applied to the application if it is not in the foreground. It is a way to wake-up the application to handle a new transaction from the server. Basically, a push notification is to be done if the client is running in the background and a new message is ready to be fetched from the server. As long as the new message is not fetched, if other messages arrive on the server, a push notification should be sent to the application.
Push notification is not necessary if the application is still running even if the user is viewing other screens of the application. It is however important that a thread is handling the connection to the server which is "patiently" waiting for transactions from the server.
One question, what protocol are you using for the messaging?.. Is it OMA IMPS protocol?