Q:

WebRTC integration in iOS With OWN Server

is it possible to integrate the WebRTC concept in iOS application with out use third party API in our own server URL. If it is possible then tell me how we are configure the connection,by using Backend API or can we configure it from our Application itself.
Our Web team already integrated it for browser(by using Java Script) and now we are trying to integrate the concept in to iOS.

A:

You can make your own signaling server to allow clients to negotiate a call with each other. How you want to do this is up to you, but we use node.js for this. Our apps connect to our node.js server through a TCP socket.  
When our app makes a call it sends a create signal to our signaling server. The server then sends a voip push to the callee (when a user logs in, the app registers for voip push notifications and sends it's device id to the signaling server). The callee connects to the server and the clients can start sending the offer and answer SDP and the ICE candidates.  
This is the class we use for the WebRTC part of the call <Link removed>. You can drop those files in your project and extend a viewcontroller on it and implement the delegation. For signaling you will have to design your own system, but any decent programmer should be able to create a simple signaling server.  
To add the library to your project I recommend cocoapods. Then use this to add the library:  
target 'your_project_here' do
  pod 'libjingle_peerconnection'
  post_install do |installer_representation|
    installer_representation.pods_project.targets.each do |target|
      target.build_configurations.each do |config|
        config.build_settings['ONLY_ACTIVE_ARCH'] = 'NO'
        config.build_settings['VALID_ARCHS'] = ['armv7', 'arm64']
      end
    end
  end
end

Or you can follow the guide provided to compile the library yourself.
You can read more about using WebRTC natively here. The diagrams show the order in which you have to implement your signals. It's not that hard, when client A calls client B, basically you do:  

A creates the peerconnection factory  
A creates a peerconnection  
A creates a local media stream  
A creates an offer SDP  
A sets the offer as a local SDP  
A starts generating ICE candidates  
A sends ICE candidates to B as they come *  
A sends the offer to B *  
B creates the peerconnection factory  
B creates a peerconnection  
B sets the offer as a remote SDP  
B creates a local media stream  
B creates an answer SDP  
B sets the answer as a local SDP  
B starts generating ICE candidates  
B sends ICE candidates to A as they come *  
B sends the answer to A *  
A sets the answer as a remote SDP  

* If you use the class I linked, you only have to worry about these points  
Note that this class is just a starting point, it doesn't allow for multi-user calls (just 2 peers) and doesn't have much features.

