Month: March 2015

Remote machine control via Raspberry pi

What is a Raspberry pi ?

The Raspberry Pi is a series of credit card-sized single-board computers. It can be used to build hardware along with software system . It essentially acts like a mini computer where we can install our programs and work on them pretty much like a regular computer . However the applications of Rpi is really diversifies from making robots to kiosks , surveillance system to remote control agents etc .

Yes the new model B+ is out yet I have an old B model and I am trying ot most of the things using it before making the investment of purchasing a  new one .

2 3(images from : http://www.adafruit.com/products/998)

Configuration :

  • The design is based around a Broadcom BCM2835 SoC, which includes an ARM1176JZF-S 700 MHz processor, VideoCore IV GPU, and 512 Megabytes of RAM.
  • The design does not include a built-in hard disk or solid-state drive, instead relying on an SD card for booting and long-term storage.
  • This board is intended to run Linux kernel based operating systems.
  • Generic USB keyboards and mice are compatible with it .
  • It does not come with a real-time clock, so an OS must use a network time server, or ask the user for time information at boot time to get access to time and date info for file time and date stamping. However a real time clock (such as the DS1307) with battery backup can be easily added via the I2C interface.

Physical architecture :

rpib

Pin Model :

p1header

Rpi model B startup

Requirements for boot

  1. Power supply
  2. HDMI cable to connect to HDMI tv or HDMI to VGA adapterto connect to monitor
  3. power charger ( micro USB same as phone )
  4. SD card upto 8 GB ( in case its a micro SD card then SD card adpater as well)
  5. monitor
  6. keyboard
  7. mouse
  8. internet through ethernet
  9. ethernet wire

Steps:

top view of the board
top view of the board
HDMI connector for screen display from Rpi
HDMI connector for screen display from Rpi
NOOBS
NOOBS
Raspbian start
Raspbian start
rpi5
rpi6
rpi8
rpi9
Default id : pi default password : raspberry
Default id : pi
default password : raspberry
OS boot up
OS boot up
rpi12
raspbian on Raspberry pi
raspbian on Raspberry pi
run sudo apt-get update
run sudo apt-get update

 RPI model B to LED glow using timers in python

Aim :

First time booting Raspbian on Raspberry pi Model B . Connecting it to LED ( series with resistor ) and controlling the on -off process using timer logic written in python .

Requirements :

  1. Rs(RaspberryPi)
  2. Power supply
  3. Ethernet wire(3m)
  4. SDcard or micro SD card with adpater
  5. Breadboard
  6. LED(7)
  7. resistors(1k )(7)
  8. button
  9. breadboard wires

Steps :

1. Manual ON and OFF of LED on Rpi GPIO

To manually make the LED turn ON and OFF ,  make a serial connection of two GPIO pins with a LED  and resistor ( shown in the picture )

rpi15
  • Open terminal and sudo su  to :/home/pi#
  • #echo25>/sys/class/gpio/export
  • File manager -> /home/pi -> sys -> class ->gpio -> gpiochip0 -> device -> gpio ->gpio25 , Change directory to this location
  • #cd /sys/class/gpio/gpiochip0/device/gpio/gpio25
  • List all files , with gpio#ls

To give output to LED through the pin 25 :

  • echo out>direction ( set this pin as output)
  • To tuen ON the LED , write 1 to the value of pin echo 1> value

To take input through pin 24 through a button

  • connect button to pin 24 of Rpi as earlier
  • echo in >direction
  • see the changes on pressing the button on cat value

2. GPIO control with WiringPi library

  • Install git , sudo apt-get innstall git-core
  • Get the sourcecode with :sudo git clone git://git.drogon.net/wiringpi
  • cd wiringPi
  • ./build
  • $gpio -v
  • $gpio readall

To turn ON or OFF the first LED wiring pin 0 , set the pin as an output  -> gpio mode 0 out

  • To turn ON LED  -> $gpio write 0 1
  • To turn OFF  -> $gpio write 0 0

To read from a digital switch on wiringPin no

  • $ gpio read 0

Applications:

1.  Timer based control

Following are the steps to make and execute a LED  control using timers in python .

 Machine control through RPi via Mobile app on Internet

Aim :

Controlling a machine via Rpi hub connected to internet . Users can control machine behavior through a web page or mobile app .

Steps:

1. Install Raspbian wheezy ( details of installation are provided in the 1fisrt application on this page )

2. Get win32 Disk-manager 0.25 and dump into raspberry

3. Connect the Rpi via Ethernet wire to internet router . Find IP address of Rpi client by checking the router default console .

4. Connect the Rpi to remote machine

For Linux remote machine OS –Install tightVNC server

  • ssh  raspberrypi_username@ipaddress
  • sudo apt-get updates
  • sudo apt-get install tightvncserver
  • During installation supply a username and password example , username pi  , password altanai.

The viewer for VNC could be Remmina VNC viewer on linux

  • Incoming VNC server .
  • Enter username and password

For Windows  remote machine OS –Install putty

  • Enter Rpi_ip:port
  • login as pi given password  for example altanai

5. For the webpage

  • Install a web server  :sudo apt-get install apache2 php5 libapache2-mod-php5
  • transfer the web page for machine control  to Rpi inside /var/www
  • index.phpo :  <?php phpinfo(); ?>
  • ctrl+ o to save , ctrl + x to exit
  • change permission fr user pi :  chown -R pi /var/www
  • test the webpage at http://rpi_address

6. For the android app

7. To control real machine like fan , tubelight , washing machine  , connect the output of Rpi to relay.

8. To control the machines from anywhere on the internet , this page need to be on public DNS . There fore host the website on public server like amazon Ec2 instance .

Light Fan control Rpi web

Ref :

  1. http://www.adafruit.com/products/998
  2. http://www.raspberrypi.org/
  3. http://www.instructables.com/id/Simple-and-intuitive-web-interface-for-your-Raspbe/

TURN server for WebRTC – RFC5766-TURN-Server , Coturn , Xirsys

STUN (Session Traversal Utilities for NAT) and TURN (Traversal Using Relays around NAT) are protocols that can be used to provide NAT traversal for VoIP and WebRTC. These projects provide a VoIP media traffic NAT traversal server and gateway.

TURN Server is a VoIP media traffic NAT traversal server and gateway.

I come accross the question of difference between turn and stun a lot . Here I wanted to specify in very clear words that TURN is an extension of STUN .

rfc5766-turn-server

This is a VoIP gateway for inter network communication which is popular and MIT based .

platforms supported :

Any client platform is supported, including Android, iOS, Linux, OS X, Windows, and Windows Phone. This project can be successfully used on other *NIX platforms ( Aamazon EC2) too. It supports flat file or Database based user management system ( MySQL , postgress , redis ). The source code project contains ,  TURN server ,  TURN client messaging library and some sample scripts to test various modules like protocol , relay , security etc .

Protocols :

protocols between the TURN client and the TURN server – UDP, TCP, TLS, and DTLS. Relay protocol – UDP , TCP .

Authentication

The authentication mechanism is using key which is calculated over the user name, the realm, and the user password. Key for the HMAC depends on whether long-term or short-term credentials are in use. For long-term credentials, the key is 16 bytes:
key = MD5(username “:” realm “:” SASLprep(password))

Installation

Since I used my Ubuntu Software center for installing the RFC turn server 5677 .

Screenshot from 2015-03-05 15:22:30

More information is on Ubuntu Manuals : http://manpages.ubuntu.com/manpages/trusty/man1/turnserver.1.html

The content got stored inside /usr/share/rfc5766-turn-server.

Also install mysql for record keeping

sudo apt-get install mysql-server

mysql

mysql2mysql4

Intall MySQL workbench to monitor the values feed into the turn database server in MysqL. connect to MySQL instance using the following screenshot

mysql5

The database formed with mysql after successful operation is as follows . We  shall notice that the initial db is absolutely null

mysql8empty

Terminal Commands

These terminal command ( binary images ) get stored inside etc/init.d after installing

turnadmin –

Its turn relay administration tool used for generating , updating keys and passwords . For generating a key to get long term crdentaial use -k command and for aading or updateing a long -term user use the -a command. Therefore a simple command to generate a key is

format : turnadmin -k -u -r -p
examples : turnadmin -k -u turnwebrtc -r mycompany.com -p turnwebrtc

The generated key is displayed in console . For example the following screenshot shows this :

rfc5677turnkey

To fill in user with long term credentails

Format : turnadmin -a [-b | -e | -M | -N ] -u -r -p

exmaple : turnadmin -a -M “host=localhost dbname=turn user=turn password=turn” -u altanai -r mycompany.com -p 123456

Check the values reflected in MySQL workbench for long term user table . ( screenshot depicts two entries for altanai and turnwebrtc user )

turnkeylongterm

you can also check it on console using the -l command

format :turnadmin -l –mysql-userdb=””

example :  turnadmin -l –mysql-userdb=”host=127.0.0.1 dbname=turn user=turnwebrtc password=turnwebrtc connect_timeout=30″

longtermuserlcommand

or we can also check using the terminal based mySQL client

mysql> use turn;
Database changed

mysql> select * from turnusers_lt;
+------------+----------------------------------+
| name | hmackey |
+------------+----------------------------------+
| altanai | 57bdc681481c4f7626bffcde292c85e7 |
| turnwebrtc | 6066cbe0b5ee14439b2ddfc177268309 |
+------------+----------------------------------+
2 rows in set (0.00 sec)

turnserver –

Its command to handle the turnserver itself . We can use the simple turnserver command to start it without any db support using just turnserver. Screenshot for this is

turnserverstart

We can use a database like mysql to start it with db connection string

Format : turnserver –mysql-userdb=””

Example : turnserver –mysql-userdb=”host=127.0.0.1 dbname=turn user=turnwebrtc password=turnwebrtc connect_timeout=30″

turnservermysqldb

turnutils_uclient:

emulates multiple UDP,TCP,TLS or DTLS clients.

turnutils_peer:

simple stateless UDP-only “echo” server. For every incoming UDP packet, it simply echoes it back.

turnutils_stunclient:

simple STUN client example that implements RFC 5389 ( using STUN as endpoint to determine the IP address and port allocated to it , keep-alive , check connectivity etc) and RFC 5780 (experimental NAT Behavior Discovery STUN usage) .

turnutils_rfc5769check:

checks the correctness of the STUN/TURN protocol implementation. This program will perform several checks and print the result on the screen. It will exit with 0 status if everything is OK, and with (-1) if there was an error in the protocol implementation.

Specifications :

TURN specifications include :

  • RFC 5766 – base TURN specs
  • RFC 6062 – TCP relaying TURN extension
  • RFC 6156 – IPv6 extension for TURN
  • DTLS
  • Mobile ICE (MICE)

STUN specifications :

  • RFC 3489 – Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs) (STUN) to discover the presence and public IP
  • RFC 5389 – STUN serves as a tool for other protocols in NAT traversal. It can be used by an endpoint to determine the IP address and port allocated to it , keep-alive  , check connectivity etc .
  • RFC 5769 – test vectors for STUN protocol . FINGERPRINT, MESSAGE-INTEGRITY, and XOR-MAPPED-ADDRESS involving binary-logical operations (hashing, xor)
  • RFC 5780 – experimental NAT Behavior Discovery STUN usage

