Creating first WebRTC application - WebRTC overview

Below are the expectations from WebRTC

Streaming of audio, video or other data.
Getting network information such as IP addresses and ports. Exchanging of this information with other WebRTC clients (peers) to enable connection even through NATs and firewalls.
In case of error reporting, initiation, session closing and coordinating with signaling communication.
Communicating with streaming video, audio or data.
Exchange of information about media and client capability such as resolution and codecs.


The above functions are been implemented by WebRTC by employing some main APIs listed below:
MediaStream (aka getUserMedia)
RTCPeerConnection
RTCDataChannel


Below is a close look at these APIS
MediaStream

getUserMedia or MediaStream takes the access to data streams for example from user’s camera and microphone. MediaStream is available in Chrome, Firefox and Opera. MediaSream API represents synchronized streams of media. This can be well-explained that a stream taken from camera and microphone input has synchronized video and audio tracks. Each MediaStream has an input, which might be a MediaStrem generated by navigator. getUserMedia(), and an output might have been passed to a video element or an RTCPeer Connection.


getUserMedia() method takes three parameters:


A constraint’s object.
Success callback which, if called, is passed a MediaStream.
Failure callback which, if called, is passed an error object.


Each MediaStream has a label, such as ’Xk7EuLhsuHKbnjLWkW4yYGNJJ8ONsgwHBvLQ’. An array of MediaStreamTracks is returned by the getAudioTracks() and getVideoTracks() methods.

For the simpl.info/gum example, stream.getAudioTracks() returns an empty array (because there’s no audio) and, assuming a working webcam is connected, stream.getVideoTracks() returns an array of one MediaStreamTrack representing the stream from the webcam. Each MediaStreamTrack has a kind (‘video’ or ‘audio’), and a label (like ‘FaceTime HD Camera (Built-in)’), and represents one or more channels of either audio or video. In this case, there is only one video track and no audio, but you can easily imagine with use cases where there are more: for example, a chat application that gets streams from the front camera, rear camera, microphone, and a ‘screenshared’ application.

getUserMedia can also be added in Chromium-based apps and extensions. Adding audioCapture and/or videoCapture permissions enables permission to be requested and granted only once, on installation. Thereafter, the user permission for camera or microphone access is not asked.

Similarly, pages using HTTPS: permission only has to be granted once for getUserMedia(). Very first time an Always Allow button is displayed in the info-bar of the browser.
It is always required on enabling MediaStream for any streaming data source not just a camera or microphone. This enables streaming from disc or from arbitrary data sources such as other inputs and sensors.
Note that getUserMedia() must be used on a server, not the local file system, otherwise a PERMISSION_DENIED: 1 error will be thrown.


2. RTCPeerConnection
RTCPeerConnection: Audio or video calling holds the extension of encryption and bandwidth management. It gets supported in Chrome (in desktop and Android both), Opera (on desktop and Android) and of course in Firefox too. RTCPeerConnection is implemented by Chrome and Opera as webkitRTCPeerConnection and by Firefox as mozRTCPeerConnection. There’s an ultra-simple demo of Chromium’s RTCPeerConnection implementation at simpl.info/pc and a great video chat application at apprtc.appspot.com. This app uses adapter.js, a JavaScript shim maintained by Google, that abstracts away browser differences and spec changes.

RTCPeerConnection is the WebRTC component that handles stable and efficient communication of streaming data between peers.


 RTCPeerConnection safeguards web developers from the myriad complexities. The codecs and protocols used by WebRTC takes care of huge amount of work to make real-time communication even over unreliable networks:



    Packet loss concealment

    Echo cancellation

    Bandwidth adaptivity

    Dynamic jitter buffering

    Automatic gain control

    Noise reduction and suppression

    Image ‘cleaning.’


WebRTC Signalling, session control, network and media information


WebRTC uses RTCPeerConnection to communicate streaming data between browsers. Along with this it also needs a mechanism to coordinate communication and to send control messages. This process can be defined as a signaling. One should know that signaling is not part of the RTCPeerConnection API.

developers can choose whatever messaging protocol they prefer, such as SIP or XMPP, and also an appropriate duplex (two-way) communication channel.


WebRTC needs four types of server-side functionality:

User discovery and communication.
Signaling.
NAT/firewall traversal.
Relay servers in case peer-to-peer communication fails.

RTCDataChannel: peer-to-peer communication of generic data. The API is supported by Chrome 25, Opera 18 and Firefox 22 and above.

References
https://dzone.com/articles/how-to-create-your-first-webrtc-application

What is SCSS?

SCSS is a preprocessor of css. It helps you write your css codes much easily.
It is developed on ruby on rails.


ever faced an issue in css where if you wish to change the complete color theme of website then you have to change each and every color properties of selectors? Or any such issues?

You can create variables in SCSS

$myColor: #333;

#myDiv1{
background-color: $myColor;
}
#myDiv2{
background-color: $myColor;
}


nav {
  ul {
    margin: 0;
    padding: 0;
    list-style: none;
  }

  li { display: inline-block; }

  a {
    display: block;
    padding: 6px 12px;
    text-decoration: none;
  }
}

nav ul {
  margin: 0;
  padding: 0;
  list-style: none;
}

nav li {
  display: inline-block;
}

nav a {
  display: block;
  padding: 6px 12px;
  text-decoration: none;
}

Other features of SCSS are:

