Recently, I have tried to gain a better understanding of VOIP. I have a good enough understanding of what the phone does in terms of converting audio signals to UDP packets and I develop embedded firmware for a living so I'm no stranger to internet protocols or data formats. My question is: how does a VOIP server go about delivering that audio information to say a land line or wireless carrier? Is there some kind of DNS for phone numbers that gives you an IP address of a server where you can send the data? if so, what is the name of the protocol that is used to determine that information, and the protocol for transmitting the audio data once you know where to send it. I've tried to search for the information, but of course my searches are all swamped with irrelevant results. Also, where can I find documentation for implementing these protocols?
The most popular protocol for this is SIP/RTP (SIP for signaling and RTP for media).
You will need a SIP server (softswitch) to handle this.
To be able to route the calls to landline or mobile numbers, you will have to "interconnect" with carriers from your softswitch. Then you will just send the traffic to their server (the address what they told) again with SIP/RTP since most carriers have SIP support. Alternatively you can send the traffic to traditional PSTN (you will need a hardware for this: either a dedicated gateway or just a PCI slot in your softswitch).
Related
I'd like to implement a simple video chat system for students to tutor each other. I'm a one man show, and would like a system I can run in a cost effective way starting with 10 users, and hopefully scale up as needed.
WebRTC seems like a great, low latency, and cheap option to build this feature. However, if clients are communicating, then they must know each other's public IP. Is this a significant privacy or security issue?
What is the worst case scenario of somebody getting my IP address? Wouldn't any malicious actor have to get through my ISP to get my specific location?
Thanks!
If you host it yourself, WebRTC can be extremely cost-effective. I've been running the SFU at galene.org (disclaimer: I'm the main developer), which is used for multiple lectures with up to a hundred students. Even though this is a full-fledged SFU (and not a mere TURN server), hosting amounts to just over €6/month.
If your tutoring sessions involve just two or three people, then peer-to-peer WebRTC might be enough, but even then a TURN server will be required, especially if some of your users are on university networks. For larger groups, you will need to push your traffic through an SFU.
If you do peer-to-peer WebRTC, then any user can learn the IP of any user they are communicating with; this is most probably not an issue, since the IP addresses are most probably already being disclosed (e.g. in mail headers). If you go though an SFU, then the IP addresses are not deliberately disclosed, but they might still leak; for example, the SFU implementation mentioned above (Galene) discloses IP addresses when a user initiates a file transfer since file transfers happen directly between clients, in a peer-to-peer fashion. (It may be possible to avoid this disclosure by setting the iceTransportPolicy field to relay in the PeerConnection constructor, but I haven't tested how effective it is.)
WebRTC doesn't have to be P2P. You could run a SFU. Each user will upload their video to your server, and the server will distribute via WebRTC. Then the users will never know each others IPs.
I don't have any exact numbers, but it isn't expensive either. Your biggest expense will probably be bandwidth. Lots of Open Source SFUs exist, this is a good list to get started.
Is it possible to use the free GPS service to send other types of data such as plain text/XML/HTML??
E.G. systems for taxi companies - each car has in it a box which receives and sends information to and from the controller/ dispatch, back in the office. The driver can view all bookings and accept them, as well as tell the controller when the customer has been picked up and when they have been dropped off.
Is this all possible via the free GPS service? Or would the system's manufacturer have to pay to to rent a private satellite? Or would the system be using something similar to a mobile phone network? I would think it would be one of the first to options, as constant reliable signal is vital.
I know the question above is pretty open, and it's not what I'm too desperate to have answered...I just want to know if it is possible for me to build a device with a GPS receiver and have it send text and XML via the free GPS service?? (I want an admin to operate a team of employees from a browser, like with a taxi fleet management system).
No, GPS is a chip with an antenna that can receive only Location data.
It is not possible to send data via GPS.
All that devices that drivers, taxies, busses, tolling system use, send their data via mobile phone network.
So a device needs such a communication chip and a sim card.
Then you can send what you want.
I am working on a product which requires a real time gps tracking.
I searched on google to collect information, so I got an overview on how does basically GPS work.
Now what else do I need except for a GPS receiver to display on my mobile through an app (designed by us) where a GPS receiver is attached to my product?
I don't want the whole navigation functionality, but just to display where it is located.
I know a GPS receiver continuously sends and receives signals from satellites, but how to display that on my mobile app?
Do we send some info to some kind to a database and then program the app to collect the info from there?
Basically, You need a kind of connection between your receiver and your phone. Since all the phones have their own gps receiver, I assume that you are gonna track the location of a remote device. So the easiest way to do that is creating a basic web service which holds just 2 pages in total.
1 to update data by receiver (I suggest you to use a hash key to prevent bots to piss your database)
1 to get data to mobile app
Depending on your background and project needs you can either use a database to keep location data or you can use just a file (like xml file or something like that)
Also you will need to parse NMEA code to get the actual data. It is easier to do that on web side (like in php). So you can just pass the NMEA code as it is to server, parse it, record it to database/file. Then you can fetch the data from your mobile app by using simple http requests.
If two devices will be close to each other you can easily use bluetooth but I don't know if there is any case that it make sense to place an additional gps receiver just next to a smart phone :)
First of all, you need some kind of communication channel to send location from your product to a server (1) of directly to the phone (2).
Usually GPS tracking devices use GSM modem with GPRS to connection to a remote server. Then your phone app can request location data from server via HTTP API. You can use open source GPS tracking server for your project and use some simple protocol to send location data to it.
Second popular option requires GSM modem again, but in this case device can send SMS messages directly to your phone. In your app you can intercept SMS and retrieve location data.
I am not a professional developer but I want to develop one project that includes sending message through mobile connected through USB port only... And if possible I want to keep it generalized, like no need for handset model and service provider name.
I don't think it's possible to do this. Certainly at the very least it would depend on the model of mobile in use.
However as an alternative approach there are companies that provide a (paid for, but not expensive) SMS service accessible via a web API. This may suit what you are trying to achieve.
I don't think you will find this easy. Messages can be sent in 2 different modes 'text' or PDU. Support for both modes is not universal across all phones. PDU is the most widely available type on modern phones, but is also the most complex. Not all mobile phones expose a modem to the computer eg. Windows mobile 6.*. Many phones use proprietory software that does not support all commands. Different phones will connect to different COM ports so this will need checking every time, and could prove tricky if there is more than one phone/modem connected. However using just one phone and sending messages in text format after configuring the settings manually the first time is very easy.
See an example here http://www.codeproject.com/Articles/34360/vb-net-AT-commands-to-send-SMS
Well, I tried to ask this question as a comment on this question, but I thought that maybe no one will notice it, so I decided to ask it as a separate one.
The question is about how to do real-time GPS tracking system things; if we have the following scenario:
Rather than connecting a GPS receiver to a PC, the user will have a mobile device with an integrated GPS receiver.
Location data will be sent over mobile network using GPRS data connection to a server side.
The data will be processed and a KML path file will be created and updated on time intervals and used to track the user using Google Earth.
The question is: what is the best method to accomplish this scenario for the server side; is it a web service, a web application, a windows service, a windows application or what exactly? Taking into account that the system will serve a number of users simultaneously, and that more users may use the system in the future(scalability issues).
Thank you in advance and I highly appreciate any help :)
What kind of device are you using exactly, something like this or something more sophisticated / configurable? If we assume that the device sends its data over TCP, I would consider the following approach with separate input/output processes:
Input: a process listening specific TCP port and storing incoming coordinates to database with a device id. Preferably, your listening loop must be able to handle simultaneous connections without them blocking each other.
Output: web application reading coordinates from database for a given device id and displaying them through the Google Earth API.
Use whatever programming language(s) you are familiar with.
For me there is a technical limitation/risk here -> the mobile device, and its connectivity.
1) What are your requirements? Do you need to support various mobile devices or will you focus on only one platform ?
2) More importantly, you have to understand that GPRS data connections differ from a PC connected to the Internet. There are various connection restrictions imposed by different mobile operators.
If I was to design such a system in order to minimise those risks I would go with a web server running on port 80 which the mobile devices would upload their Long/Lat through POST (or even GET to simplify things).
EDIT: Regarding scalability, it would be very easy to scale things up in the future using tried&tested load-balancing techniques.
EDIT2: Whichever technology you decide to use, i would HIGHLY recommend that the first thing you do is to mock up a prototype. Those connection restrictions could be show-stoppers. Ideally you need to explore them before you have made any serious investment.