ICE specifications :

  • RFC 5245 – ICE
  • RFC 5768 – ICE–SIP
  • RFC 6336 – ICE–IANA Registry
  • RFC 6544 – ICE–TCP
  • RFC 5928 – TURN Resolution Mechanism

Test :

1. Test vectors from RFC 5769 to double-check that our
STUN/TURN message encoding algorithms work properly. Run the utility to check all protocols :

$ cd examples
$ ./scripts/rfc5769.sh

2. TURN functionality test (bare minimum TURN example).

If everything compiled properly, then the following programs must run
together successfully, simulating TURN network routing in local loopback
networking environment:

console 1 :

$ cd examples
$ ./scripts/basic/relay.sh

console2 :

$ cd examples
$ ./scripts/peer.sh

If the client application produces output and in approximately 22 seconds
prints the jitter, loss and round-trip-delay statistics, then everything is
fine.

Usage

iceServers:[
{ ‘url’: ‘stun: altanai@mycompany.com’},
{ ‘url’: ‘turn: altanai@mycompany.com’, ‘credential’: ‘123456’}]

Insert the above piece of code on peer connection config .

Now call from one network environment to another . For example call from a enterprise network behind a Wifi router to a public internet datacard webrtc agent . The call should connect with video flowing smoothly between the two .

