Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Introduction:

RDK-C Mobile application will be used to watch live streaming from RPI Camera & Previous recordings from RPI Camera stored in Cloud Servers. In this mobile application we use WebRTC protocol for live streaming of video & audio, HTTP to play or download the previous recordings from cloud servers.

This mobile app will support android & iOS* platforms. This page is dedicated to bring up the overall picture of the mobile app and how it works.

About WebRTC:

WebRTC, short for Web Real-Time Communication, is both an API and a Protocol. The WebRTC protocol is a set of rules for two WebRTC agents to negotiate bi-directional secure real-time communication. A similar relationship would be the one between HTTP and the Fetch API. WebRTC the protocol would be HTTP, and WebRTC the API would be the Fetch API.

To establish WebRTC communication one should involve the below 4 steps:

  1. Signalling
  2. Connecting
  3. Securing
  4. Communicating

These four steps happen sequentially. The prior step must be 100% successful for the subsequent one to even begin. Each of these steps has dedicated chapters, but it is helpful to understand them at a high level first. Since they depend on each other, it will help when explaining further the purpose of each of these steps.

  • Signalling:

            When a WebRTC Agent starts it has no idea who it is going to communicate with and what they are going to communicate about. Signalling solves this issue! Signalling is used to bootstrap the call                  so that two WebRTC agents can start communicating. Signaling uses an existing protocol SDP (Session Description Protocol). SDP is a plain-text protocol. Each SDP message is made up of of                              key/value pairs and contains a list of “media sections”.

...

  •  Connecting:    

            The two WebRTC Agents now know enough details to attempt to connect to each other. WebRTC then uses another established technology called ICE.

            ICE (Interactive Connectivity Establishment) is a protocol that pre-dates WebRTC. ICE allows the establishment of a connection between two Agents. These Agents could be on the same network, or                on the other side of the world. ICE is the solution to establishing a direct connection without a central server.

            The real magic here is ‘NAT Traversal’ and STUN/TURN Servers. These two concepts are all you need to communicate with an ICE Agent in another subnet. Once ICE successfully connects, WebRTC                then moves on to establishing an encrypted transport. This transport is used for audio, video, and data.

  • Securing:

           Now that we have bi-directional communication (via ICE) we need to establish secure communication. This is done through two protocols that pre-date WebRTC. The first protocol is DTLS (Datagram             Transport Layer Security) which is just TLS over UDP. TLS is the cryptographic protocol used to secure communication over HTTPS. The second protocol is SRTP (Secure Real-time Transport                             Protocol).

           First, WebRTC connects by doing a DTLS handshake over the connection established by ICE. Unlike HTTPS, WebRTC doesn’t use a central authority for certificates.

           WebRTC then uses a different protocol for audio/video transmission called RTP. We secure our RTP packets using SRTP. We initialize our SRTP session by extracting the keys from the negotiated                     DTLS session.

  • Communicating:

           We now have two WebRTC Agents with secure bi-directional communication. we use two pre-existing protocols: RTP (Real-time Transport Protocol), and SCTP (Stream Control Transmission                             Protocol).  Use RTP to exchange media encrypted with SRTP, and use SCTP to send and receive DataChannel messages encrypted with DTLS.


Now we are done! You now have bi-directional and secure communication. If you have a stable connection between your WebRTC Agents, this is all the complexity you may need.


Application Architecture (Live streaming)


Image Added

Application Flow (Live streaming)


Image RemovedImage Added

Mobile App Features

Following are the mobile application features.

...