Building iOS Native App using WebRTC

Question

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:

1. Create ICE/STUN/TURN server on parse core using this =source= and this tutorial =tutorial=.

2. Create RTCPeerConnection using created ICEServer: RTCPeerConnectionFactory *pcFactory = [[RTCPeerConnectionFactory alloc] init]; RTCPeerConnection *peerConnection = [pcFactory peerConnectionWithICEServers:kICEServerURL constraints:nil delegate:self];

3. Create DataChannel using ...

4. Send signal using ... explained here =link=

5. Set local and remote descriptions ...

6. Send Data ... using ...

7. ... " or something similar.

I'm sorry for asking this, but I'm losing my mind trying to figure it out. Thank you!

Answer 1

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.

  3. 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.