I'm trying to build a Google Assistant Action that dials a phone number (using my device and my phone number) and once the call is connected interact using Dialogflow's voice synthesis to interact for a few minutes before connecting me.
Is there an option to do this inside the Actions SDK?
The desired behavior is to do this the same way Assistant does when I say "Hey Google call Mom". (This might be a North America only feature at the moment) Basically, it connects the call via my Google account phone number so caller ID looks like it's from me via either a mobile device or smart speaker.
Dialogflow appears to have a beta telephony option that might be a usable workaround, but it's a handoff, not the call coming from me.
Alternately is there a service like Twilio for voice calls?
The feature is not currently available with Actions on Google.
The Dialogflow outbound telephony feature is only to transfer calls that have come in through the telephony feature. It does not work with the Assistant.
Related
I want to write an application which will be a bridge between VoIP app and phone line.
E.G.:
- I am writing in Skype to user XXX "call to ******"
- User XXX call me back and by phone modem calling to ******
- So I can speak throw my VoIP and phone modem for free (except internet and phone fees)
I thought to use something like this.
The better description is here in Calling section.
But it is outdated and my server part is on Ubuntu
Could you please advice VoIP (e.g. Skype, Viber, WhatsApp, etc) which I can use for such purpose? It would be great to have a client on Android Phone and server on Ubuntu.
Thank a lot,
If I have well understood, the use case is:
A wants to call B through an application running in a mobile device
B has a phone land or mobile line, but not a VoIP one to receive the call.
Bridge between internet and phone lines is to be done at home (A's home) without specific subscription costs, that is to say, without the services of a VoIP provider (I should like here to suggest rethinking the use of a well stablished solution as costs to call phone lines from IP can be really cheap).
Well, there is a lot of solutions for this scenario. I am going to speak about one of them that I consider interesting because it opens the way to a lot of additional communication services.
First, the softphone. To make and receive calls, A will need an application in his or her device. Consider a softphone as Zoiper or Jitsi Meet.
Then, the gateway between VoIp and phone lines. Asterisk can do the work as a SIP server. It is a lightweight linux software with a lot of features. It can switch VoIP lines with land phone lines via FXS - FXO cards (if the phone lines are analogue ones), ISDN cards, VoIP interfaces, bluetooth using mobile devices, etc.
Last, but not least, the connection. Ok, you do not want to expose your gateway to the dangers of all those wicked people of internet, eager to stole your phone line minutes. Connection between mobile and server could be done using a VPN (e.g. OpenVPN), or through a web app (SIP on top of WebRTC).
Once you have the asterisk working at home, you could use it as an answering machine sending email messages with the received audio, as (if your local regulations allow it) a recorder, as an IVR or as a part of a security system, calling sequencially phone numbers in case of emergency.
I want make a simple app (action) on Google Home speaker but I cannot find any docs in which is described how to get access to mic.
Is there any chance to develop VoIP app on the Google Home device?
In short - no. (Or at least not at this time.)
The only access Google provides third-party built apps is through Actions on Google, and this does not provide direct access to the microphone or to an audio stream.
I do an aplication that reports valance
I simply call
platformRequest("tel:*222#");
Where *222# is the way to get valance in my network
Work in Samnsug for the moment
But in Some Lg istead of do ussd do a voice call and of course fail
I want to know if are a way to force do a ussd intead a voice call to *222#
for this phones.
i believe that J2ME does not support the USSD protocol because in the JSR 120 for messaging the specifications does not tell us that the USSD protocol needs to be implemented by the provider API company. See this link to get more info:
http://javatnews.blogspot.com/2012/06/ussd-in-j2me-or-jme.html
Greetings, Pavel
For example, if I have a friend over and he wants to show me a video using a given app that runs both on my device and his device. Could that app display a QR code on the screen or something that he could scan and instantly be granted access to my Chromecast device?
As Ali mentioned, Chromecast devices are discovered and apps launched via local network applications. One an app is started, it could easily connect with a cloud service that allows other (non-local) devices to talk w/ your Chromecast via the cloud service. A Chromecast Receiver application is just a HTML5 application (HTML, CSS, and JavaScript). You can really do what ever you want once your application gets launched.
If displaying a QR code that allows some kind of rendezvous with your cloud application is what you want to do, you can certainly do that.
I presume your friend's mobile device is on the same wifi network, right? Currently, a chromecast device has no identity outside of its local wifi network, so if the sender is not on the same network as the receiver, there is no way they can exchange messages. Back to your question, if your friend is on your network, then he could see your device except from those applications for which your device is not whitelisted for. Is that the case you want to handle through, say, a QR code? If so, that is currently not doable either since whitelisting is not just a local setup. Maybe I misunderstood your question?
Based on your questions, you are saying that both you and your friend have the same app. If so, and if your friend connects to your wifi network, then he will see your chromecast (you do not whitelist a device for a phone, you whitelist a device for an app id and as long as your friend has the same app (hence the same app id I resume), your whitelisted device will be discoverable by his phone. On the other hand, if you do not want to give him credentials to get on your network, then you need a cloud backend and a lot of work, since although your chromecast device can send a message to cloud and your cloud service can notify the other user's phone (using, say notification or some other mechanism that you employ in your app), the reverse (i.e. sending a message from your friend's phone to your chromecast (through your cloud service)) is much harder. Your friend's phone can send your phone a message (again via a back end service, a bluetooth communication, NFC, etc and then your phone using your app can send that to the chromecast receiver but I am sure you are getting the idea that it is a lot of work. Signing up on your wifi network can be made easier with a QR code or something so at this pint, that would be the easiest solution.
Google just announced that they will add support for VoIP calls in its Gmail application.
Does someone know how this will work? Did they manage to write a web-based VoIP client, or will they require the user to have Google Talk installed and somehow (how?) call this app from the browser?
I'd also like to provide customers with a way to make/receive calls through their browser, so that they wouldn't have to install an SIP client.
Thank you.
Google don't use a VoIP client in a browser. Instead the browser is used to initiate a callback to a phone number you must have previously registered. Once you answer that call Google Voice will then ring the destination number you specified and then bridge the calls together.
I've just noticed that in my inbox. They ask you to accept their EULA to start installing Google Voice. So it's not really a browser solution.
There are several companies that have built VoIP clients as e.g. Java applets.
It is totally doable, although depending on the exact requirements it may be expensive and time consuming: for instance, echo cancellation is not exactly trivial when you need to deal with arbitrary audio drivers across any and all laptops, netbooks etc out there.
There are also consulting firms that can help with that.
Full disclaimer: I own one such company ;)