We have an IVR setup that we've been working on lately. We have dial plan that is working fine, we have 1 PRI line connected to our Server (FXM8aPCI card) coming from PABX, also there are 4 analog phones connected with PABX to transfer the calls to sales/support service, we don't have SIP! Only analog phone.
Right now when we use Dial() method to transfer the calls to analog phone, like this:
Dial(DAHDI/1/106)
it would return an error called "Cause 17 - user busy", channel 1 is the channel on which user currently is on and listening to IVR menu, how do we just transfer the line? when we use Transfer(DAHDI/1/106) it doesn't work.
To check this error, we plugged in another line in another channel #2, coming from pabx aswell, now when we did this:
Dial(DAHDI/3/106) it works, but then again it takes up the channel, as if another user calls and press 0 to go to extension 106, it says Cause 17 user busy.
One last issue is when the call is picked up from extension #106 we only listen a loud noise like "someone is blowing an air in the receiver!".
Analog phone connected via 1 wire can accept only ONE call.
You can use call waiting/hold or parking if you want. But anyway you can't use more then 1 line per phone.
Related
I'm working on Google Actions Console.
I want to have my google agent to verbally warn that time is up (instead of setting a timer, for instance).
I have now two main scenes:
user says "I am ready", the agent responds "OK. Ready, set, go!";
(user says nothing and) the agent says "please stop now".
I would like the prompt in 2 to proactively run 5 minutes after the end of the prompt in 1, without the user having to say anything.
Is it possible to create a timer/delay fo 5 min before the transition from 1 to 2 or to have the prompt in 2 delayed of 5 min during scene 2? How can I create this delay? Is there any workaround otherwise?
NB: I'm not a developer so be patient :D
This is difficult to do without code, but not impossible.
First - in general, Actions on Google is poorly suited for this. It is much better for conversational systems rather than timed events.
You have two options for how to do this:
As part of an Interactive Canvas game.
Using a Media response.
As part of an Interactive Canvas game
This scenario has you controlling the timer using JavaScript code that is part of an Interactive Canvas page that you have loaded on a Smart Display or Smart Phone device. As part of the "Ready Set Go" response, you send data back to indicate that your local code should start the timer.
You'll capture this data as part of the onUpdate() callback and in your callback function set the timer. This timer is done using JavaScripts setTimeout() function. In the function that setTimeout() triggers when it is done, you can call the sendTextQuery() function to continue the conversation.
Using a Media response
This will work on devices that can play long-form audio, but do not have a screen (so they can't use the Interactive Canvas).
In this scenario, when you send the "Ready Set Go" response, you also include a Media prompt which plays a 5-minute long audio.
When the audio finishes playing, it will send a MEDIA_STATUS_FINISHED System Intent which you can handle and then reply to continue the conversation.
Which should you use?
Well... maybe both. Media works better on Smart Speakers, while the Interactive Canvas works better on Smart Displays and Smart Phones (assuming your Action is a Game).
I am working on my home automation app. I am using estimotes iBeacons and what I want to do is give my Home Automation Control the ability to know my proximity in my home. Each iBeacon is given a virtual switch on my Home Controller and when I come in contact with a iBeacon my device either in foreground or background will update my control to turn on my switch for when I am near a beacon and turn it off when I have wondered away from my beacon. All of this works perfectly and I am loving it, however some of my conditions rely on me to be in a proximity for a period of time, and what I am noticing is after a couple of minutes or even after a half hour of being near a beacon, the iPhone 5s basically drops its connection and then fires it back up, causing it to perform an exit (turn off my virtual switch) and then immediately perform an enter (turn back on the virtual switch). As you can imagine this is very annoying to the wife and myself in the middle of the night when the bedroom lights start to flicker on and off because of the exit/enter. I have read about people having this problem and tried everything I have seen on the internet to no avail.
What I noticed is that whenever a monitor crossing has been crossed for a iBeacon, both the didDetermineState and the corresponding Enter/Exit call back functions are called. What can I do to get this to stop occurring? I can provide code examples if needed but this is more of a general question.
This is a common problem with iBeacons (and wives of geeks like us), and the simple solution is a software filter. You must ignore region exit events that last only a few seconds until you verify that there is no subsequent entry event.
You can do this by creating a variable (e.g justExitedRegion) that tracks these events. When you get an exit region notification, set justExitedRegion=YES and start a five second timer. When the timer goes off, if justExitedRegion==YES, perform your exit logic normally and set justExitedRegion=NO. Otherwise skip processing the exit logic.
Meanwhile, if you get an entry notification and justExitedRegion==YES, set justExitedRegion to NO and skip your entry processing.
If you just want to know whether you're at home or not at home, you could fire up the GPS on the phone and check your location.
Assuming you have a wifi network at home that your iPhone sees regularly, geolocation will work very well even inside the house where there will be no GPS signal. It will know no the latitude/longitude of the wifi base station and give that as your current location.
So use iBeacon as your primary location detection, but verify the data it gives you using GPS.
Also, you should contact Estimote to be sure you don't have a faulty unit or something. It is pretty new hardware, there could be issues.
I want to create an iPhone application which will display notification that an incoming call is being forwarded from an outside line, to my iPhone.
Purpose being, I have 3 separate office land lines that forward calls to my cell phone after hours and I would like to know from which they are coming from.
is there any possible way ? Kindly help,thanks in advance.
On an unjailbroken phone, you cannot interfere with incoming calls in any way.
On a jailbroken phone, your ability to do this depends on the phone system that's doing the call forwarding.
I developed and app that is currently set as "Location based" so that it can run in the background indefenitely. It's not a trick i need it to do stuff when the user moves.
After some search I learned that this app will only execute code on the event of a location change, no timer whatsoever will be able to execute any code after 10 mins.
My app, while in the background, stays connected to XMPP for 50mins or so, it then disconnects. I would like the app to never disconnect, I looked at the framework but I can't find the place where to fix this behaviour. Do you know if it's possible to stay connected "indefinetly"? if so what settings do I have to change in the xmppframework.
thanks
[EDIT]
After 50mins the user is still connected to XMPP but it's disconnected of the XMPPRooms it was conected.
On another run it was connected for 3 hours, the time the iPhone is connected doesnt seem to be consistent.
To make sure your application can do send and receive keep-alive messages, it needs to be a voip app and use a voip socket. From Apple's Documentation:
Add the UIBackgroundModes key to your app’s Info.plist file. Set the value of this key to an array that includes the voip value.
Configure one of the app’s sockets for VoIP usage.
Before moving to the background, call the setKeepAliveTimeout:handler: method to install a handler to be executed periodically. Your app can use this handler to maintain its service connection.
As for the socket:
NSInputStream and NSOutputStream: For Cocoa streams, use the setProperty:forKey: method to add the NSStreamNetworkServiceType property to the stream. The value of this property should be set to NSStreamNetworkServiceTypeVoIP.
Many reachability test codes seem to incorporate "notify" concept so that when network gets back on, user can get notified.
Do I need to implement the "notification" part? Is it acceptable to alert user whenever he tries something that needs network connection and it is not available? (without notification when connection gets back)
I see example codes deals with pure network availability(if the device is connected to wifi, 3g, and so on) and with reachability to specific ip. My app needs to connect to specific ip address when appropriate. In this scenario, just alerting if that ip is not reachable in appropriate times are all that's required or do I need to handle something more?(such as putting different messages for alerting user to turn on network and for alerting user that my ip is not reachable)
Thank you
1.
I'd recommend taking a look at Andrew Donoho's Reachability class that is an extension of the sample released by Apple:
http://blog.ddg.com/?p=24
That'll abstract away the need to worry about handling the notifications and allow you to focus on simply testing the reachability of your IP or if a certain network type is active.
2.
In terms to actual notification to the user, I'd say that depends on your application. For instance on the vast majority of the screens on one of my Apps the UIView attempts to do an async download of data from a RESTful service when that view loads. I don't do any reachability tests beforehand, I simply attempt to make the call and if the request fails, I notify the user after the fact. Unless you have a specific case of needing to know an IP is reachable, I'd think in the general case handling any errors on connections attempts should be sufficient. I'm sure there are are plenty of edge cases though that you might want to test reachability first.
On the other hand I do use the reachability on a given screen that I recommend a WiFi connection. Since that screen performs a fairly data intensive sync, I warn the user if they are on 3G that the sync make take quite a bit longer vs. WiFi simply performs the sync.
AFAIK, there is no requirement that you pop up a notification when the network becomes available, or in fact that you actually pop up a notification when the network is not available. You could instead enable/disable network-related buttons (as long as the user can know why the buttons are disabled), display an unobtrusive on-screen indicator, or whatever.
The important part is that you do not display a blank screen or a cryptic error message when the network is not available, or otherwise leave the user wondering why things aren't working.
I don't know of any requirement that you differentiate between "networking off" and "networking on but IP address unreachable".