For a school project, I need to make an eavesdropping experiment between a SIP user agent and a SIP server. The experiment has to include the following steps:
i)Establish a voice/data communication between two SIP agent.
ii) Capture the signal (i.e. SIP packets) in wireshark.
iii) Change the content of the signal via wireshark or some
other tool that fits better to this purpose.
iv) Encrypting/securing the communication between the agents somehow
to avoid third parties (e.g. wireshark to eavesdrop the communication)
from eavesdropping.
Could you please tell me if there are tools for simulating the above scenario? I prefer to do this programmatically actually and I know there is an open source SIP stack named resip (resiprocate.org) which provides an example user agent and server already in C++. Can I simulate this scenario programmatically or it's better to use some tools that can do this?
There are bunch of possibilities you can check/use for your project purposes.
i)Establish a voice/data communication between two SIP agent
The best way will be to use some already made solution (like e.g. some soft SIP phones).
iii) Change the content of the signal via wireshark or some other
tool that fits better to this purpose.
I think that it is not possible to change traffic using wireshark at all. This is only packet sniffer so you can grab the packets without any modifications of it. You will need some tool that will be able to read and modify packets payload (look at some open source IPS code for some hints).
iv) Encrypting/securing the communication between the agents somehow
to avoid third parties (e.g. wireshark to eavesdrop the communication)
from eavesdropping.
The easiest way will be to establish some tunnel (e.g. VPN) between client and server. This will encrypt and secure the communication.
A sip proxy would be able to capture, manipulate/modify sip packets as well as implement SSL encryption if setup correctly. Generally these servers sit in between 2 sip UA's. Some popular sip proxies are
https://www.kamailio.org/
https://www.opensips.org
Related
I have an application for linux. I am using SocketCAN to talk to the CAN bus. We are doing this on a Beaglebone Black based device we made ourselves.
We have another device we need to listen to traffic from. This device sends a ton of data way faster than we need it or can process it.
I am trying to figure out a good way to slow down the traffic coming from this device to ours over CAN.
I found the document that talks about using traffic control (tc) for linux. I have been trying the examples and not seeing any difference in the incoming traffic.
Everything I have read about this gives examples about limiting the OUTBOUND traffic from an app to the CAN bus.
My question is whether traffic control (tc) can be used to limit incoming traffic to the kernel (and the apps that are listening)?
If not, then is there another tool that can be used for this?
I am ok dropping a percentage of packets. I assume that would have to happen.
I'm trying to set up a half-duplex VoIP communication system. One client is walkie-talkie like radio, the other is a Linux system. My initial attempt was to use Twinkle, but after sniffing the network line through Wireshark, I found out that Twinkle is still sending out packets even if I mute it. The system only allows for half-duplex communication, so the Linux client is hogging the channel.
Is there a way I can either hodgepodge half-duplex on the Linux client or is there a VoIP client with G.711 u-law and PTT that only sends things out when keyed in? I did a search, but I couldn't find anything that had both.
EDIT: I wanted to add I did make a hack of two scripts that blocks all traffic going to the server and unblocks it, but I don't find this solution elegant at all.
I need a SIP server, hopefully simpler, more efficient and more secure than Asterisk or other full-featured PBX, to just terminate SIP calls and play audio, based on the incoming number. This would be in a linux environment.
I'm concerned about long-term support, and much-reduced attack surface. I'm a programmer but a no0b in the SIP world. I want to avoid the tons of security hassles of a full-featured PBX, let alone the crazy big bills after a hacker gets into it. Thanks in advance!
Personally I would build one with pjsip. Assuming you do not need built in registration server all calls would be handled by so called local account. You can use command-line pjsua with auto-answer and auto-play options for initial tests and then add some logic for audio wave selection and perhaps audio player allocation/deallocation (audio players could be active all the time and shared by multiple calls for efficiency if they e.g. contain something like background music).
For security disable not needed parts (TCP, TLS transports, not needed codecs?) and use port other than 5060. In my application I'm also using kind of application-level firewall that blocks requests from hosts that generate suspicious traffic (registrations, malformed SIP requests).
I'm looking to write my own multiplayer game server (most likely in nodejs) and I was wondering what protocol I should be using to transfer data? Are Datagrams the norm to send information (i realize they don't confirm delivery like HTTP, that can written on top of the protocol)? Any suggestions of performant proven systems would be a real help.
I guess I'm looking for successful techniques in handling the data transfer quickly and effectively (maintaining state on the server and scaling are a separate issue that I have a solid understanding of).
I'm looking to initially support desktop/mobile games (MacOS, iOS, and Android).
For all your protocol needs take a look at socketIO.
Basically your best solution is to rely on websockets which are TCP sockets. socketIO is just a nice cross-browser compliant abstraction.
Either you use standard long pulling techniques or html5 websockets. There is no access to UDP for browser <-> server.
There is a technology that is called RTMFP that Adobe introduced in the latest version of Flash (Flash 10). It allows you to do P2P connection and transfer data directly from a client to an other client without passing by the server. On top of that, it's using UDP to transfer data. I believe that this was originally designed to do video and audio streaming, but you can use it to pass data around.
However the main downside on this technology is the mobile since most of them don't support Flash. In this case you can use Socket.IO and use the server as a router of information as a fallback.
If you want to build your application in Javascript, you can still use it by bridging the functionnality to Javascript. If you want to take a look at a simple version of a bridge, you can take a look at this github project (I am the author).
As a C++ developer of Massive Multiplayer games for 10 years, I can tell you that most of your more advanced games, such as ones in which I was involved (Legends Of Kesmai, Magic: The Gathering Online, Airwarrior II, AVP, NTN Triva) to name a few, TCP is used for most communication simply because you need an ACK / NACK to be sure the data was received from the client. That is not to say UDP doesn't have it's place. In Legends we wrote the the protocol code to use UDP for out of bandwidth delivery of data which wasn't imperative that it be received in proper packet order and complete. Use UDP when you want to do things like update graphic files in the background while the user is playing, etc. This type of delivery is often used for such purposes and allows your TCP packets to arrive as required by your server.
I have an application where I have about 10,000 pieces of monitoring equipment across the US that periodically dials into a bank of 32 phone lines. I have two receivers of 16 lines each that answer the call and temporarily stores a small alpha string. I then have a computer that polls the receivers and parses the string and copies it to a database.
I am looking to replace the phone lines and the receivers with a voip solution and rewrite the software to parse the data string.
Any ideas on where to get started?
Tom's suggestion about Asterisk is a good one for the overall system.
However you will still need to decode the data sent from your remote equipment from an audio signal to a data signal. That task is what the "dem" part of Modem stands for (Modulate/Demodulate). Either you do this with a canned hardware/software package (as you are currently doing with a commercial modem) or you have to emulate the modem in software yourself which will be extremely tricky to code at the very least if you attempt it yourself (heaps of standards that you have to comply with for a general modem solution, plus the solution needs to work in real time)
For the software approach could start with this page Linmodems.org (just a something I saw on google prompted by your question). Alternatively do lots of searches on google for software modems. Getting someone else's code is the best approach for this sort of code :)
Whatever you end up doing I suspect it will be rather custom.
A good place to start is probably Asterisk PBX.
I take it you don't want to replace the modems at the client sites (the easiest thing on the server side would be each clients had its own IP software stack, and used its modem to call an ISP and establish an internet connection, and then talk to your server using TCP or UDP or HTTP or whatever).
Assuming that you don't have IP capability on the client sites, Googling suggests that the relevent technology is called "Modem over IP" or "MoIP" (which Wikipedia seems to be confusing with "Mobile over IP").
VoIP consists of SIP for signalling (e.g. for call set-up and call tear-down) plus some codecs (e.g. H.323) for traffic (encoded voice) while the call is established.
I'm guessing that MoIP can keep the SIP signalling, but needs to use some different codecs.
V.150 Modem over IP White Paper looks like an introduction to the technologies. I don't know what vendors there are.
I presume you are looking to find a way to do this without mofidying the modem hardware at your remote sites. If this is the case you will have to find or write signal processing software to demodulate the encoded signal from the modem. Fortunately, signal encodings on a modem are designed to be easy to do this with.
Maybe somebody makes software modem libaries that do this sort of thing. The other parts of the problem will be emulating the handshaking on the modem so it plays nicely with the remote sites.
If you can modify the software (really just the number to dial, but it would have to include the data you want to transfer) at the 10000 sites (not likely!), you could in theory use DTMF in the "dial" string to key the data over into Asterisk. Ok, more than a bit hackey, but it would avoid having to have a software modem. Note: you'd want a checksum!! (and maybe send it multiple times) And a way to tell the caller if it was received correctly. Like I said, hackey but cute.