Simulator to test IVR application - ivr

I am developing IVR system using asterisk . To test my application , I need PRI lines and PRI card whose cose is around 30000 k . Is there any simulator available for same which i can use for my application.

For most testing of IVR applications, a softphone over SIP is sufficient. If TDM is truly required, one option is TDMoE (TDM over Enternet) which is functionally similiar as a PRI; however, it can be run on standard Ethernet.

Related

WebView in MacOS: How to request file system permissions correctly

It may be because I'm not developing a traditional Swift app, instead I'm using the https://github.com/zserge/webview library to develop a cross platform app.
My app has 2 parts, divided into 2 different threads: one thread launches the window and displays a JS app. The second thread contains a background server bound to an ephemeral port and serves a json api, written in Rust. The Rust side is also the one talking with the File System and making all requests. On Linux I don't have any problem, but on Mac it works only when requesting resources from root and home directories but not from Documents/Desktop etc
The first problem I had when running it on Mac has been allowing access to the server from the window: I had to add a new entry to the info.plist file, according to this answer in stackoverflow: The resource could not be loaded because the App Transport Security policy requires the use of a secure connection
This resolved the issue I had talking to the server bound to the ephemeral port. Truth be said I have to also say that now it requests me to allow access to external resources every time I launch the app.
But, when trying to execute a function which requires access from the Rust side to the Desktop (for example), it doesn't work and it does not show any popup and never did
Btw, if you want to have a look at the final product, maybe to help you understand better the app, have a look here: http://getdevspace.com/
Check the ch mode file system
Even had the same problem so i checked the ch mode so it worked
Thanks

Wear Actions execute very slow or not at all when phone is in doze mode

I am building an Android App to control power outlets with a smartphone. The app features an Android Wear app so people can control their lights right from their wrist.
When the user wants to control a light I send a String action via the MessageApi from the smartwatch to the smartphone, which receives this action in a WearableListenerService and sends the appropriate network signal to the power outlet/gateway in an AsyncTask.
This works fine as long as the phone has not been in idle for too long. However if the phone is still on the table for too long and doze kicks in Wear actions do execute very slow or sometimes not at all. I guess this is in part intended behavior however it is not practical in my case as the user cant wait that long for his lights to turn on if he wants to enter a dark room.
I am aware that doze completely cuts the networking for everything except FCM/GCM if you are not on the doze whitelist. But even when my app is on this whitelist and the networking part works actions can take a long time to execute on the phone.
So my specific question is:
Whats the recommended way to handle this scenario, where an action from a wearable device needs to be done via network on the connected smartphone which is in doze mode?
Is there a way to exit doze for a quick amount of time to execute calculations triggered by the wearable companion app faster?
I know the AlarmManager has a new method that works even in doze mode, but will this fix the processing delay too? Firing an alarm after receiving a MessageEvent from MessagApi seems like a workaround to me.
Or maybe is an AsyncTask just the wrong way to handle background networking and thats where the delay comes from?
Actually, there are a few options that you can do to handle Doze's effects as given in Adapting your app to Doze. You may want to consider the following options:
If your app requires a persistent connection to the network to receive messages, you should use Google Cloud Messaging (GCM) if possible.
GCM is optimized to work with Doze and App Standby idle modes by means of high-priority GCM messages. GCM high-priority messages let you reliably wake your app to access the network, even if the user’s device is in Doze or the app is in App Standby mode.
To help with scheduling alarms, Android 6.0 (API level 23) introduces two new AlarmManager methods: setAndAllowWhileIdle() and setExactAndAllowWhileIdle(). With these methods, you can set alarms that will fire even if the device is in Doze.
However, please note that with these methods, neither setAndAllowWhileIdle() nor setExactAndAllowWhileIdle() can fire alarms more than once per 9 minutes, per app.
Please try going through Optimizing for Doze and App Standby for a more detailed information or discussion.
In addition to these given documentations, the same options in handling Doze were also given and discussed in Diving into Doze Mode for Developers which might also help.

Do I need to differentiate between Chromecast device revisions?

Given that Chromecast devices (both the 1st and the recently launched 2nd gen family) do only properly run when they have a working internet connection is it safe to assume that 1st and 2nd gen devices share the same public API?
Or do I need to do some magic number checking in my custom receiver code to check on which device revision the code is executing?
No magic is needed, they support identical set of APIs so developers don't need to differentiate them.

socket.io interrupted by incoming phone call

I am trying to collect GPS location every 5 seconds from a smart phone by using socket.io.
I notice that when users pick up a phone call, socket.io will stop emitting messages. When users switching tabs in the browser, socket.io will stop emitting messages too.
Does anyone know how to solve this problem?
Thanks very much!
Your best bet would be to package the website in a native app. Use a service such as http://build.phonegap.com or Intel XDK. There are configuration options to keep your app alive in the background. As for it disconnecting during phone calls, this is a carrier limitation. If the user was connected to WIFI, most phones will that for data while simultaneously on a call.
Some networks (such as Verizon) do not have the capability to do voice and data at the same time. Thus, when a call is made, data is suspended until the call is finished. AT&T does not have this limitation.
The operation of background tabs will vary by mobile browser and is likely done for battery conservation reasons. It is unlikely there is a work-around to keep the background tab running (because that would defeat the whole battery management purpose).

How to monitor a device with SNMP

I've been given a task to write some code to notify administrators if the device sends a trap. Also I'd like to be able to check upon the device as well.
I'm not so sure where to begin. Is there a test server online where I can test if I setup the device correctly? (Whether it send traps according to the condition I set?)
If I were to write code to monitor this device, I think I should learn how the snmp and mib files work exactly. Is there good summary and reference for me?
Is there some simple example code for snmp?
download any trial based S/W to receive traps on your system like LoriotProV6 or SolarWids.
In windows based sys open run evntwin.exe n select ur preferred options to generate traps like SNMP.
Here you need to check for Trapping column if it says "Yes" then only select it..
or else it wont mean any thing.
then click add run ur SNMP services.
To rum SNMP services go to control panel-> Add/Remove -> Add/Remove Windows component -> check Management & Monitoring click on details n check SNMP & WMI options.
now go to control panel-> Administrator tools -> Services -> search SNMP services n& start it.
You can consider 2 basic ways to check whether the device of interest generating/sending out SNMP traps.
You can just run wireshark on the device (if possible) or on the target server (where the traps supposed to arrive). Then you can filter the traffic using default SNMP ports. For example it could be one of the following: 161, 162, 10161, 10162.
You can install a MIB browser on the target server and see if any traps arrive. There are number of available free applications on the web.

Resources