tooltips

website : https://code.google.com/p/rfc5766-turn-server/

Download the executable from : http://turnserver.open-sys.org/downloads/v3.2.5.4/

you can read about setting a carrier grade TURN infrastructure on amazon EC2 here –

coturn

Project Coturn evolved from rfc5766-turn-server project with many new advanced TURN specs beyond the original RFC 5766 document.
Here the databses supported are : SQLite , MySQL , PostgreSQL , Redis , MongoDB

Protocols :

The implementation fully supports the following client-to-TURN-server protocols: UDP  , TCP  , TLS  SSL3/TLS1.0/TLS1.1/TLS1.2; ECDHE , DTLS versions 1.0 and 1.2. Supported relay protocols UDP (per RFC 5766) and TCP (per RFC 6062)

Authetication :

Supported message integrity digest algorithms:

  • HMAC-SHA1, with MD5-hashed keys (as required by STUN and TURN standards)
  • HMAC-SHA256, with SHA256-hashed keys (an extension to the STUN and TURN specs)

Supported TURN authentication mechanisms:

Installation :

Install libopenssl and libevent plus its dev or extra libraries .
OpenSSL has to be installed before libevent2 for TLS beacuse When libevent builds it checks whether OpenSSL has been already installed, and its version.

Download coturn readonly  from

