WebRTC doesn't work with WIFI connection but works with mobile data.
When launched with a mobile date, an offer and candidates are sent, then when connected, a response and candidates are sent, and everything is connected. But when I give it through wifi, everything goes the same, but the videos do not connect.ICE connection state change: disconnected. What could be the problem?
At the same time, the problem occurs with 2 independent providers in Ukraine. For example, in the USA everything works correctly. Firewall off
ICE failed means there were no candidate pairs discovered via which peers could reach each other.
It could be caused by many different reasons.
Top-1 in my opinion is that you're behind NAT and you're not using turn server that is accessible via ipv4 from public network.
Even if you're not behind NAT it still might be an issue as browsers might restrict ICE candidates discovery. Especially if user hasn't granted access to his mic / camera (it does affects candidates gathering).
You might deploy your own turn server (see coturn), or use a cloud one, for example Xirsys. They also have a free trial.
The other reason might be that the provider is blocking UDP / WebRTC traffic. You can prove it using tcpdump on both sides of connection.
For further reading, here's a great article on how to approach debugging webrtc.
Related
I’m not talking about Reachability.
What I’m talking about is figuring out how to create a network connection from an iOS device across the cellular interface.
Why? Because I have conditions where the device connects to a WiFi access point so it chooses WiFi… but that access point is not internet connected and goes nowhere. I have data which I must make every effort to deliver and it some cases it’s getting lost in the WiFi gateway to purgatory. In both cases of using Reachability and relying on MPTCP, Apple has already given priority to WiFi in the stack.
I know NSURLSessionConfiguration can set allowsCellularAccess to allow cellular access — I’m looking to require cellular for the routing.
Even at the CFNetwork level I’m looking at kCFStreamPropertyConnectionIsCellular for status, kCFStreamPropertyNoCellular to disable cellular.
I can’t find anyway to give preference to the cellular radio. I realize Apple has gone to great lengths to prefer WiFi and I’m going against that — which is why I’m having such difficulty finding an answer to this.
I'd like to keep this up in the Cocoa level, but not opposed to going into Foundation or deeper levels. I would like to avoid trying to parse an interface table (if it's even accessible) to figure out which is the cellular interface.
Has anyone successfully created a network connection across the cellular link despite WiFi appearing to be present?
Is some configuration of Multipath TCP the answer here?
To bind to a particular interface, as far as I'm aware, you'd have to drop all the way down to the raw socket level, and there's no way to provide a custom socket for NSURLSession purposes, so you'd basically be rewriting it from scratch. You should file a bug asking for support for binding an NSURLSession to a source IP.
The behavior you're experiencing is a known problem with iOS and disconnected networks. iOS 9 and later do a better job, but even then, they can be highly problematic; the devices sometimes refuse to talk to the Wi-Fi network, and sometimes refuse to talk to the cellular network. Specifically, it seems to fail spectacularly if either signal is weak. Just this morning, I actually had to force my iPhone (iOS 10) to talk to a disconnected Wi-Fi network by putting it in Airplane mode and enabling only Wi-Fi.
I'm told that you can fix this by configuring the network's DHCP server to not provide a router advertisement; that said, every time I've tried that, the iOS device would just keep asking for an offer repeatedly. Maybe that bug got fixed at some point. If so, it might be worth a shot, but don't expect it to work in older versions of iOS.
Failing that, assuming you don't need to support web browsers in iOS 3 and earlier, you might try eliminating the DHCP server on that Wi-Fi network entirely, and just rely on DNS service discovery with zero-conf IPs. That way, the device won't see a router, and it won't try to send data out that interface except to those link-local IPs.
If that isn't possible for some reason, ordinarily I would suggest using a customized copy of libcurl, except that I doubt this will work in your case, because POSIX networking doesn't wake the cellular hardware.
In iOS 12 and later you can use the Network Framework. Sample code is here.
I have two entities which I would like to be able to start a communication:
Hardware Device Using Atmel ATSAMS70 and WINC1500 Wifi Module
HTML 5 App
The idea to have a HTML 5 app is to be able to communicate easily with most of the commercial devices like: Windows computers, Android Phones, Mac OSX computer and iOS devices. Apart from that, I would avoid working with native code at all.
Currently, they can talk with each other using WebSockets but somehow the IP address of the custom board has to be known from HTML 5 to initiate the communication.
In order to do this, I can think of 3 options:
Using WebRTC I can get the local IP address of the browser and then I could do a scan of the local devices considering a 255.255.255.0 network mask.
Have an external server that the hardware device can send its local address which will be later retrieved by HTML 5.
Using Bonjour or some sort of device discovery service between the board and HTML5.
I could not find a way to achieve #3 but #2 seems feasible to me. #1 is what I am doing now, but WebRTC is currently not supported on iOS.
So, is there any other better possibility to achieve this communication?
You don't mention how the WINC1500 unit is being connected to the network but presumably this is in STA mode (acting as a wifi station rather than becoming a software access point or part of an ad-hoc network) and is being provided with its IP details through an existing access point?
Ordinarily I'd suggest that once connected, the device ought to start indicating its availability on the network via a regular UDP broadcast on a specific port but my (admittedly limited) understanding of WebSockets it is that it creates TCP connections. The only implementation of Bonjour that I've seen uses UDP messaging too, that may be why you've had trouble with your third approach.
Your second approach seems more likely to work well. A server at a known (or discoverable) IP on the local network which allows the Atmel device to register itself (and its IP address) and also allows other applications (your HTML 5 WebSockets applications) to request that connection information to allow them to create the WebSocket TCP connections they need.
I suppose that doesn't really answer your question as to "Is there a better way?", other than to say "Not that I can think of, your second approach looks good to me...". Sorry! Sounds like a very interesting project, overall,
Is there any way to communicate between two devices or application with Browser of other devices without having Server in the middle?
If I explain, actually I want to share data between iPhone application and Browser of Desktop, I tried HTTPServer, & played with WebSocket too, but in these case this server plays an important role in between. So If somehow I exchange data between two peers like IP Address, Port number, Then Is it possible to communicate between those two devices using Wi-fi channel without having Server in Middle?
The Way, Right now I have implemented.
The way, I am looking for.
I recently came across http://www.freedomjs.org/ which is suppose to provide p2p functionality in the browser.
I am trying to do a little experiment and I'm getting pretty odd results that I can't explain. I came to my University with my friend, we both brought our laptops and we connected to the same WiFi. But from some reason, our computers couldn't communicate with each other. For example, I couldn't ping him, and I when I did an ARP Scan to find all the hosts on the LAN I didn't find him. He did the same. He couldn't ping me and he didn't find my laptop when he did an ARP scan. Yet, there were many other devices on the LAN that both of us could ping and that we both found in our ARP scan. The University may be big, but we sat just next to each other.
I know that the WiFi on the university may be complex, but yet I have no explanations of what is happening. We sit next to each other, connect to the same WiFi(same Access Point MAC), we both see many same devices in our LAN, yet we can't see each other. Anyone has any idea of what may be happening? Why can't we see/ping each other while we are on the same LAN?
Thanks! :)
The wireless access point probably has a security setting of "Wireless Isolation Within SSID" turned on. This function does exactly what you describe. It allows all authenticated users to see machines on the LAN, but not other wireless machines on the same access point.
Reconfigure your router and make some settings like this
LAN DHCP=Enable
Wireless Authentication type=WPA-PSK/WPA2-PSK
Encryption=AES
After this setting delete all Wireless network of router listed in your PC. And than connect, It will works. you can ping your both PC together.
Because you are connected to an infrastructure mode access point (99% of APs), in order to send packets to another device your laptop sends the packet to the AP (to the distribution system), and then the AP sends the packet to your friend (from the distribution system). You cannot connect 'directly' to your friend.
The AP can direct whether or not wireless clients can see each other - depending on the manufacturer this can be implemented in many different ways. You could talk to your system administrator about why/how this policy works.
I have got a couple of phones and another couple of PC's connected to a Wifi access point and need to send and receive messages between either of these, I mean anyone can send a message to anyone and receive a message from anyone.
I am willing to write apps on the phones(Symbian OS, S60 platform) or PC(Windows), but what I can't understand is how do I set up a client or server, since any one of these devices could be a client or server.
If I use sockets do I have to script for ServerSockets and also Sockets on each of these devices? Can I use the HTTP protocol?
Alternatively any standard protocol that I could use to implement this?
You would broadcast UDP packets which would arrive at every device on the Wifi network. You would have to invent your own protocol to decide on the identity of each device, since you wouldn't be able to easily infer the IP addresses of your network devices. Without writing an election algorithm you would find it difficult to use a client/server architecture, so just use point-to-point (P2P).
Google for UDP broadcasts and read the relevant RFCs at ietf.org.
It seems like you're looking for pretty typical peer-to-peer communication over IP. I suppose other requirements will dictate which transport you use (HTTP, raw sockets, etc), but yes: Each node will be both a client and a server. You could possibly use MDNS (http://www.multicastdns.org/) to help the nodes find eachother in an ad-hoc manner.