I have PC and VOIP phone. When someone calls to my account and I answer it using VOIP phone, I want the phone number to be stored on my PC.
What is the easiest way to receive caller number? Is finding a VOIP Java/C# SDK and developing my application (just to get a caller number) the only way or are there some clever shortcuts?
Note: I am familiar that softphones are displaying the callerID but there is no (reasonble, non hack'ish) way I can read it from softphone.
Depending on your softphone you might be able to configure it to save a calls log. Alternatively you could obtain CDRs (call detail records) from your VOIP server.
Another route to go would be to monitor incoming VOIP TCP connections and extract caller data from sniffed packets.
Or you could write a small program that will run in background and check periodically which is the active window. If the active window is your softphone, then it will take a screenshot and dump it to a folder.
What Vlad said. Providing the hardphone model details will get you more details :-)
If the PC is sure to be on all the time you want to operate the phone, you can install a simple SIP proxy on the PC that does nothing but logging.
If a softphone is an option, many of them can be scripted, I love twinkle for example.
Using wireshark (or more to the point tshark, the command-line version) you can build a capture spec that will only capture incoming SIP packets on UDP port 5060, and then only if the SIP msg is INVITE. Then you just have to look at the "From" line to see who called you (if it's filled in; it should at least have a number).
Related
I want to have the app i am creating to communicate with my personal android device. As in, my application will be monitoring something on my server, and when something changes it needs to somehow send an option to act or ignore to my phone, and my personal reply (Yes/No) should be send back to the server.
I don't mind any specific protocols. Anything which does not require an app running actively on my phone would be nice, but i am not that great with android native development so if it can be done it should be relatively simply to achieve.
My own idea would be to actually implement Email somehow. So my phone could get an email on my google account (which in turn creates a notification), to which i would send a reply email with my reply. Which in turn will be read out on my server.
The bad part is that i would have to actually open gmail and type out a short message to send back as a reply. So anything easier then that would be a great thing.
I have seen newer android 6 apps use custom buttons in notifications in order for the app to act on, but i have no clue how hard those are to implement and rig to my reply.
Please note that this application is probably nothing that will go public. So i am not going to bother to worry about load or efficiency in the end of it. Since it will be just me and my server.
Any input would be greatly appreciated. The most convenient/easy-to-use method will be marked as the answer.
I think...u can use xml-rpc " http://xmlrpc.scripting.com " for communicating with your server and android app.
I used it in my personal project and found iI to be useful.In my case,I used wordpress as framework so any new updates in my server is notified by this protocol.
Ok, I have a VOIP Phone. I know the IP address and the port of the phone and have full access to the phone, which I am using to make SIP calls via a SIP trunk.
I basically want to see what is going on on the phone at any given time and I don't know where to start.
If I started, initially, using Wireshark what type of network traffic would I need to look for?
Could I use Putty and view activity on the phone that way?
What part of the .Net framework would provide functionality for interfacing with a VOIP phone?
Thanks
(Most) VOIP phones uses UDP communication, so you would use the UDP functionality in .NET. This can be raw sockets or the UdpClient class, which is a nice starting point.
You can look in Wireshark for UDP communication that has the phone IP as endpoint. You should try to get the network protocol documentation for your specific protocol/phone, or it is likely to take you a very long time to deduce the messages you need to send.
Wireshark has a built-in SIP processor
According to http://www.splicecom.com/document-area/doc_download/272-maximiser-protocol-a-port-information-for-ip-networks they have several protocols providing different information which you can access to achieve what you describe.
Another option is to use the the TAPI provider they offer to access the information you want.
Some starting points for TAPI via .NET:
http://www.codeproject.com/KB/IP/devangpro.aspx
http://www.codeproject.com/KB/dotnet/CShart_TAPI_3x.aspx
http://www.codeproject.com/KB/IP/Video_Voice_Conferencing.aspx
http://msdn.microsoft.com/en-us/library/ms734214.aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/ms734257%28v=vs.85%29.aspx
Another option is to build a SIP proxy which allows you to do all sorts of things including the things you described:
http://www.codeproject.com/KB/cs/SIP_stack_with_SIP_proxy.aspx
http://sipsorcery.codeplex.com/
http://www.independentsoft.de/sip/index.html
http://www.konnetic.com/products/products_sip_sdk_std.aspx
http://www.voiceelements.com/Products/VEToolkit.aspx
Recently I have started working on a program that will monitor the packets of one of my open-source programs in an attempt to learn more about programming and networking. Also, I want to add additional functionality to the program without editing the source, like an external control panel.
(I used WPE Pro to filter packets in case you'r wondering, WireShark is too much hassle for such a simple task.) One thing bothers me though, the Socket ID.
I know what it is, and I've asked a question about it before, but I cant figure out how to use it/assign one/intercept one.
Without the right socket ID, my program wont be able to do anything, so my question is if it's possible to find out what Socket ID a socket is using, once you capture the packet?
If not, are there any other ways of doing? -or possible other languages like Visual Basic?
Thank you for your time.
If, by socket ID, you mean the return value of a successful call to socket() function, I don't think there's a way.
The closest thing you can obtain is the process ID because, as you may already know, each IP packet has a destination that's described by the tuple (IP address, port) and inside a system only one socket can be successfully bound to that tuple. Utilities like TCPView are able to map an IP tuple to a process, so a way does exist if that information is enough for you.
If that's not the case, I'm not aware of any method to retrieve the socket ID you need if the target application is not collaborative.
This library: SharpPcap promises doing capturing, injecting, analyzing and building packets using any .NET language such as C# and VB.NET (more info).
It is the library used by Wireshark and it is for sure that it can capture and analyze.
socket() returns a file descriptor if this is what you are referring to as a socket ID then the ways to get this without the process's collaboration on windows are limited. FWIW on linux open FDs are enumerated in the proc filesystem.
That being said, the only thing you would be able to do with the fd is send additional information from the socket. You could also read from the fd, but any data read in this way would not be sent to the application that owns the socket. Without some coordination, that would probably not be what you desire as you would just get bits and pieces of data.
If just want to be able to listen in on the traffic in your program, then something like packet filtering should be sufficient so I assume you actually want to be able to be like a man in the middle for it.
If this is the case, then the best thing to do would actually be to set your application up as a proxy for your other service.
By this I mean, write a program that opens a listening port and accepts connections when a connection is initiated, it should immediately open its own connection to a pre-configured IP:port combination and begin forwarding traffic. Once this is written it's a simple matter to inspect the traffic before forwarding and possibly modify it.
If your program is a server, run it on a non-standard port, configure this application to open the server's normal port and then forward connections to the non-standard port you set up on localhost.
If your program is a client, simply point the interceptor application at the server and choose a random listen port on your box. Then configure the client to connect to this listen port as though it were the server.
This should work for pretty much anything. The only caveat is if the traffic is encrypted you will (obviously) not be able to inspect/modify it. This is effectively the same as placing your application behind a NAT.
I would like to track messages sent and received though Windows Live Messenger. I would then like to collate these messages into a database (not in the scope of this question).
The question is how and where should I track these messages. The simplest way it to force all clients to keep history files and read those, but it is not really the solution that I am looking for. Is there a way to track them from a server running in the same domain, I have read a little into Windows Communicator, I have also seen a lot of people chat about http://dev.live.com/messenger/ but I was hoping that someone may have addressed this problem already :)
I would like to do this using C# .NET 3.5
Check out MSNPSharp. Its a .NET msn library. Its very powerful and allows you to sign in from multiple locations. So you can sign in and listen to other conversations happening on a given account.
Its very straight forward to use. Download the full source code, there's a sample application that demonstrates its use in full detail.
http://code.google.com/p/msnp-sharp/
Here is two idea that might work.
The first one is the easiest but can be easily avoided by the user if he doesn't want to be logged. It would be to use MSN Plus over the MSN. With MSN Plus you have an API that let you get all messages from any Chat Windows... and a lot more. Of course, if the user is not you, the user can simply uninstall Msn Plus and your program will not log any data.
The second idea is better if you have a network that you require to check all Msn Conversation. If you use WireShark you can see that conversation are not crypted (well the last time I did it) and you can check the port and protocol to simply get the data from the network.
Hope it gives you a way to what you need.
Just two ideas
1. First the standard MSN protocol is plain text (from what I understand) so you could intercept the messages on the firewall and then put them in the DB and do the correlation there.
2. If this is in an organisation you could use Office Communicator which is the "corporate" version of MSN and has that functionality built in already. You can then just go in via their SDK and get the correlated data.
I managed to find two ways of doing this, though both are not really programmatic solutions, so may not appeal to this audience.
Make use of a Jabber gateway to set up forwards between your jabber client and the other IM networks. Traffic flows between your jabber enabled client and the jabber server via the jabber server. The Jabber server then translates this to the destination networks protocol and forwards the message. Likewise messages from the external IM networks are routed and translated by the Jabber server. An example of this is PSI <-> IceWarp Merak <-> MSN
Make use of Symantec IM Manager to intercept messages from the messaging clients on your network. You will need to either use host files or local DNS rules to convince the your local PCs that Messenger.hotmail.com is actually located at 192.168.0.59 and not at Microsoft.
Hope it helps other people that may want to do the same.
I hope someone can guide me as I'm stuck... I need to write an emergency broadcast system that notifies workstations of an emergency and pops up a little message at the bottom of the user's screen. This seems simple enough but there are about 4000 workstations over multiple subnets. The system needs to be almost realtime, lightweight and easy to deploy as a windows service.
The problem started when I discovered that the routers do not forward UDP broadcast packets x.x.x.255. Later I made a simple test hook in VB6 to catch net send messages but even those didn't pass the routers. I also wrote a simple packet sniffer to filter packets only to find that the network packets never reached the intended destination.
Then I took a look and explored using MSMQ over HTTP, but this required IIS to be installed on the target workstation. Since there are so many workstations it would be a major security concern.
Right now I've finished a web service with asynchronous callback that sends an event to subscribers. It works perfectly on a small scale but once there are more than 15 subscribers performance degrades considerably. Polling a server isn't really an option because of the load it will generate on the server (plus I've tried it too)
I need your help to guide me as to what technology to use. has anyone used the comet way with so many clients or should I look at WCF?
I'm using Visual C# 2005. Please help me out of this predicament.
Thanks
Consider using WCF callbacks mechanism and events. There is good introduction by Juval Lowy.
Another pattern is to implement blocking web-service calls. This is how GMail chat works, for example. However, you will have to deal with sessions and timeouts here. It works when clients are behind NATs and Firewalls and not reachable directly. But it may be too complicated for simple alert within intranet.
This is exactly what Multicast was designed for.
A normal network broadcast (by definition) stays on the local subnet, and will not be forwarded through routers.
Multicast transmissions on the other hand can have various scopes, ranging from subnet local, through site local, even to global. All you need is for the various routers connecting your subnets together to be multicast aware.
This problem i think is best solved with socket.
Open a connection to the server, and keep it open.
Could you have a slave server in each subnet that was responsible for distributing the messages to all the clients in the subnet?
Then you could have just the slaves attached to the central server where the messages are initiated.
I think some of you are vastly overthinking this. There is already a service built into every version of Windows that provides this exact functionality! It is called the Messenger service. All you have to do is ensure that this service is enabled and running on all clients.
(Although you didn't specify in the question, I'm assuming from your choices of technology that the client population of this network is all Windows).
You can send messages using this facility from the command line using something like this:
NET SEND computername "This is a test message"
The NET SEND command also has options to send by Windows domain, or to specific users by name regardless of where they are logged in, or to every system that is connected to a particular Windows server. Those options should let you easily avoid the subnet issue, particularly if you use domain-based security on your network. (You may need the "Alerter" service enabled on certain servers if you are sending messages through the server and not directly to the clients).
The programmatic version of this is an API called NetMessageBufferSend() which is pretty straightforward. A quick scan of P/Invoke.net finds a page for this API that supplies not only the definitions you need to call out to the API, but also a C# sample program!
You shouldn't need to write any client-side code at all. Probably the most involved thing will be figuring out the best set of calls to this API that will get complete coverage of the network in your configuration.
ETA: I just noticed that the Messenger service and this API are completely gone in Windows Vista. Very odd of Microsoft to completely remove functionality like this. It appears that this vendor has a compatible replacement for Vista.