svn checkout http://coturn.googlecode.com/svn/trunk/ coturn-read-only

extract the tar contents
$ tar xvfz turnserver-.tar.gz

go inside the extracted folder and run the following command to build
$ ./configure
$ make
$ make install

Adding users in the format using turnadmin
$ Sudo turnadmin -a -u -r -p

Example
$ Sudo turnadmin -a -u altanai -r myserver.com -p 123456

Start the turn Server using turnserver from inside of /etc/init.d using the start command

$ sudo /etc/init.d/coturn start

Screenshot from 2015-01-06 12-08-15

The logs are usually stored in /var/log . Screenshot of log file

tuenlog2

The default configured port is 3478.If other port is needed, change the file /etc/turnserver.conf

Usuage:

Specify the  values in Peer Connection

Format:
iceServers: [
{ ‘url’: ‘stun: @: ‘},
{ ‘url’: ‘turn: @: ‘, ‘credential’: ”}]

example:

iceServers:[
{ ‘url’: ‘stun: altanai@myserver.com’},
{ ‘url’: ‘turn: altanai@myserver.com’, ‘credential’: ‘123456’}]

Specifications:

TURN specs:

STUN specs:

  • RFC 3489 – STUN – Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)
  • RFC 5389 – Session Traversal Utilities for NAT (STUN)
  • RFC 5769 – test vectors for STUN protocol testing
  • RFC 5780 – NAT behavior discovery support
  • RFC 7443 – Application-Layer Protocol Negotiation (ALPN) Labels for STUN and TURN

ICE :

  • RFC 5245 – ICE
  • RFC 5768 – ICE–SIP
  • RFC 6336 – ICE–IANA Registry
  • RFC 6544 – ICE–TCP
  • RFC 5928 – TURN Resolution Mechanism

website : https://code.google.com/p/coturn/

Xirsys

Xirsys is a provider for WebRTC infrastructure which included stun and turn server hosting as well .

The process of using their services includes singing up for a account and choosing whether you want a paid service capable of handling more calls simultaneously or free one handling only upto 10 concurrent turn connections .

The dashboard appears like this :

xirsys1

To receive the api one need to make a one time call to their service , the result of which contains the keys to invoke the turn services from webrtc script .


&lt;script src=&quot;http://ajax.googleapis.com/ajax/libs/jquery/2.1.0/jquery.min.js&quot;&gt;&lt;/script&gt;&lt;script&gt;// &lt;![CDATA[

$.post(&quot;https://api.xirsys.com/getIceServers&quot;, {
ident: &quot;altanai&quot;,
secret: &quot;&lt; your secret key &gt;&quot;,
domain: &quot; &lt; your doemain &gt;&quot;,
application: &quot;default&quot;,
room: &quot;default&quot;,
secure: 1
},
function(data, status) {
alert(&quot;Data: &quot; + data + &quot;n Status: &quot; + status);
console.log(&quot;Data: &quot; + data + &quot;nnStatus: &quot; + status);
});
});
&lt;/script&gt;

The resulting output should look like ( my keys are hidden with a red rectangle ofcourse )

xirsysedited

The process of adding a TURN / STUN to your webrtc script in JS is as follows :

iceServers:[
{“url”:”stun:turn2.xirsys.com”},
{“username”:”< put your API username>”,”url”:”turn:turn2.xirsys.com:443?transport=udp”,”credential”:”< put your API credentail>”},
{“username”:”< put your API username>”,”url”:”turn:turn2.xirsys.com:443?transport=tcp”,”credential”:”< put your API credentail>”}]

