I want to develop an android app which uses push to talk or Voip to communicate between 2 mobile devices using a Wi-Fi connection without using a data or the internet.
Is it possible to develop this?
I am looking for a 'free' Wi-Fi Walkie Talkie but I don't know how to start doing it?
For a very simple, initial version, I'd do the following:
Assign a static IP address on each phone
Record the audio and packetise it into a UDP stream that you'll send to the remote IP address
Repackage again the UDP stream and play the audio.
Microphone ---> Samples ----> UDP (over WiFi) ----> Samples ----> Speaker.
There are plenty of enhancements that you can add over the time:
Device discovery
Signalling separate (SIP or custom messages via TCP or UDP to indicate when to start the audio transmission and negotiate the media channel that will be used).
Support for third party devices (SIP)
Use standard paketization using RTP and encode the audio using G711alaw/G711ulaw...
There are plenty options, but you should start by capturing the audio, and sending it over the network, even make packets of 2 seconds with the incurring delay, but that's a point to start. Then, you should lower the packet length to contain 20ms of audio to avoid delays in the transmission.
Hope this helps.
Related
I know I can send 802.11 custom packets with wifi_send_pkt_freedom, and I'am using it without any problem.
But what about receiving?. Yes, I can enable promiscuos mode, and filter by MAC address. Doing that is perfect for sniffing, but not for communication, because the ESP8266 won't ACK the packets and if I'am not sniffing and my ESP is the only receiver, it will make the transmitter to repeat many times the packet. Yes, I can send it like broadcast or multicast to avoid waiting for the ACK, but I'll missing the ACK/re-send functionality. In short I would like to put the ESP Wifi interface in monitor mode (which is not promiscuos mode)
And yes, I can use ESPNOW, but for my application it wont suit very well my needs.
Thanks!
Román
There are 4 queues in WiFi system for QoS-
1- voice
2- video
3- best effort
4-background
How are these access classes assigned to packet transmitted over wifi ?
Can we differentiate two voice services (say Skype and Whatsapp Video call) to provide different QoS to them (using WMM or WMM-SA) ?
Even though wifi router would have layer 3 protocol information only, is there any way to identify packets based on application ?
I have a basestation (beaglebone running linux) at my home which is connected to multiple cameras. I connect my iPhone iOS9 to the basestation via TCP and the basestation will stream the video of each camera to a specific UDP port. All is well.
I want to be able to see the cameras when I am not connected to the local network. When my phone is connected to LTE, I have the iPhone connecting to the public address of my router via TCP and with port forwarding, all data is forwarded to the basestation. I am connecting and talking just like it was on the local network with the TCP client. All is well.
The problem is when the video is streamed via UDP on a specific port, no different than when on the local network, the basestation has no problem sending the packets, but the iPhone is not receiving anything. I am using GCDASYNCUDPSOCKET and my cellular carrier is Verizon.
I am wondering if this issue is due to Verizon blocking UDP packets? Or possibly there needs to be something else done other than just binding the iPhone UDP socket to a specific port and calling the beginreceiving function. I feel if it works on the local network, it should work on the cellular network.
I have also tried to ping the address of my cellphone from my computer which does not work. I am guessing the reason is because the iPhone has blocked this. It should be no different than pinging the address of google or anything else.
Please give me some insight on the possible issues or work arounds. I don't think I need to port forward the UDP since it is only outgoing and my Netgear router does not limit any outbound traffic (from the router to the iPhone). I was doing all this TCP before trying to send the video via UDP. It is much slower waiting to receive acks for 5 cameras streaming live video. And when it doesn't receive a packet it backs up the buffer and causes more issues. Also I had an issue with the TCP packets combining together so then I had to implement some kind of custom ack which made the delay worse, or add an end of message, but then it slows down on parsing and since I don't know exactly what data is coming it made things more difficult.
UDP is the way to go, just cannot receive the packets at this time. My understanding is a lot of games use UDP and they work on LTE network, so I'm not quite sure what the problem is. Is there special UDP ports that only work with Verizon?
We are working on an iOS application for which we need to learn how VoIP works on 2 devices/machines which are on same local network. When transferring files between 2 Skype users on same network, the file transfer is very fast. So there must be something different when 2 devices are connected which are on same network.
Maybe file sharing is different than VoIP and at least the VoIP part works the same way for users on same network or on different networks. But if its not the case then I would like to know whats the difference between connecting machines on same and different networks via Skype.
Generaly VoIP is based on 3 protocols. SIP, RTP and RTCP.
Try to read some articles about SIP signalisation or SIP messages flow. The two devices within the same network can communicate directly or via SIP proxy. Basically the app has to support at least:
REGISTER
INVITE
CANCEL
BYE
100 Trying
180 Ringing
200 OK
486 Busy here
and few others SIP messages and status codes. Your app has to be able to handle SDP messages where the codec is negotiated - choose some free and open codec such as G.711 or iLBC. Within the SDP header RTP and RTCP port are negotiated as well, try to read something about SDP as well.
As this standard model uses multiple ports, it may cause issues when NAT is implemented, but this is not your case as you are within the same LAN.
Regardin the speed of transfer - if you are within the same network you shall not experience any impairments while calling - voice is transmitted in very small packets (i.e. 273 bytes) sent every 20 ms. If you are on wired 100 Mbit or 1 Gbit network, this shall work flawlessly. When on Wi-Fi some impairments may occur as it is not that much reliable.
Further information can be found here:
http://www.ietf.org/rfc/rfc3261.txt
https://www.rfc-editor.org/rfc/rfc4566.html
http://www.ietf.org/rfc/rfc3550.txt
I hope I answered your question at least a bit, if you have any further questions regarding VoIP feel free to ask.
I'm creating an app that needs to connect to versions of itself running on other devices on the wifi network. The goal is to set up a broadcast / client relationship between one device to the others.
I know that Bonjour is the accepted method to do this, but I'm reticent to do that because it locks me into iOS devices, when I'd like to branch out to others, at least for clients.
If I start a webserver on the broadcaster on a specific port, like 43231 or something, is it acceptable for the client device to get it's own IP and then scan that block range for the broadcaster? Is there anything bad about pinging all the other random devices on the network with a request like that?
As in, Broadcaster is 192.168.1.11. Client is 192.168.1.4. If the client assumes all the devices are in the 192.168.1.* block, can it just iterate up the line from 1-100 or so looking for the broadcaster?
If this method is crazy, what should I do?
You can use SSDP (used by UPnP) or just multicast a message over the network and listen for it at the same time, ignoring the loopback (if you don't want the sender to receive it's own messages).
Maybe it will be better to use Bluetooth Low Energy for broadcasting/discovery? You can send non-connectable advertisement packets on server (with it's IP address) and listen for them on all other devices. Device founds such packet, reads IP address and connects to it via NSURLConnection (or something like that).