Partials and imports: Helps you to split your CSS into smaller, more maintainable portions.
Mixins: A mixin lets you make groups of CSS declarations that you want to reuse throughout your site.
Inheritance: let's you use the properties of any selector with another.
Operators: let's you do math in CSS easily.



References:
https://www.quora.com/What-is-SCSS-How-does-it-differ-from-CSS

How to override the default Origin header in Electron App?

Below is the code to do it.

import { app, BrowserWindow, ipcMain, session } from 'electron';

session.defaultSession.webRequest.onBeforeSendHeaders((details, callback) => {
    console.log('setting headers in main.dev.js details ', details)
    console.log('setting headers in main.dev.js callback ', callback)
    details.requestHeaders['Origin'] = 'https://origin.com';
    callback({ cancel: false, requestHeaders: details.requestHeaders });
  })


references:
https://github.com/electron/electron/issues/2245
https://github.com/electron/electron/issues/6859

Electron - Origin file:// header and heroku CORS proxy

Trying to avoid the Origin with file:// value, since the Axios and the XHR did not work, tried to use
CORS proxy, but this also did not seem to work!

References:
https://medium.com/netscape/hacking-it-out-when-cors-wont-let-you-be-great-35f6206cc646

How to Add interceptors to Axios

// Add a request interceptor
axios.interceptors.request.use(function (config) {
    const token = store.getState().session.token;
    config.headers.Authorization =  token;

    return config;
});


References:
https://stackoverflow.com/questions/43051291/attach-authorization-header-for-all-axios-requests?rq=1

What does the error mean "We apologize, the requested URL was rejected. Please consult with your administrator. Your support ID is:"

This happen when trying to hit the server URL for post from Electron application using XHR.
This is very strange although the GET request to the same is working.

So basically, below is the data from the app when using Electron and React-native as printed in the local node js server.
There is no much difference essentially.

From Electron App

 ------WebKitFormBoundaryuB0JC0S5inEZ8N9q
Content-Disposition: form-data; name="jsonData"

{"id":"","activeDuringCallHold":true,"activeDuringCallPark":true,"messageSourceSelection":"SYSTEM","audioFileDescription":null}
------WebKitFormBoundaryuB0JC0S5inEZ8N9q--


From React-Native app

POST
 --AtDN_wHVWYYY2U3o1qKMCiQ.jaTz2HCZ7tPArc_Iumu.6tU3-40e5n3KyyFK2-lW--VmQn
content-disposition: form-data; name="jsonData"

{"id":"","activeDuringCallHold":true,"activeDuringCallPark":true,"messageSourceSelection":"SYSTEM","audioFileDescription":null}
--AtDN_wHVWYYY2U3o1qKMCiQ.jaTz2HCZ7tPArc_Iumu.6tU3-40e5n3KyyFK2-lW--VmQn--


And the headers from the two platforms are like below. The main difference is Origin is set to file:// in Electron which is not able to be changed by setting the header options for some reason,

From Electron App

Headers

{"host":"127.0.0.1:3000","connection":"keep-alive","content-length":"266","authorization":"Basic bWNkLWFkbWluOkFkbWluMUAxMjM=","origin":"file://","user-agent":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.181 Electron/3.0.10 Safari/537.36","content-type":"multipart/form-data;","accept":"*/*","accept-encoding":"gzip, deflate","accept-language":"en-GB"}


 ------WebKitFormBoundaryuB0JC0S5inEZ8N9q
Content-Disposition: form-data; name="jsonData"

{"id":"","activeDuringCallHold":true,"activeDuringCallPark":true,"messageSourceSelection":"SYSTEM","audioFileDescription":null}
------WebKitFormBoundaryuB0JC0S5inEZ8N9q--


From React-Native app

Headers

{"host":"127.0.0.1:3000","content-type":"multipart/form-data; boundary=h3KnK7XfLMut.istQrUWQ7W7Ucw0uVer8cyQVaeOamrAHWqNVdVEf4-7ZEAesw.Nl8HRNm","user-agent":"BroadcloudBulkProvisioning/2 CFNetwork/975.0.3 Darwin/17.7.0","connection":"keep-alive","accept":"*/*","accept-language":"en-us","content-length":"330","accept-encoding":"gzip, deflate","authorization":"Basic bWNkLWFkbWluOkFkbWluMUAxMjM="}



POST
 --AtDN_wHVWYYY2U3o1qKMCiQ.jaTz2HCZ7tPArc_Iumu.6tU3-40e5n3KyyFK2-lW--VmQn
content-disposition: form-data; name="jsonData"

{"id":"","activeDuringCallHold":true,"activeDuringCallPark":true,"messageSourceSelection":"SYSTEM","audioFileDescription":null}
--AtDN_wHVWYYY2U3o1qKMCiQ.jaTz2HCZ7tPArc_Iumu.6tU3-40e5n3KyyFK2-lW--VmQn--


References:
https://support.mozilla.org/en-US/questions/1197304
https://support.mozilla.org/en-US/questions/1233607

Extracting Fingerprint from Google Play Console

Navigate to the Google Play Console and login
Choose the application you are signing
Go to Release Management –> App Signing
Copy /Download the SHA-1 certificate fingerprint from the App signing certificate section

This app signing certificate SHA-1, is the fingerprint of the final singing certificate that will be distributed via Google Play


references:
https://www.appdome.com/no-code-mobile-integration-knowledge-base/extracting-a-sha-1-fingerprint-from-the-google-play-app-signing-certificate/