website : http://xirsys.com/technology/

NAT traversal using STUN and TURN

We know that WebRTC is web based real-time communications on browser-based platform using the browser’s media application programming interface (API) and adding our JavaScript & HTML5 t control the media flow .
WebRTC has enabled developers to build apps/ sites / widgets / plugins capable of delivering simultaneous voice/video/data/screen-sharing capability in a peer to peer fashion.

But something which escapes our attention is the way in which media ia traversing across the network. Ofcourse the webrtc call runs very smoothly when both the peers are on open public internet without any restrictions or firewall blocks . But the real problem begins when one of the peer is behind a Corporate/Enterprise network or using a different Internet service provider with some security restrictions . In such a case the normal ICE capability of WebRTC is not enough , what is required is a NAT traversal mechanism .

STUN and TURN server protocols handle session initiations with handshakes between peers in different network environments . In case of a firewall blocking a STUN peer-to-peer connection, the system fallback to a TURN server which provides the necessary traversing mechanism through the NAT.

Lets study from the start ie ICE . What is it and why is it used ?

ICE (Interactive Connectivity Establishment )  framework ( mandatory by WebRTC standards  ) find network interfaces and ports in Offer / Answer Model to exchange network based information with participating communication clients. ICE makes use of the Session Traversal Utilities for NAT (STUN) protocol and its extension, Traversal Using Relay NAT (TURN)

ICE is defined by RFC 5245 – Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols.

Sample WebRTC offer holding ICE candidates :

type: offer, sdp: v=0
o=- 3475901263113717000 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE audio video data
a=msid-semantic: WMS dZdZMFQRNtY3unof7lTZBInzcRRylLakxtvc
m=audio 9 RTP/SAVPF 111 103 104 9 0 8 106 105 13 126
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:/v5dQj/qdvKXthQ2
a=ice-pwd:CvSEjVc1z6cMnhjrLlcbIxWK
a=ice-options:google-ice
a=fingerprint:sha-256 F1:A8:2E:71:4B:4E:FF:08:0F:18:13:1C:86:7B:FE:BA:BD:67:CF:B1:7F:19:87:33:6E:10:5C:17:42:0A:6C:15
a=setup:actpass
a=mid:audio
a=sendrecv
a=rtcp-mux
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:106 CN/32000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:126 telephone-event/8000
a=maxptime:60
m=video 9 RTP/SAVPF 100 116 117 96
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:/v5dQj/qdvKXthQ2
a=ice-pwd:CvSEjVc1z6cMnhjrLlcbIxWK
a=ice-options:google-ice
a=fingerprint:sha-256 F1:A8:2E:71:4B:4E:FF:08:0F:18:13:1C:86:7B:FE:BA:BD:67:CF:B1:7F:19:87:33:6E:10:5C:17:42:0A:6C:15
a=setup:actpass
a=mid:video
a=sendrecv
a=rtcp-mux
a=rtpmap:100 VP8/90000
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli
a=rtcp-fb:100 goog-remb
a=rtpmap:116 red/90000
a=rtpmap:117 ulpfec/90000
a=rtpmap:96 rtx/90000
a=fmtp:96 apt=100
m=application 9 DTLS/SCTP 5000
c=IN IP4 0.0.0.0
a=ice-ufrag:/v5dQj/qdvKXthQ2
a=ice-pwd:CvSEjVc1z6cMnhjrLlcbIxWK
a=ice-options:google-ice
a=fingerprint:sha-256 F1:A8:2E:71:4B:4E:FF:08:0F:18:13:1C:86:7B:FE:BA:BD:67:CF:B1:7F:19:87:33:6E:10:5C:17:42:0A:6C:15
a=setup:actpass
a=mid:data
a=sctpmap:5000 webrtc-datachannel 1024

Notice the ICE candidates under video and audio . Now take a look at the SDP answer

