Authors: Abhay Kasetwar, Nikita Balani, Deepika Damwani, Alfiya Pandey, Aafreen Sheikh, Apeksha Khadse
Certificate: View Certificate
II. TECHNOLOGIES USED
A. Web Real Time Communication (WRTC)
Web Real-time Communication is a framework that allows browsers to communicate with each other in real time. WebRTC allows browsers to natively broadcast audio, video, and arbitrary data to one another without the use of a central server. This eliminates the need for plugins or platform-specific apps when writing and running real-time applications like communication services directly in the browser. A voice engine, video engine, and transport and communication technologies are all included in WebRTC. It's utilised for conferencing, social networking, online medical consultations, live games, and other applications that require Real Time Communication (RTC). It allows developers to create RTC Data Channel, RTC Peer Connection, and Media Stream objects.
STUN/TURN servers, a signalling server, ICE, SDP, NAT, UDP, and a signalling server TCP and UDP are used to establish
TC direct peer-to-peer connections. Next, we'll look at each of these elements individually.
2. getUserMedia() API
specifying video, you can gain access to a user's camera and microphone. on the HTML5 page, as well as audio tags
these tags are specified in the method navigator of the video chat WebRTC application. getUserMedia(), which requires two arguments additional parameters to handle what to do when the video/audio streams are properly collected, and what to do when they are not
if it is unable to capture them When using this application in a browser that specifically requests permission from users,
It is acceptable to utilise a webcam. Encryption is one of the operations that are required for all layers of the protocol. If messages transferred between browsers are stolen or hijacked in the middle of transmission, they are unreadable. In the Security section, we'll go over these encryption features in further detail. Regardless, have a half-decent code in the navigator to specify video/audio streams. This function, at most, getsUserMedia() alone is insufficient to see the user's face. It has to be RTCPeerConnection registered ()
3. RTC Peer Connection API
The RTCPeerConnection object is in charge of the components involved in connecting two browsers to share real-time media. It establishes a connection and collects gICE candidates, which entails obtaining the public IP address and port address of two browsers.
When two browsers want to share data, they need to be able to exchange three different types of information. They must first select whether or not to link. close by going over the session control data They must then figure out how to exchange network data like each peer's IP address and port numbers. Finally, they'll have to know how to deal with media data like the codecs and media formats used by the peers in the connection.
We provide a rough overview of how the RTCPeerConnection API can be utilised in this section. This API actually uses a lot more events, methods, and properties than are listed here. This API is accompanied by a number of underlying protocols, which we shall discuss in greater depth in this section.
The STUN and TURN servers required to locate the ICE candidates are included in the parameter used to generate the RTCPeerConnection object. Google offers free public STUN servers at code.google.com, however there aren't many free TURN servers, and the only ones that are trustworthy are commercial A caller (peer) must first construct a new RTCPeerConnection object called pc. Now pc must construct an ICE candidate by calling onicecandidate(), which returns a list of ICE candidates returned by STUN/TURN servers, each of which contains the current browser's public IP address and port. The signal server transmits these numbers to the target peer. The getUserMedia function then receives a local and remote media stream for the pc object. This For a remote media stream, the onaddstream() method must be used to attach it to RTCPeerConnection.
For a local video/audio stream, use the addStream() method. The caller pc must use the createOffer method to create an offer () method. This package includes codecs, encryption algorithms, and more. as well as any candidates acquired by the ICE agent, All of these are encapsulated in SDP, which is supplied as a parameter to a new RTC Session Description (offer) object. The RTCPeerConnection is then used by PC. setLocalDescription() method for sending data to a target peer via a signalling server
B. Session Description Protocol (SDP)
In the last section, we examined the relevance of a signal server in a WebRTC application and the vital role it plays in data exchange between two peers; however, the signal server cannot work alone. To execute its purpose, it requires the help of numerous other underlying protocols, one of which being SDP. SDP's major function is to share media-related information based information through a network with other peers SDP provides the session's name, purpose, media type, protocols, codec and its settings, timings, and transportation information. When the RTCPeerConnection object begins collecting ICE candidates for establishing a connection with another user, an SDP description is constructed. SDP has been present for a long time (since the late 1990s) for media-based connections, and it has gained experience through a variety of different uses, such as phones, before it was used for the first time. WebRTC will rely significantly on it. The SDP format is text-based. With a line breaker at the end, it consists of a set of key-value pairs. This is an example: "key>=value>n." This key uses a single character to represent the value type, with a machine-readable configuration value is the value. It use mnemonic names like the ones listed below.
III. LITERATURE SURVEY
There have been many researches that explored the architectural choices for internet broadcast. In , the authors reviewed the architectural choices for supporting Internet broadcast.
In the Internet environment, the major issue for broadcast is determining the layer of implementation. There are two conflicting considerations 1) a functionality should be pushed to higher layers if possible unless 2) implementation at a lower layer can achieve significant performance benefits that outweighs the additional complexity. In , the authors argued
that this second consideration should prevail and it has since been widely accepted, leading to the IP multicast model of today. Unfortunately, despite the tremendous effort in the past today’s IP multicast deployment remains limited. Three complex reasons are making this approach less attractive. First, IP multicast requires router support which introduces high complexity and serious scaling constraints. Secondly, IP multicast attempts to conform to the traditional separation of routing and transport that has worked well in the unicast
context. However, providing higher level features is proved to be more difficult than in the unicast case. Finally, IP multicast calls for changes at the infrastructure level, and this slows down the pace of deployment.
In the new millennium several researchers proposed to move multicast functionality away from routers towards end systems , , , . In these approaches, multicast-related features are implemented at end systems, assuming only unicast IP service. Moving multicast functionality to end systems has the potential to address many of the problems associated with IP multicast. Deployment is accelerated because all packets are transmitted as unicast packets. In addition, solutions for supporting higher layer features can be significantly simplified by using unicast solutions and application specific intelligence. But moving multicast functionality away from routers has obvious performance penalties. For example, preventing multiple overlay edges from traversing the same physical link is not completely possible so there will always be redundant traffic on physical links. Further, communication between end systems need the traversing of other end systems which
increases latency. Hence, many research efforts have focused on addressing these performance concerns.
Because clients do not need to send and receive messages through a server, direct communication between browsers improves performance and minimises latency times. For example, we might connect two clients using WebSockets, but a server would have to transport their communications as shown in the picture below:
WebRTC, on the other hand, requires only a server to originate and control client connections.
Signaling is the term for this procedure. After the browsers have gathered the necessary information from their peers, they can communicate with one another as follows:
Because WebRTC does not specify a signalling messaging protocol, the implementation chosen must be depending on the application requirements; some of the most prevalent approaches include WebSockets, SIP, and others.
The following is how the signalling system works:
What is Interactive Connectivity Establishment and how does it work? ICE is an Internet peer-to-peer network communication technique for sending and receiving media data. The details of routing (NATs, firewalls, etc.) are outside the scope of this article, but it is something that WebRTC must address. For NAT and firewall traversal, ICE aggregates available network connections, known as ICE candidates, and uses the protocols STUN (Session Traversal Utilities for NAT) and TURN (Traversal Using Relays around NAT).
CE processes the connection in the following way:
It begins by attempting to connect peers directly through UDP.
If UDP fails, TCP is used. If both UDP and TCP direct connections fail, as they frequently do in real-world circumstances due to NATs and firewalls, ICE will connect peers via a STUN server with UDP. A STUN server is a server that uses the STUN protocol to determine a peer's public address and port behind an asymmetric NAT.
If the STUN server fails, ICE will fall back on a TURN server, which is a STUN server with additional relaying capabilities that can pass through symmetric NATs. As you can see, ICE tries to use STUN servers initially, but for severely restricted corporate networks, TURN relay servers will be required. TURN relay servers are expensive, so you'll either have to pay for your own or hire one, but ICE will usually be able to link peers with STUN. A STUN/TURN conversation is shown in the diagram below:
To summarise, the signalling mechanism is utilised to trade media data via SDP files, whereas ICE is used to communicate peer network connections. Peers can finally share data directly through their browsers after the channel has been established.
B. Video Conferencing
When a user logs in, our main Audio/Video Conferencing module appears, allowing them to view the video of others and privately communicate with them. This module opens when a user clicks on a new module on the UI.
Any video can be enlarged by simply clicking on it. Each video has a name tag, as well as additional admin controls.
C. Participant List and Features
A list of all linked participants appears on the right side of the screen. Next to each user are two buttons.
V. OBJECTIVES OF PROPOSED
VI. FUTURE SCOPE
Our application covers a wide range of topics, including business, distant learning, telecommuting/home offices, legal settings, and telemedicine. It allows businesses to meet and collaborate with others over long distances. Teachers and pupils can see one another. In an atmosphere comparable to a typical classroom, students can share documents and discuss issues. It assists users in by videoconferencing with clients and/or coworkers, you can save time and money. Videoconferencing technology is becoming increasingly widely used. It is becoming more widespread in today's courtrooms. The usage of videoconferencing technology allows testifying witnesses to appear in court without having to go to the courtroom. A patient in a remote area can consult with an expert from anywhere in the world.
VII. RESULTS AND DISCUSSION
Following the completion of the WebRTC video conferencing system, the following results were obtained:
A video conferencing solution was designed and approved using WebRTC technology. WebRTC was chosen for this study because it is simple to use and does not require any plugins or applications to be installed; all you need is a browser that supports it. The video conferencing system runs on a web browser that runs on a range of operating systems. The purpose of this research is to reduce the amount of work and difficulties involved in communicating while also producing a video. a video conference that includes voice calls, video calls, file sharing, desktop sharing, and recording. The format and attendance will vary depending on who attends. These goals have been achieved. The option to create and join rooms will be available to users. They can construct and join rooms, as well as broadcast and receive voice and video. They can receive audio and video broadcasts from other users and share presentations and locally recorded videos. They are also capable of communicating with one another. either using private or public texting Our app works on computers, tablets, and smartphones.
 Rhinow, Florian, Pablo Porto Veloso, Carlos Puyelo, Stephen Barrett, and Eamonn O. Nuallain. \"P2P live video streaming in WebRTC.\" In Computer Applications and Information Systems (WCCAIS), 2014 World Congress on, pp. 1-6. IEEE, 2014.  Liu, Jiangchuan, Sanjay G. Rao, Bo Li, and Hui Zhang. \"Opportunities and challenges of peer-to-peer internet video broadcast.\" Proceedings of the IEEE 96, no. 1 (2008): 11-24.  Deering, Stephen E., and David R. Cheriton. \"Multicast routing in datagram internetworks and extended LANs.\" ACM Transactions on Computer Systems (TOCS) 8, no. 2 (1990): 85-110.  Chawathe, Yatin, Steven McCanne, and Eric Brewer. \"An architecture for internet content distribution as an infrastructure service.\" Unpublished, available at http://www.cs.berkeley.edu/yatin/papers (2000).  Chu, Yang-hua, Sanjay G. Rao, Srinivasan Zeeshan, and Hui Zhang. \"A case for end system multicast.\" IEEE Journal on selected areas in communications 20, no. 8 (2002): 1456-1471.  Francis, Paul. \"Yoid: Extending the internet multicast architecture.\" (2000).  Zhuang, Shelley Q., Ben Y. Zhao, Anthony D. Joseph, Randy H. Katz, and John D. Kubiatowicz. \"Bayeux: An architecture for scalable and fault-tolerant wide-area data dissemination.\" In Proceedings of the 11th international workshop on Network and operating systems support for digital audio and video, pp. 11-20. ACM, 2001.  Chu, Yang, Sanjay Rao, Srinivasan Seshan, and Hui Zhang. \"Enabling conferencing applications on the internet using an overlay muilticast architecture.\" ACM SIGCOMM computer communication review 31, no. 4 (2001): 55-67.  Luo, Chong, Wei Wang, Jian Tang, Jun Sun, and Jiang Li. \"A multiparty videoconferencing system over an application-level multicast protocol.\" IEEE Transactions on Multimedia 9, no. 8 (2007): 1621-1632.  Chen, Minghua, Miroslav Ponec, Sudipta Sengupta, Jin Li, and Philip A. Chou. \"Utility maximization in peer?to-peer systems.\" In ACM SIGMETRICS Performance Evaluation Review, vol. 36, no. 1, pp. 169-180. ACM, 2008.  Ponec, Miroslav, Sudipta Sengupta, Minghua Chen, Jin Li, and Philip A. Chou. \"Multi-rate peer-to-peer video conferencing: A distributed approach using scalable coding.\" In 2009 IEEE International Conference on Multimedia and Expo, pp. 1406-1413. IEEE, 2009.  Koh, Eunyee. \"Conferencing room for telepresence with remote participants.\" In Proceedings of the 16th ACM international conference on Supporting group work, pp. 309-310. ACM, 2010.  Isaacs, Ellen A., and John C. Tang. \"What video can and cannot do for collaboration: a case study.\" Multimedia Systems 2, no. 2 (1994): 63-73.
Copyright © 2022 Abhay Kasetwar, Nikita Balani, Deepika Damwani, Alfiya Pandey, Aafreen Sheikh, Apeksha Khadse. This is an open access article distributed under the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.