I'm looking to create a windows application in vb.net or c#.net that will capture the phone number of incoming calls. This would be a land line. What would the hardware requirements be? Which .Net libraries would be used?
You'll need a recent modem that supports Caller ID and is supported by Windows. Windows provides an API for talking to the modem called Telephony Application Programming Interface, a.k.a. TAPI. Unfortunately, this API cannot easily be accessed from managed code.
Your best bet for getting access to Caller ID in managed code would be to use one of the free or shareware TAPI OCX controls that sit on top of the TAPI API, most of them should have a simple API that would give you the incoming number. Google for something like 'TAPI OCX' or 'TAPI Caller ID' to see what's available.
If it's a landline you're talking about, all you would need would be a standard analog modem and a serial port to connect it to. You'd use standard AT-style commands to control the modem and monitor incoming data.
For specific commands and events, check out the Wikipedia article on the Hayes AT command set
If you have a VOIP system, your system provider may have an API available to do this. Based on my experience, it will cost extra and be buggy.
Related
I was wondering if it is possible, in a universal windows app, to monitor all the probe requests around my device. I read and tried several samples codes provided from Microsoft to locate AP, but what I would like to do is the opposite, looking for every devices that send the probe request.
I read that it is usual to use Wireshark, but it possibly does not support the monitor mode under windows, and furthermore I want to use it in an application (even if I could use TShark...).
Well, is there an API that could do the trick ? (I looked at Windows.Devices.Wifi, WifiDirect and Co)
Thanks !
I understand that Cortana needs to be able to connect to the MS services to process natural language spoken to her. However, is a connection required when trying to get your UWP app to interact with her?
For example, when trying to launch a foreground app with Cortana, you are providing a local VCD (Voice Command Definition) file that defines the commands that Cortana can respond to. Does this then require the device to be connected and online?
My confusion stems from using the Windows.Media.SpeechRecognition API where depending on the grammar and constraints used determines whether you need a network connection or not.
How does this relate to Cortana?
Well, after scouring the Cortana API docs and still not being able to find concrete documentation on an answer, I finally stumbled upon the Cortana Extensibility in Universal Windows Apps video and around the 12:20 mark, the presenters flow diagram suggests that even Voice Commands are routed to the Microsoft Speech Platform Service (cloud).
I want to develop an app with VoIP and sip. I have found a good example from Microsoft sample is ChatterBox VoIP sample app
From this app we can receive or make audio or video call to some one.But I can not call to another number.
In this document VoIP apps for Windows Phone 8
the incoming call is possible through Microsoft Cloud server. It will push a notification to our phone.
I have also found some third party SIP clients for Windows Phone 8 like LinPhone and PJSIP but they are not providing how to use that thing
Now my questions are :
1) How can I integrate SIP client to this ChatterBox example or How can I call to another number?
2) Can it is possible to user other that Microsoft Cloud server means can I use my own server to push call to my app?
3) In ChatterBox example there is a default incoming call. How can I call from another to my number / my app ?
Thank You.
ChatterBox is just a framework for what a SIP App could be, it shows you Background Process code and also Scheduling Tasks and Push notifications.
If you want to be able to make SIP calls, you need to download the src code of a sip library like PJSIP which works very well.
Just run the code and call pjsua methods, they encapsulate the functionality quite well.
I have written an c# 4.0 application that analyses the microphone input and records DTMF tones that represent credit card numbers entered by our clients. This all works well, but since we are working under PCI Compliance (see www.pcisecuritystandards.org), we don't want to allow the logged in user (call centre staff) to listen or even record the microphone input so that they then can parse the credit card numbers on their own with a 3rd party app or their phones. So the question I have is:
How can I restrict the microphone input to a specific application so
that it can't be heard or recorded somewhere else?
If there is no solution to this, the 2nd question arises:
How can I restrict the microphone input to a specific user so that it
can't be heard or recorded somewhere else (I could run the software
as a Windows service under specific user credentials)?
Kind regards,
JB
The main way to restrict access to device is setting of Security Descriptor on the device. So granting of the permission for specific user group is the way in which you should go.
The exact implementation for Windows XP could be different from later versions of Windows. Windows 8 have new possibilities too. Audio Mixer APIs can be used in Windows XP. Starting with Vista Windows Multimedia Device (MMDevice) API can be used. MMDevice API's implementation of the property store. You can use IPropertyStore::SetValue and IPropertyStore::Commit to change properties. Unified Device Property Model are introduced starting with Windows Vista. There are different Windows API which uses internally SetupAPI to access to devices and to set it's properties (see here). I think that you should set PKEY_Device_SecuritySDS property to secure device. One can use old APIs like SetupDiSetDeviceRegistryProperty and SetupDiSetClassRegistryProperty to set the properties on Windows XP (see here).
If I start on my computer devmgmt.msc and examine default property of microphone device then I can see Security Descriptor
What you need is to change it so that only specific user groups (or users) access it.
There are PKEY_Device_SecuritySDS and PKEY_Device_Security properties which can be change by SetupDiSetDeviceProperty and SPDRP_SECURITY_SDS or SPDRP_SECURITY (see here). Usage of SDS parameters (PKEY_Device_SecuritySDS or SPDRP_SECURITY_SDS) could be easier because there use readable Security Descriptor Definition Language (SDDL).
After you change security descriptor on the device you need use SetupDiSetClassInstallParams and SetupDiCallClassInstaller with DIF_PROPERTYCHANGE and DICS_PROPCHANGE to reset the device. You can find the code example in the source code of devcon utility on WinDDK. Alternatively you can use CM_Disable_DevNode and CM_Enable_DevNode to restart it with new properties.
You should be able to do it with the Core Audio API. For each playback device and capture device in the system, you can control whether the device can be used in exclusive mode.
One drawback - there is no support for Core Audio API under Windows XP.
I think the solution to your problem is to write a KS Filter
Create a Kernel Streaming filter that is able to decode the DTMF on demand of your application and send the decoded data to your application. When the filter is in DTMF decoding mode, it just outputs silence to the rest of the filter stack.
If an USB audio device is used, you could also write a GFX Filter instead, which can be configured on a per-user-base. But this only seems to work for 32-bit operating systems. WinDDK has a sample called gfxswap.xp.
You can use ASIO audio drivers in your application.
ASIO is a technology developed by Steinberg to provide low latency audio input and output, and as a side effect, requiring a device using an ASIO driver completely restricts the device use to the process that required it, in addition to multiple other advantages that may be irrelevant to your needs.
It is available for every soundcard thanks to the ASIO4ALL project, so compatibility won't be an issue as long as you provide it with your application
For more informations, check out the wikipedia article about ASIO here, or pick up the SDK here ( you will need to register a Steinberg Developer account to proceed )
Will it be helpful if you can control (MUTE) the VOLUME of the sound device and set it back to it's former state once you are done? You can look at this link for ideas. Good luck.
With .Net what is the best way to interact with a service (i.e. how do most tray-apps communicate with their servers). It would be preferred if this method would be cross-platform as well (working in Mono, so I guess remoting is out?)
Edit:
Forgot to mention, we still have to support Windows 2000 machines in the field, so WCF and anything above .Net 2.0 won't fly.
Be aware that if you are planning to eventually deploy on Windows Vista or Windows Server 2008, many ways that this can be done today will not work. This is because of the introduction of a new security feature called "Session 0 Isolation".
Most windows services have been moved to run in Session 0 now in order to properly isolate them from the rest of the system. An extension of this is that the first user to login to the system no longer is placed in Session #0, they are placed in Session 1. And hence, the isolation will break code that does certain types of communication between services and desktop applications.
The best way to write code today that will work on Vista and Server 2008 going forward when doing communication between services and applications is to use a proper cross-process API like RPC, Named Pipes, etc. Do not use SendMessage/PostMessage as that will fail under Session 0 Isolation.
http://www.microsoft.com/whdc/system/vista/services.mspx
Now, given your requirements, you are going to be in a bit of a pickle. For the cross-platform concerns, I'm not sure if Remoting would be supported. You may have to drop down and go all the way back to sockets: http://msdn.microsoft.com/en-us/library/system.net.sockets.aspx
If this is a tray app, and not a true service, be wary of how you set up your communications if using pipes or TCP/IP. If multiple users are logged into a machine (Citrix, Remote Desktop), and each user launches a tray app "service", then you can run into a situation where you have multiple processes trying to use the same well known port or pipe. Of course this isn't a problem if you don't plan on supporting multiple pipes or if you have a true service as opposed to a tray app that runs in each user shell.
Have your service listen to 127.0.0.1 on a predefined port with a plain old TCP stream socket. Connect to that port from your desktop application.
It's dead simple and it's completely cross platform.
Did any one of you actually try remoting with Mono? It works just fine. You might bump into some corner cases, but this is highly unlikely. Just test your application for cross-platform (MS.Net <-> Mono) remoting from time to time to catch any possible glitches. And start with a recent Mono, 2.4.2 is current.
Remoting is an option, but it's not cross-platform. Some other ways are to use named pipes, IPC, or kernel events.
Funnily enough I was going to suggest Remoting! The Mono 1.0 Release Notes (from archive.org because the original location is missing) mention System.Runtime.Remoting.dll as a supported library and doesn't say anything about known issues.
If remoting is out then you probably have to implement your own TCP message framing protocol. Windows doesn't have an equivalent of UNIX-domain sockets for communication on the same machine.
Most services that have a GUI component are run as a named user, and are allowed access to the desktop. This lets you access it via COM or .NET but only locally (unless you want to get complicated)
Personally, I open an ordinary old socket on the service - its cross platform, allows multiple clients, allows any app to access it, doesn't rely on Windows security to be opened up for it, and allows your GUI to be written in any language you like (as everything supports sockets).
For a tray app, you'd want a simle protocol to communicate - you might as well use a REST style system to send commands to it, and stream XML (yuk) or a custom data format back.