type: answer, sdp: v=0
o=- 6931590438150302967 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE audio video data
a=msid-semantic: WMS R98sfBPNQwC20y9HsDBt4to1hTFeP6S0UnsX
m=audio 1 RTP/SAVPF 111 103 104 0 8 106 105 13 126
c=IN IP4 0.0.0.0
a=rtcp:1 IN IP4 0.0.0.0
a=ice-ufrag:WM/FjMA1ClvNb8xm
a=ice-pwd:8yy1+7x0PoHZCSX2aOVZs2Oq
a=fingerprint:sha-256 7B:9A:A7:43:EC:17:BD:9B:49:E4:23:92:8E:48:E4:8C:9A:BE:85:D4:1D:D7:8B:0E:60:C2:AE:67:77:1D:62:70
a=setup:active
a=mid:audio
a=sendrecv
a=rtcp-mux
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:106 CN/32000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:126 telephone-event/8000
a=maxptime:60
m=video 1 RTP/SAVPF 100 116 117 96
c=IN IP4 0.0.0.0
a=rtcp:1 IN IP4 0.0.0.0
a=ice-ufrag:WM/FjMA1ClvNb8xm
a=ice-pwd:8yy1+7x0PoHZCSX2aOVZs2Oq
a=fingerprint:sha-256 7B:9A:A7:43:EC:17:BD:9B:49:E4:23:92:8E:48:E4:8C:9A:BE:85:D4:1D:D7:8B:0E:60:C2:AE:67:77:1D:62:70
a=setup:active
a=mid:video
a=sendrecv
a=rtcp-mux
a=rtpmap:100 VP8/90000
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli
a=rtcp-fb:100 goog-remb
a=rtpmap:116 red/90000
a=rtpmap:117 ulpfec/90000
a=rtpmap:96 rtx/90000
a=fmtp:96 apt=100
m=application 1 DTLS/SCTP 5000
c=IN IP4 0.0.0.0
b=AS:30
a=ice-ufrag:WM/FjMA1ClvNb8xm
a=ice-pwd:8yy1+7x0PoHZCSX2aOVZs2Oq
a=fingerprint:sha-256 7B:9A:A7:43:EC:17:BD:9B:49:E4:23:92:8E:48:E4:8C:9A:BE:85:D4:1D:D7:8B:0E:60:C2:AE:67:77:1D:62:70
a=setup:active
a=mid:data
a=sctpmap:5000 webrtc-datachannel 1024

Call Flow for ICE

STUN call flow for WebRTC Offer Answer
STUN call flow for WebRTC Offer Answer

WebRTC needs SDP Offer to be send to the clientB Javascript code from clientA Javascript code . Client B uses this SDP offer to generate an SDP Answer for client A. The SDP ( as seen on chrome://webrtc-internals/ ) includes ICE candidates which punchs open ports in the firewalls.
However incase both sides are symmetric NATs the media flow gets blocked. For such a case TURN is used which tries to give a public ip and port mapped to internal ip and port so as to provide an alternative routing mechanism like a packet-mirror. It can open a DTLS connection and use it to key the SRTP-DTLS media streams, and to send DataChannels over DTLS.

In order to Understand this better consider various scenarios

1 . No Firewall present on either peer . Both connected to open public internet .

Diagrammatic representation of  this shown as follows :

WebRTC signalling and media flow on Open public network
WebRTC signalling and media flow on Open public network

In this case there is no restriction to signal or media flow and the call takes places smoothly in p2p fashion.

2.  Either one or both the peer ( could be many in case of multi conf call ) are present behind a firewall  or  restrictive connection or router configured for intranet .

In such a case the signal may pass with the use of default ICE candidates or simple ppensource google Stun server such as

iceServers:[
{ ‘url’: “stun:stun.l.google.com:19302”}]

Diagram :

WebRTC signalling when peers are behind firewalls
WebRTC signalling when peers are behind firewalls

However the media is restricted resulting in a black / empty / no video situation for both peers  . To combat such situation a relay mechanism such as TURN is required which essentially maps public ip to private ips thus creating a alternative route for media and data to flow through .

WebRTC media flow when peers are behind NAT . Uses TURN relay mechanism
WebRTC media flow when peers are behind NAT . Uses TURN relay mechanism

Peer config should look like :

var configuration =  {
iceServers: [
{ “url’:”stun::”},
{ “url”:”turn::”}
]
};

var pc = new RTCPeerConnection(configuration);

3. When the TURN server is also behind a firewall .  The config file of the turn server need to be altered to map the public and private IP

The diagrammatic description of this is as follows :

WebRTC media flow when peers are behind NAT and TURN server is behind NAT as well . TURN config files bind a public interface to private interface address.
WebRTC media flow when peers are behind NAT and TURN server is behind NAT as well . TURN config files bind a public interface to private interface address .