I want to use video call on iOS,I have done R&D for doing this and found Webrtc is option for this.
As i found WebRTC is Peer-To-Peer communication.And it's demo example is contain a server LINK.
So my question is that If WebRTC is peer-to-peer then why this is using server.
WebRTC can be used for multiple tasks, but real-time peer-to-peer audio and video (i.e., multimedia) communications is the primary benefit. In order to communicate with another person (i.e., peer) via a web browser, each person’s web browser must agree to begin communication, know how to locate one another, bypass security and firewall protections, and transmit all multimedia communications in real-time.
One of the biggest challenges associated with browser-based peer-to-peer communications is knowing how to locate and establish a network socket connection with another computer’s web browser in order to bidirectionally transmit multimedia data. The difficulties associated with this may not seem obvious at first, but let me explain further.
When you visit a web site, you typically enter a web address or click a link to view the page. A request is made to a server that responds by providing the web page (HTML, CSS, and JavaScript). The key here is that you make an HTTP request to a known and easily locatable (via DNS) server and get back a response (i.e., the web page).
Now let’s say I wanted to have a video chat with my dear ol’ mom. My mom’s computer is not a web server. Therefore, the problem is how do I make the request and actually receive her audio and video data directly, while also sending my audio and video data directly to her, but without going through an external server?
Got Help From HERE
It would be unsafe for an app to listen to new connections all the time, you usually only want outbound connections in an app, inbound connections are found in server applications.
This is a problem for peer to peer, because if both peers only connect outbound, how will they ever establish a connection? The answer is that all peers connect to a signaling server. When starting a call, the peer signals the server that it wants to call another peer. The server can then let the other peer know that there is an incoming call.
It doesn't end here, there is still no connection, but at least both peers know that there will be one. Both peers will start generating ICE candidates now. Through ICE, peers find a route to establish the connection. Sometimes you can connect peer to peer now, but usually there's at least 1 firewall involved (most of the time it's more). In that case, the protocol tries a STUN server, which 'punches a hole' in the firewall (basically, it opens a port in a safe way). This covers 90% of all peer to peer connections, but there are still some cases where peer to peer connection is just not possible. This is where TURN comes in, it's a relay server that your peers can use to relay data to the other peers. The connection is not peer to peer this way.
Related
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.
I'm making use of the library GCDWebServer(https://github.com/swisspol/GCDWebServer) in a project of mine, that requires me to accept connections originating only from my application's process, for security reasons. I was hoping this is something that the iOS app sandbox would provide out of the box, but that doesn't appear to be the case. The sandbox appears to be enforced for UNIX domain sockets(AF_UNIX), by means of file-system permissions. But for TCP/IP sockets(AF_INET), used by GCDWebServer, there appears to be no sandboxing in place.
I was able to write two sample applications - a client and a server(signed with different developer certificates) and could have them communicate with each other, without any issues.
I was wondering if there was some way of enforcing the same on iOS, essentially spin up a HTTP server on a TCP socket but only accept connections from the same process. I can't make use of UNIX domain sockets, because the client which is going to request the content from the HTTP server is an AVPlayer and it wouldn't know how to connect to my application's UNIX domain socket.
I'm about 99% certain that what you're asking for is impossible. I don't even think it is possible in OS X without writing a network kernel extension (and even then, it would be challenging).
By the time a network request reaches another process, it has passed through the networking stack and has lost any notion of what process originated the connection (unless this has improved fairly recently).
Realistically, the closest you can get is binding to a random port on the localhost interface and tearing it down as soon as your app gets put into the background.
Pedantically, if you managed to somehow convince Apple that you planned to build a VPN, it is theoretically possible to abuse the VPN API in such a way that would let you provide a private network that worked only within your app. It would not, however, ever be allowed in the app store.
But why would you ever want to do this? AVPlayer is more than capable of playing from a file URL.
There are many ways you could do that: you can inspect the incoming request in GCDWebServer and decide if you want to respond to it or return an error.
You could add a secret header other apps wouldn't know about, sign the entire request with a secret key, etc...
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 developing an application which requires connection to the internet. Till now i have been using Wifi and WAP 2 connection UID for Http connection and everything has been working fine. But now the client is telling that he wishes to use direct TCP connection as using WAP2.0 connection costs him a big amount.
I am not having clear understanding about APN settings. I have goggled a bit and appended 'deviceside=true' to the url and then set the APN in the Settings->Advanced Options->TCP/IP. But everytime I run the application, I am getting 'Timed Out' Exception.
My client is using O2 carrier. I googled and found out that APN for 2 are 'mobile.o2.co.uk' and 'wap.o2.co.uk' but using these two also client is not able to make Http connection. Is there any way of free unlimited internet connectivity in third party applications?
I am not having a clear understanding of APN settings so kindly bear with me. I am using OS 4.5
Eargerly waiting for reply.
Welcome to the confusing world of network transports on BlackBerry! You will want to start with the article Connecting your BlackBerry - http and socket connections to the world.
I need to connect to a server where resides an mp3 file and stream it. If I am not using rtsp connection what do u suggest me to use? Can we use rstp in this case?
Is it fine to use a http connection? I used that but it seems to take a long time to actually connect to that server. Can I improve the performance by using any other connection class?
Thanks
HTTP over Wi-Fi, Direct TCP, or WAP2 is the best connection method to use for streaming audio if you want to reduce the number of intermediate proxies and carrier networks. Transports such as BES and BIS go through third-party infrastructure (enterprise in the base of BES and RIM in the base of BIS), which adds another point of failure in the path. Not only that, but I have asked RIM employees directly what their thoughts were on streaming media over BIS and their short but sweet response is "don't". They don't want the extra traffic going over their network. I have heard from the BlackBerry forums that large HTTP transfers aren't very reliable over BIS, anyways. In a similar way, BES admins probably don't like apps that try to stream a lot of media through their servers as well.
That leaves Wi-Fi, WAP2 and Direct TCP. Wi-Fi is a no-brainer for devices that have it (and users who are connected) but remember most CDMA devices don't have Wi-Fi so only a small percentage of users may have it. WAP2 is nice in that it doesn't require manual "APN" configuration, however in my experience not all carriers are set up for WAP2. So you may want to try that first and if it doesn't work (i.e. no WAP2 service records or connections over WAP2 fail), use Direct TCP.