Is it possible to recognize when a caller has barged-in with DTMF? Is there something in VoiceXML like an event that I could catch?
The problem that I am trying to solve is we need barge-in to 'cascade' for several prompts so I was thinking of setting a variable if I could recognize barge-in and then skip over the next few prompts.
If your browser supports mark (see VoiceXML 2.1 Spec, section 4 Using mark to detect barge in during prompt playback), you should be able to detect barge-in. However, only a subset of browsers support mark and because DTMF is often detected on a separate path than speech, make sure your browser supports mark on both paths. In some cases, even the telephony protocol being used can impact whether the feature exists (again, an artifact of the technologies used to put the systems together).
One alternative that may work, depending on your browser, is to create a series of fields or forms. Each with a very short or non-existent timeout. Go forward on the default timeout path, but break if you receive a nomatch or match. This will work fine for some browsers, other may have noticeable gaps between the fields/forms.
Related
I have an NFC tag that has integrated environmental sensors inside (MLX90129 to be exact). I would like to make an iPhone app that can read the realtime data from the tag multiple times per second and graph them. I'm not looking for background tag reading, and you can assume that the app will be open and the phone is near the tag at all times.
From what I can see on Apple documentation and other sources, the Swift support for NFC tags is mostly built for single session interrogation. Has anyone succeeded in getting continuous and repeated NFC tag reading for this type of purpose?
As you pointed out: "to make continuous and repeated NFC readings" it's not the intended functionality.
While I think that you can sort this out, there's another thing that could be a headache... to make multiple readings per second it's directly confronted to the current implementation of NFC tag reading in iOS.
Every time you start a reading, it shows the native window which informs the user that you are making a NFC Reading. A part of this process is the interaction of the user, and is exactly that part the one that imposes a time constraint. Even if the interaction with the user is not needed, there is an animation, and that animation has its lifecycle's events (start reading, reading, OK, KO, close...).
Afaik you can't bypass that animation which definitely could represent a couple seconds in the best case.
With that said, you should have a few things in mind, if you still want to try:
NFCTagReaderSession can only have one active reading at a time, and when that reading ends (OK/KO), it should be invalidated. So if you want to make another reading, you'll need to create and configure a new instance.
I'd like to protect against unauthorised system extension teardown that are triggered by
the container application following this command:
self.deactivationRequest =
OSSystemExtensionRequest.deactivationRequest(
forExtensionWithIdentifier: extensionIdentifier, queue: .main)
self.deactivationRequest!.delegate = self
OSSystemExtensionManager.shared.submitRequest(self.deactivationRequest!)
Is there a callback in the endpoint extension code, that can be invoked upon this deactivation request, and may block/allow it ?
thanks
There is no public API to control the system extension deactivation with EndpointSecurity or inside sysext itself (activation and deactivation management, I think, is a job for some daemon, like sysextd).
I could advice to try two approaches for your case:
You may still be able to deny deactivation with EndpointSecurity, just not in direct way. To deactivate sysext the responsible processes would do a lot of stuff, including opening some specific files, reading them, etc. In case you are lucky, you may be able to fail the deactivation process by blocking one of such operations before it really deativated. However, the context of operation (how do you know the target is your extension) may vary and be less than you need.
You may intercept the OSSystemExtensionManager.shared.submitRequest call inside your application, and add some condition to really call original method from interception method. The interception for submitRequest will be a swizzling.
Or you can place an old good hook on something deeper, like xpc_* stuff, and filter your deactivation request by some unique string from request, also calling original method only on some condition.
Both ways are not bulletproof from perspective of tampering protection ofc, but nothing really is, we just requesting additional efforts from hacker.
If you haven't disabled library validation for your app, there are two ways of tampering it: either turning SIP off, or using some 0-day system breach.
You can't really protect your app from such treats: 0-days are new, you don't know what it may be, and with SIP off the one may unload/disable/alter all possible kinds of protection stuff.
What is the best way to transfer binary data from plugin to browser.
We want to play YUV buffer received from network on browser tab.
currently am converting to base64 and giving via callback. but it is not efficient and am finding below issues
1> CPU and Memory is going up
2> Callback events are not passed when we change the browser tab, later all events are given at one shot on moving back to our tab.
I would also like to know is there any way we can directly draw YUV frame on browser using plugin thread itself.
Thanks in advance.
NPAPI has been removed from most major browsers... the last holdout, Safari, will be removing it as of macOS Mojave. That being the case, don't expect any updates of any kind to the spec -- however you're using it is likely a dying method.
That being the case, on windows there is a method (super hack, really) that you can use to draw directly to the window in the browser from a native message extension, but it's not portable and it depends on internal implementation details. I haven't actually looked into it since I wrote that other answer (linked in this paragraph) so I don't know if it still works or not.
Anyway, if you're on a browser which fully supports NPAPI then you could draw the YUV data directly to the plugin window given to you on the browser; there is an example of blitting image data in FireBreath which you could possibly trace through as an example.
You could also try some variation of listening on a TCP port in the plugin and connecting to it from the browser; you could easily run into some security issues there, but it is the only other method I can think of.
NPAPI simply wasn't ever designed to allow fast transfer of data between the plugin and the browser; I submitted a proposal to add that capability years ago but it was basically too close to the death of NPAPI (which is basically past at this point) for it to go anywhere. The issues you're seeing are 100% consistent with what I would expect, though... and it's still the best way I know.
While using tshark, I want to capture a packet that contains a specific string.
After executing tshark, I want it to stop receiving packets immediately when it receives a packet that contains the specific string and return it.
What parameters should I use to do this operation?
I think you're looking for something like trigcap, which is part of the Wireshark project, but not currently being shipped to my knowledge because it apparently doesn't work on Windows and may have problems on other platforms now too since it hasn't seen any active development in quite a long time AFAIK.
You can try to compile it yourself to see if it meets your needs. Read more about it at:
Bug 2039 - Triggered Capture
what is the work of trigcap?
If you're on Windows, you might want to take a look at the dumpcap.bat file posted on the Wireshark wiki Tools page.
All of these solutions rely on BPF (pcap-filters), so whatever string you're looking for as your stop condition needs to somehow be manipulated into that format, which may not be easy to do.
I've got a Behringer X32 rack, which uses an extension of the OSC (Open Sound Control) protocol. This particular rack communicates via UDP packets on port 10023. A fellow named Patrick Maillot actually has some pretty extensive albeit unofficial documentation of the protocol, including multiple executables you can download to interact with the system (outside of the official Behringer apps).
What I would like to do is pretty simple, though I'm having a hard time getting up to speed with this. I want to be able to mute and subsequently un-mute Mute Group 1 on my device. The mute group is already set up; all I want to do is utilize the protocol to either activate or deactivate it.
I can successfully connect to the rack using the X32_Command.exe program. But wading through the documentation, here's what I came up with as my best guess for which commands I should be sending:
/config/mute/1/ON
/config/mute/1/OFF
However, I don't think I have the syntax right (or maybe I've just got the wrong set of commands altogether), because those don't seem to do anything. In the X32_Command.exe console application I appear to receive the following responses when issuing those commands, respectively:
->X, 20 B: /config/mute/1/ON~~~
->X, 20 B: /config/mute/1/OFF~~
However, nothing actually happens on the rack. The mute group isn't affected at all when I issue these commands. How do I get this working? What am I doing wrong?
Just saw this (better late than never). The correct syntax for X32_Commmand.exe would be (as stated in the documentation):
/config/mute/1 ,i 0
/config/mute/1 ,i 1