I'm searching for 4 days, but can't get it. I built all libraries and integrated it in my custom project, but I don't know what steps should I do to make it work. The only thing that i found with code example\explanation is tech.appear.in/2015/05/25/Getting-started-with-WebRTC-on-iOS , but it is poor and unclear for me, AppRTCDemo source code too. I read about WebRTC for browsers but still can't reproduce it on iOS.
Can anybody explain or provide links to explanation on how to completely build iOS native app using WebRTC API for example p2p ios chat?
Besides the fact that I do not understand code logic provided in demo, I can't understand:
1) What is ICE servers for my iOS app? Should I take care of it? Is it something server side? Should I code and run it myself, or I can use existing Parse background?
2) What is signaling mechanism in iOS app? Is it client side only, or it must be implemented on server side too?
3) And maybe someone can explain step-by-step guide, maybe with some code, how to implement simple iOS p2p chat using WebRTC? For example:
"You have to:
Create ICE/STUN/TURN server on parse core using this =source= and this tutorial =tutorial=.
Create RTCPeerConnection using created ICEServer:
RTCPeerConnectionFactory *pcFactory = [[RTCPeerConnectionFactory alloc] init];
RTCPeerConnection *peerConnection = [pcFactory peerConnectionWithICEServers:kICEServerURL constraints:nil delegate:self];
Create DataChannel using ...
Send signal using ... explained here =link=
Set local and remote descriptions ...
Send Data ... using ...
... " or something similar.
I'm sorry for asking this, but I'm losing my mind trying to figure it out. Thank you!
I am not an expert in webrtc but i will try to explain some of your questions.
1.ICE servers-- NATs and firewalls impose significant problem in setting up IP endpoints. so IETF standards STUN, TURN and ICE were developed to address the NAT traversal problem.
STUN helps connect IP end-points:
discover whether they are behind a NAT/firewall, and if so,
to determine the public IP address and type of the firewall. STUN then uses this information to assist in establishing peer-to-peer IP connectivity.
TURN, which stands for Traversal Using Relay NAT, provides a fallback NAT traversal technique using a media relay server to facilitate media transport between end-points.
ICE is a framework that leverages both STUN and TURN to provide reliable IP set-up and media transport, through a SIP offer/answer model for end-points to exchange multiple candidate IP addresses and ports (such as private addresses and TURN server addresses).
2.Signaling is the process of coordinating communication. This signalling part needs to be implemented by you according to your needs(for ex. if you have sip structure in place then you will have to implement sip signalling). In order for a WebRTC application to set up a 'call', its clients need to exchange information:
Session control messages used to open or close communication.
Error messages.
Media metadata such as codecs and codec settings, bandwidth and media types.
Key data, used to establish secure connections.
Network data, such as a host's IP address and port as seen by the outside world.
Steps
for offerer:
first create the peer connection and pass the ice candidates into it
as parameters.
set event handlers for three events:
onicecandidate-- onicecandidate returns locally generated ICE candidates so you can pass them over other peer(s) i.e. list of ice candidates that are returned by STUN/TURN servers; these ice candidates contains your public ipv4/ipv6 addresses as well as UDP random addresses
onaddstream--onaddstream returns remote stream (microphone and camera of your friend!).
addStream` attaches your local microphone and camera for other peer.
Now create SDP offer by calling setLocalDescription function and set remote SDP by calling setRemoteDescription.
For Answerer:
setRemoteDescription
createAnswer
setLocalDescription
oniceCandidate--On getting locally generated ICE
addiceCandidate--On getting ICE sent by other peer
onaddstream--for remote stream to add
I hope this will make some of your doubts clear.
I came through the process of implementing it few month ago. What I've found was the library was not stable - sometimes it was working sometimes not.
Additionally my iPhone was always becoming hot when I was using it.
I would not suggest using this library and overall WebRTC technology for commercial projects.
This is my implementation, which was working few months ago:
https://github.com/aolszak/WebRTC-iOS
Good luck!
Related
I am building a WebRTC videoconferencing service for iOS and Web. We have so far used tokBox, they deliver the whole package (client API (ios and web) + TURN server. Their solution also takes care of generating tokens and session ID etc. But we want to have our own setup, and a partner has given us a TURN server. But, what do we miss to be able to have a webRTC video conference between iOS and a web client? What service will let us just plug in the TURN server address/credentials and have it work both from a web and iOS client? Are these suitable packages: EasyRTC, SkyLink, AppRTC ? We don't need a lot of features, just 1-1 videocall with no bugs. Which one is best?
at minima you will need a signaling server.
apprtc is a complete application, it is not suitable for what you have.
tokbox is a PaaS, so you could replace it with another PaaS (skylink, forge, ...)
easyrtc gives you the code of a signaling server, but not the infrastructure (load balancing, ...), you can use it if you re ok to host it.
you might want to go for peerJS (open source, both hosted and DIY options) if you really want to do it yourself. Otherwise, just changing PaaS is not making a lot of sense. You have to think about everything you're gonna lose as well (recording, archiving, media server, ...).
If your use case is well defined, you can ping me offline, and i'll point you to additional resources.
You can look to Kurento media server.
You can use the service provided by anyconnect SDK. They provide the leading Peer to Peer connectivity between any two nodes whether browser, desktop or mobile platforms. They also provide STUN,TURN and Signaling (SIP,XMPP) server support. Using their SDK will let you just plug in your server credentials and transfer any type of data.
I have a live video chat application and I use a TURN server which supports STUN/TURN and both UPD/TCP transmission.
Sometimes users can be connected to the network which blocks that much ports and protocols that WebRTC connection just cannot happen (usually those are corporate networks). I would like to check if a WebRTC connection is possible before users try to connect to each other (actually, perform a technical check).
How can I do it? Ideas I have in my head:
Try to download a hosted chunk of data (audio file, for example) via WebRTC - is it possible and would this be enough to make sure both inbound and outbound connections are open?
Use a TURN server as a host to make a connection to and see if it fails (have no idea if I can do it or not)
Use Flash to try to download/upload a chunk of data over specific ports and protocols. May be even using Cirrus. However, I am not sure this test will be accurate from WebRTC prospective.
Any other ideas?
Additional requirement: the checking technique must support Chrome, Opera and Firefox. Preferably also IE/Safari via Temasys plugin.
Edition 1 - gathering ICE candidates is a good idea, however, it is not 100% reliable. Once I checked logs in my application and it actually gathered relay ICE candidates, but video/audio transmission failed. Tested on Apprtc as well and got same results.
The best way to check is to connect with just a data channel first. Your users won't notice. If that works then audio and video are almost guaranteed to work. As a bonus, you can use the data channel for signaling for super-fast connecting when your users are ready.
the typical WebRTC approach to this is to create a peerconnection with STUN and TURN servers, call createOffer and setLocalDescription and watch the candidates gathered. See e.g. http://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/
If you get srflx candidates, your stun server works (i.e. UDP is not blocked). More interesting is whether you get relay candidates. If you do, using TURN as a fallback will work. Quality might suffer if TURN/TCP is used. If you don't get relay candidates... calls are very unlikely to work.
I want to implement a peer-to-peer video chat feature for a web application I am currently developing. After doing my research, I've decided that using webRTC's Javascript APIs is the way to go. The application uses AngularJS in the front end and Ruby on Rails in the back end. The main issue I'm encountering while conceptualizing this application is linking the front end with the backend, and creating and maintaining the connection between user streams.
For the signaling aspect of the network, I want to utilize ActionController::Live and the Ruby gem em-event source to push live messages from the server to users and indicate which of their connections are online. Then, when they are ready to make a connection, they will create a custom room and the URL will be sent to the user that they wish to connect with, creating their offer. Once the user clicks on the link sent to them, they send back their answer. When the user responds, the ICE candidate process will begin for each of the users. Do you think that this is a sufficient signaling channel to set up the PeerConnection? What other major players am I missing?
From the research that I have done about WebRTC's RTCPeerConnection, once the initial connection is set up, and both users have public IP addresses corresponding to their stream, the connection is sustained through RTCPeerConnection, more specifically getPeerConnection(). Am I wrong? Are there other factors that I am not considering?
WebRTC makes the process of creating MediaStreams very simple with their getUserMedia method. Once these streams are created they can be added to the RTCPeerConnection that was established. Both as local and remote streams.
If you have any other suggestions for me, please let me know. I want to create this feature using webRTC, it seems like so much fun
There are certainly many ways to handle the call signaling so I'm not going to comment specifically on your approach. I will say that if you plan on supporting ICE trickling the ICE candidates will start flowing very early in the process so you really need an open signalling channel between your peers almost immediately when trying to connect to a peer.
We developed our solution for WebSphere on top of MQTT which is an open, and very simple pub/sub protocol. You can use any open MQTT broker with the protocol and there are a number of open source components available to make WebRTC development extremely easy including an AngularJS WebRTC module (angular-rtcomm), a core pure JavaScript module and much more. We also released a simple JSON based protocol as part of this open source solution. You can take a look at the signaling protocol. You can also read more details about the overall solution here (www.wasdev.net/webrtc). Here you'll find the base JavaScript libraries as well as a number of open source sample solutions. All of these can be forked on github.
In general you want to build your signaling on a protocol that will allow you to grow over time. It should work well for the web and mobile apps. From our experience it took a lot of time to get all this to work well and our goal was to not only support peer-to-peer calls but to support using media resources like Dialogic's XMS PowerMedia server on the backend for multiway support, record/playback and more. We also needed to support federation via SIP trunking so we wanted to make sure the protocol could be easily translated to SIP signaling while also supporting transcoding between media protocols like VP8 and H.264.
Note that if you're looking to only support peer-to-peer calling between WebRTC clients you can do that with these rtcomm open source components only, including an open MQTT broker and save yourself a ton of time. You can literally get something up and running in a matter of hours. The developer version of the WebSphere Liberty beta with the new rtcomm-1.0 service enabled also includes a built in MQTT broker and supports the open WebRTC signaling protocol linked above. You can use WebSphere for development and deploy a single server of this in production for free. You can also use Ruby on Rails with Liberty as well if you'd like.
Even if you decide not to use Liberty you can use all the open source components along with something like Mosquito (which is an open source MQTT broker) to get a solution off the ground quickly. There are also a number of MQTT clients available for many different programming languages including JavaScript, Java, etc. Check out https://eclipse.org/paho/. If you decide to build you're own signaling protocol you might still find these open source components helpful to see how we approached integration with the WebRTC PeerConnection.
Quite a lot of webpages address this issue but I cannot find a simple (I am a begginer) explanation about how to setup a connection between iOS device and Mac computer. I read things about sockets and service publishing with Bonjour and the Apple documentation but it is quite heavy to understand since there is no tutorial and examples.
Does anyone know how to get the basics to setup a connection and send one file over the network or have a good tutorial to share?
Bonjour provides a way for applications to advertise their services and other applications to discover the advertised services.
The main components of a service are
the address (e.g. 10.0.1.52 in the local domain 10.0.1.1)
the type (e.g. Apple Filling Protocol "_afpovertcp._tcp")
the name (e.g. JustinsMacbookPro.local)
the port (e.g. 5687)
These components provide all of the necessary information for a "browser" to figure out how to network with the other application (e.g. setting up the network sockets).
However, Bonjour does not provide a way to send data. Applications send data to other applications using sockets. If you don't want to directly use sockets then you can use high-level protocols that are built on top of sockets like FTP, HTTP, etc. I recommend giving Beej's Guide to Network Programming a read if you want to learn the basics of sending and receiving data over a network.
I have a software architecture problem.
I have to design an IOS application which will communicate with a Linux application to get the state of a sensor, and to publish an actuator command. The two applications run in a Local network with an Ad-Hoc WiFi connection between the IOS device and the Linux computer.
So I have to synchronize two values between two applications (as described in figure 1). In a Linux/Linux system, I resolve this kind of problem thanks to any publisher / subscriber middleware. But how can I solve this problem in an IOS / Linux world ?
Actually the Linux application embed an asynchronous TCP Server, and the IOS application is an asynchronous TCP client. Both applications communicate through the TCP Socket. I think that this method is a low level method, and I would like to migrate the communication layer to a much higher level Service based communication framework.
After some bibliographic research I found three ways to resolve my problem :
The REST Way :
I can create a RESTful Web Service which modelize the sensor state, and which is able to send command to the actuator. An implementation of a RESTful web service client exists for IOS, that is "RESTKit", and I think I can use Apache/Axis2 on the server side.
The RPC Way :
I can create on my Linux computer a RPC service provider thanks to the libmaia. On the IOS side, I can use xmlrpc (https://github.com/eczarny/xmlrpc). My two programs will communicate thanks to the service described in the figure below.
The ZeroConf way :
I didn't get into detail of this methods, but I suppose I can use Bonjour on the IOS side, and AVAHI on the linux side. And then create custom service like in RPC on both side.
Discussion about these methods :
The REST way doesn't seem to be the good way because : "The REST interface is designed to be efficient for large-grain hypermedia data transfer" (from the Chapter 5 of the Fielding dissertation). My data are very fined grain data, because my command is just a float, and my sensor state too.
I think there is no big difference between the ZeroConf way and the RPC Way. ZeroConf provide "only" the service discovering mechanism, and I don't need this kind of mechanism because my application is a rigid application. Both sides knows which services exists.
So my question are :
Does XML RPC based method are the good choice to solve my problem of variable synchronization between an iPhone and a Computer ?
Does it exist other methods ?
I actually recommend you use "tcp socket + protobuf" for your application.
Socket is very efficient in pushing messages to your ios app and protobuf can save your time to deliver a message instead of character bytes. Your other high level proposal actually introduces more complications...
I can provide no answers; just some things to consider in no particular order.
I am also assuming that your model is that the iOS device polls the server to synchronize state.
It is probably best to stay away from directly using Berkeley sockets on the iOS device. iOS used to have issues with low level sockets not connecting after a period of inactivity. At the very least I would use NSStream or CFStream objects for transport or, if possible, I'd use NSURL, NSURLConnection, NSURLRequest. NSURLConnection's asynchronous data loading capability fits well with iOS' gui update loop.
I think you will have to implement some form of data definition language independent of your implementation method (RES, XML RPC, CORBA, roll your own, etc.)
The data you send and receive over the wire would probably be XML or JSON. If you use XML you would have to write your own XML document handler as iOS implements the NSXMLParser class but not the NSXMLDocument class. I would refer JSON as the JSON parser will return an NSArray or NSDictionary hierarchy of NSObjects containing the unserialized data.
I have worked on a GSOAP implementation that used CFStreams for transport. Each request and response was handled by a request specific class to create request specific objects. Each new request required a new class definition for the returned data. Interactivity was maintained by firing the requests through an NSOperationQueue. Lots of shim here. The primary advantage of this method was that the interface was defined in a wsdl schema (all requests, responses, and data structures were defined in one place.
I have not looked at CORBA on iOS - you would have to tie in C++ libraries to your code and change the transport to use CFStreams Again, lots of shim but the advantage of having the protocol defined in the idl file. Also you would have a single connection to the server instead of making and breaking TCP connections for each request.
My $.02
XML RPC and what you refer to as "RESTful Web Service" will both get the job done. If you can use JSON instead of XML as the payload format, that would simplify things somewhat on the iOS side.
Zeroconf (aka bonjour) can be used in combination with either approach. In your case it would allow the client to locate the server dynamically, as an alternative to hard-coding an URL or other address in the client. Zeroconf doesn't play any role in actual application-level data transfer.
You probably want to avoid having the linux app call the iOS app, since that will complicate the iOS app a lot, plus it will be hard on the battery.
You seem to have cherry picked some existing technologies and seem to be trying to make them fit the problem.
I would like to migrate the communication layer to a much higher level Service based communication framework
Why?
You should be seeking the method which meets your requirements in terms of available resources (should you assume that the client can maintain a consistent connection? how secure does it need to be?) However besides functionality, availability and security, the biggest concern should be how to implement this with the least amount of effort.
I'd be leaning towards the REST aproach because:
I do a lot of web development so that's where my skills lie
it has minimal dependencies
there is well supported code implementing the protocol stack at both ends
it's trivial to replace either end of the connection to test out the implementation
it's trivial to monitor the communications (if they're not encrypted) to test the implementaiton
adding encryption / authentication does not change the data exchange
Regards your citation, no HTTP is probably not the most sensible for SCADA - but then neither is iOS.