My new project with WebRTC, what is WebRTC?

Time on time I periodically make WebTRC projects, of course, I not have enough tome to describe all my projects, but one description of WebRTC projects I have in my blog. This is fast description with screenshots only My site with peer-to-peer communication based on Mizu-Voip library. But now I make new WebRTC project on Android.

But firstly, a couple of main points about WebRTC, and relation with SIP:

1. What is WebRTC
2. WebRTC terminology and conceptions
3. Main source of information about WebRTC
4. What is SIP
5. What relation between SIP and WebRT
6. Examples of SIP servers
7. "glue" between WebRTC and SIP
8. Main functions of WebRTC
9. Conceptual WebRTC Workflow
10. Simple peer repository
11. My own WebRTC test peer
12. Implement simple-peer as responder to Android apps
13. Free STUN servers
14. Free TURN server for NAT traversal
15. What is NAT Traversal

1. WebRTC is a collection of APIs and protocols that enable real-time communication (RTC) - https://en.wikipedia.org/wiki/WebRTC
• Peer-to-peer communication: WebRTC enables direct communication between browsers (or other WebRTC-enabled applications) without needing a central server for media relaying (although a signaling server is required for initial connection setup).
• Low latency: Optimized for low-latency communication, which is crucial for real-time audio and video.
• Built-in codecs and protocols: Supports commonly used audio and video codecs (e.g., Opus, VP8, H.264) and network protocols (SRTP, STUN, TURN). This reduces interoperability issues.
• Browser integration: WebRTC is integrated directly into modern web browsers, making it easy to add real-time communication capabilities to web applications.
• Adaptive bitrate streaming: WebRTC dynamically adjusts the video quality based on network conditions, improving the user experience in varying network environments.


2. WebRTC terminology and conceptions:

• 	Description	Purpose	Key Components
  Signaling	The process of exchanging session descriptions (SDP) and ICE candidates between peers to negotiate a connection.	To establish a communication channel between two or more peers.	SDP offers and answers, ICE candidates, signaling servers.
  ICE Candidate Gathering	The process of discovering potential network paths for establishing a connection between peers.	To find the best route for communication, bypassing firewalls and NATs.	ICE candidates, STUN and TURN servers.
  Media Stream Establishment	The process of sending and receiving audio and video streams between peers.	To enable real-time audio and video communication.	Media tracks (audio and video), codecs, media constraints.
  Data Channels	A bidirectional communication channel for exchanging arbitrary data between peers.	To enable real-time data transfer, such as text messages, files, or game state.	DataChannel API, message types, reliability options.
  Negotiation	The process of updating the connection parameters between peers, such as codecs or media constraints.	To adapt to changing network conditions or user preferences.	SDP renegotiation, offer/answer exchange.
  Error Handling	Mechanisms for detecting and handling errors that may occur during a WebRTC session.	To ensure robust and reliable communication.	Error events, error codes, recovery strategies.
  Security	Measures to protect the privacy and integrity of WebRTC communications.	To prevent unauthorized access and eavesdropping.	DTLS-SRTP encryption, certificate management.
  NAT Traversal	Techniques for establishing connections between peers located behind NATs (Network Address Translators).	To enable communication across different networks.	STUN and TURN servers, ICE protocol.
  Peer-to-Peer Communication	Direct communication between peers without the need for a central server.	To reduce latency and improve scalability.	ICE protocol, peer discovery mechanisms.
  Multi-Party Communication	Communication between three or more peers in a conference or group chat.	To enable collaborative interactions.	Key Components: Selective Forwarding Unit (SFU), Multipoint Control Unit (MCU).
  Observing WebRTC Functionality	Monitoring Events: Implement the PeerConnection.Observer and WebRTCEventListener interfaces to receive callbacks for various WebRTC events. Logging: Add Log.d statements to your event handlers to print information about the events that occur. Debugging Tools: Use browser developer tools or dedicated WebRTC debugging tools to inspect the state of your WebRTC connection. Network Monitoring: Use network monitoring tools to observe the traffic generated by your WebRTC session.

  
  

  	ICE Candidates	STUN Servers	TURN Servers
  Description	ICE (Interactive Connectivity Establishment) candidates are potential network paths that a WebRTC peer can use to connect to another peer. They represent different ways a peer can be reached, such as through a local IP address, a public IP address, or a relay server.	STUN (Session Traversal Utilities for NAT) servers are used to discover the public IP address and port of a WebRTC peer behind a NAT.	TURN (Traversal Using Relays around NAT) servers are used as relays for communication between WebRTC peers when direct connections are not possible.
  Types	Host Candidates: Represent the peer's local IP address and port. Used for direct peer-to-peer connections within the same network. Server Reflexive Candidates: Obtained by contacting a STUN server. Represent the peer's public IP address and port as seen by the STUN server. Used for connections across NATs. Relay Candidates: Obtained by contacting a TURN server. Represent the address and port of the TURN server, which acts as a relay for communication between peers. Used when direct connections are not possible due to firewalls or other network restrictions.	N/A	N/A
  Purpose	ICE candidates are essential for establishing a WebRTC connection, as they provide the necessary information for peers to find and connect to each other.	STUN servers help WebRTC peers establish connections across NATs by providing them with their public network information.	TURN servers provide a fallback mechanism for establishing WebRTC connections when direct connections are blocked by firewalls or other network restrictions.
  Functionality	Provide connection information (e.g., local, public, or relay addresses).	Respond with the peer's public IP address and port as seen by the server.	Act as an intermediary for communication between peers when direct connections fail.
  Usage	Used by WebRTC peers to connect to each other.	Used to obtain server reflexive ICE candidates.	Used when direct connections are not possible (e.g., due to firewalls or symmetric NATs).
  Necessity	Essential for all WebRTC connections.	Often sufficient for NAT traversal in simple network scenarios.	Required for complex network scenarios where direct connections fail.
  In Summary	ICE candidates are the building blocks of WebRTC connections, providing the necessary information for peers to find and connect to each other.	STUN servers help discover the public IP address and port of a peer behind a NAT, enabling connections across different networks.	TURN servers act as relays for communication when direct connections are not possible, providing a fallback mechanism for establishing WebRTC connections.



3. Main source of information about WebRTC:
• Where is main code of WebRTC project stored - https://webrtc.googlesource.com/src/
• Where is main WebRTC community - https://webrtc.googlesource.com/src/webrtc/
• Where is main place with WebRTC instructions - https://developers.google.com/codelabs/
• Where is main samples repository - https://webrtc.github.io/samples/
• Where is main repository of WebRTC for Android - https://github.com/webrtc-sdk/android


4. What is SIP - https://en.wikipedia.org/wiki/Session_Initiation_Protocol
• SIP (Session Initiation Protocol) is a signaling protocol used for initiating, maintaining, and terminating real-time communication sessions (calls, video conferences, instant messaging) over IP networks
• Signaling protocol: SIP itself does not handle media streaming. It's used for session setup, negotiation, and teardown
• Flexible and extensible: Can be used with various media protocols (RTP, SRTP) and codecs. Supports a wide range of features (e.g., call transfer, presence).
• Widely used in VoIP (Voice over IP) systems: SIP is a core protocol in many VoIP and video conferencing systems.
• Key points to understand SIP:
• NAT Traversal (STUN/TURN): You'll likely need to set up STUN and TURN servers to handle NAT traversal for your WebRTC connections
• SDP and ICE Exchange: Implementing the logic to embed and extract SDP/ICE information within SIP messages will be one of the more complex parts


5. What relation between SIP and WebRTC:
• WebRTC and SIP can work together. While WebRTC includes its own signaling mechanisms, you can use SIP as the signaling protocol for WebRTC.
• SIP for WebRTC Signaling: A SIP server can be used to handle the initial signaling and session setup for a WebRTC call. Once the connection is established (including media negotiation using SDP, Session Description Protocol), the actual media streaming occurs peer-to-peer via WebRTC.
• Benefits of using SIP with WebRTC: Leverages the existing SIP infrastructure and its rich feature set. This allows integrating WebRTC with existing VoIP systems and adding WebRTC capabilities to SIP-based applications.


• Key Differences between WebRTC and SIP:

• 	WebRTC	SIP
  Purpose	Real-time communication (media + signaling)	Signaling protocol (session management)
  Media Handling	Built-in media handling (peer-to-peer)	Does not handle media directly
  Browser Support	Native browser support	Requires plugins or external libraries
  Complexity	Generally easier to use for basic setups	More complex signaling and configuration
  Scalability	Can be challenging for large deployments	Scales well with appropriate infrastructure
  Features	Fewer built-in features than SIP	Rich feature set (call transfer, presence)
  Signaling	Uses external signaling mechanisms (e.g., WebSocket, SIP, or custom protocols) to exchange SDP offers/answers and ICE candidates.	Primarily a signaling protocol for establishing, modifying, and terminating multimedia sessions. Does not handle media transmission directly.
  Media Handling	Handles audio and video streams natively using its own APIs (e.g., MediaStream API).	Relies on other protocols (e.g., RTP/RTCP) for media transport.
  Data Channels	Supports bidirectional data transfer using the DataChannel API (e.g., for text, files, or game state).	Does not have an equivalent to WebRTC's DataChannel API.
  NAT Traversal	Uses built-in support for ICE, STUN, and TURN to traverse NATs and establish connections.	Requires additional components (e.g., SIP ALG, media relays) for NAT traversal.
  Peer-to-Peer Communication	Designed for direct peer-to-peer communication, reducing latency and improving scalability.	Typically involves a central server (e.g., SIP proxy) to manage sessions.
  Security	Mandates the use of DTLS-SRTP for encrypting media streams and data channels.	Relies on external mechanisms (e.g., TLS, SRTP) for securing signaling and media.
  Multi-Party Communication	Supports multi-party communication using SFUs (Selective Forwarding Units) or MCUs (Multipoint Control Units).	Requires additional infrastructure (e.g., conferencing servers) for multi-party communication.
  Overlap	Can use SIP as a signaling protocol for exchanging SDP offers/answers.	Can work with WebRTC for signaling and media exchange.



6. Examples of SIP servers:

• 	Short Characteristics	Website	OpenSource or Proprietary	Purposes
  Asterisk	Highly customizable, supports multiple VoIP protocols	https://www.asterisk.org/	OpenSource	Small to large VoIP systems, PBX
  FreeSWITCH	Scalable, supports SIP, WebRTC, and more	https://freeswitch.org/	OpenSource	VoIP, conferencing, PBX
  Kamailio	High-performance, scalable SIP server	https://www.kamailio.org/	OpenSource	Large-scale VoIP deployments
  OpenSIPS	Efficient SIP routing and handling	https://opensips.org/	OpenSource	VoIP routing, load balancing
  SIP Express Router (SER)	One of the earliest SIP servers	https://www.iptel.org/ser/	OpenSource	VoIP routing, SIP traffic handling
  Jitsi	Open-source, focused on video conferencing	https://jitsi.org/	OpenSource	Video conferencing, WebRTC
  Routr	Lightweight, microservices-based SIP server	https://routr.io/	OpenSource	VoIP, microservices architecture
  SIPfoundry (sipXecs)	Open-source unified communications	http://www.sipfoundry.org/	OpenSource	Unified communications, PBX
  3CX	User-friendly, web-based management	https://www.3cx.com/	Proprietary (Free version available)	Small to medium businesses, PBX
  Cisco Unified Communications Manager (CUCM)	Enterprise-grade, robust SIP server	https://www.cisco.com/c/en/us/products/unified-communications/unified-communications-manager-callmanager/index.html	Proprietary	Enterprise VoIP, unified communications
  Avaya Aura	Advanced features for large-scale deployments	https://www.avaya.com/en/products/ucaas/avaya-aura/	Proprietary	Enterprise VoIP, unified communications
  Metaswitch	Scalable and reliable SIP server	https://www.metaswitch.com/	Proprietary	Service providers, enterprises
  Mitel MiVoice Business	SIP-based communication platform	https://www.mitel.com/products/mivoice-business	Proprietary	Business VoIP, PBX
  Twilio	Cloud-based communication platform	https://www.twilio.com/	Proprietary	VoIP applications, SIP trunking
  Vonage	Cloud-based SIP server and APIs	https://www.vonage.com/	Proprietary	VoIP applications, SIP trunking
  Zoom Phone	Cloud-based SIP server integrated with Zoom	https://zoom.us/zoom-phone	Proprietary	Business VoIP, remote teams
  RingCentral	Cloud-based SIP server and unified communications	https://www.ringcentral.com/	Proprietary	Business VoIP, SIP trunking



7. "glue" between WebRTC and SIP:
• 1. SIP Registration: Both WebRTC peers register with a SIP server. This allows them to be reachable via their SIP addresses (SIP URIs).
• 2. SIP INVITE: One peer initiates a WebRTC session by sending a SIP INVITE message to the other peer via the SIP server. The INVITE message might contain an initial SDP offer describing the caller's media capabilities.
• 3. SDP Offer/Answer Exchange (within SIP): The receiving peer responds with a SIP message (e.g., a 200 OK with an SDP answer) containing their SDP answer, which describes their media capabilities and any modifications to the offer. This SDP offer/answer exchange is how the two peers agree on the media formats and codecs they'll use.
• 4. ICE Candidate Exchange (within SIP): The peers also exchange ICE candidates. ICE candidates are potential network paths that the peers can use to connect to each other. These candidates are embedded in the SIP signaling messages (often using a format like SDP or a custom mechanism) and transmitted to each other via the SIP server. ICE helps traverse Network Address Translators (NATs) and firewalls, which are common in real-world network environments.
• 5. WebRTC Peer Connection: Once the SDP offer/answer and ICE candidates have been exchanged via SIP signaling, the WebRTC peer connection (RTCPeerConnection) is established directly between the peers. The SDP and ICE information provided via SIP is used by WebRTC to create this P2P connection.
• 6. Media Streaming: After the WebRTC peer connection is established, media (audio, video) streams directly between the peers, bypassing the SIP server. The SIP server is no longer involved in the media path.


8. Main functions of WebRTC:
• RTCPeerConnection: The core interface for establishing a peer-to-peer connection between two WebRTC endpoints. It handles signaling, ICE (Interactive Connectivity Establishment) negotiation, and media stream management.
• Important methods: createOffer(), createAnswer(), setLocalDescription(), setRemoteDescription(), addIceCandidate(), addTrack(), removeTrack(), close(), and many more.
• MediaStream: Represents a stream of media (audio, video, or both).
• Key properties: id, active.
• Methods: addTrack(), removeTrack(), getTracks(), getAudioTracks(), getVideoTracks(), clone().
• MediaTrack: Represents a single media track (either audio or video).
• Key properties: id, kind (audio or video), enabled, muted, readyState.
• Important methods: stop(), applyConstraints(), getCapabilities(), getSettings().
• RTCDataChannel: Provides a bidirectional data channel between peers, enabling arbitrary data transfer during a WebRTC session.
• Methods: send(), close().
• Events: open, message, error, close.
• RTCSessionDescription: Represents a session description (SDP, Session Description Protocol) used for media negotiation between peers. Created by createOffer() or createAnswer() on RTCPeerConnection.
• RTCIceCandidate: Represents an ICE candidate (potential network path) used for establishing connectivity between peers.
• navigator.mediaDevices: An object providing access to connected media input devices (cameras, microphones).
• Key method: getUserMedia(): Prompts the user for permission to access their camera and/or microphone and returns a MediaStream.


9. Conceptual WebRTC Workflow:
• 1. Get user media: Use navigator.mediaDevices.getUserMedia() to access the user's camera and/or microphone.
• 2. Create peer connections: Create RTCPeerConnection objects on both ends of the communication.
• 3. Create an offer: One peer creates an offer (an RTCSessionDescription) using createOffer().
• 4. Set local description: The offer is set as the local description using setLocalDescription().
• 5. Send offer to remote peer (signaling): Transmit the offer to the other peer using a signaling mechanism (WebSocket, SIP, or any other chosen signaling method).
• 6. Set remote description: The remote peer receives the offer and sets it as their remote description using setRemoteDescription().
• 7. Create an answer: The remote peer creates an answer (also an RTCSessionDescription) using createAnswer().
• 8. Set local and remote descriptions: Set local and remote descriptions for the answer, mirroring the steps for offer but in reverse direction.
• 9. Exchange ICE candidates: As each peer gathers ICE candidates, these are sent to the other peer using the signaling channel and added to the peer connection using addIceCandidate().
• 10. Connect and stream media: Once the ICE negotiation is complete and a connection is established, media will start streaming between the peers.


10. Simple peer repository - https://www.npmjs.com/package/simple-peer

    	simple-peer	Full WebRTC Implementation
    What simple-peer Simplifies	ICE Candidate Management: Automatically gathers ICE candidates and handles their exchange. No need to manually listen for onicecandidate events or process ICE candidates. SDP Offer/Answer Exchange: Automatically generates SDP offers/answers and processes them. No need to manually create or parse SDP. Data Channel Setup: Simplifies creating and managing WebRTC data channels. No need to manually configure RTCDataChannel objects. Connection Lifecycle: Handles the connection lifecycle (e.g., connecting, reconnecting, closing). No need to manually manage RTCPeerConnection states. STUN/TURN Configuration: Automatically uses STUN/TURN servers if provided in the configuration. No need to manually configure RTCConfiguration. Error Handling: Provides basic error events (e.g., on('error', ...)). Reduces the need for extensive error handling code. Boilerplate Code: Eliminates the need for writing repetitive WebRTC boilerplate code. Makes it easier to focus on application logic rather than WebRTC setup.	N/A
    Signaling	Does not handle signaling. You need to implement signaling separately.	Requires custom signaling implementation (e.g., WebSocket, SIP) to exchange SDP and ICE.
    ICE Candidate Handling	Automatically gathers and manages ICE candidates.	You must manually handle ICE candidate gathering, filtering, and exchange.
    SDP Offer/Answer Exchange	Automatically generates and processes SDP offers/answers.	You must manually create SDP offers/answers and handle their exchange.
    Data Channels	Simplifies creating and managing WebRTC data channels.	Requires manual setup and management of RTCDataChannel objects.
    Media Streams	Supports attaching media streams but does not handle media capture.	Requires manual setup of getUserMedia for media capture and RTCPeerConnection for streams.
    Error Handling	Provides basic error events but may require additional handling.	Requires manual error handling for all WebRTC events and states.
    NAT Traversal	Automatically uses STUN/TURN servers if provided.	Requires manual configuration of STUN/TURN servers in RTCConfiguration.
    Code Complexity	Minimal code required to establish a connection.	Requires significantly more code to set up and manage connections.
    Customization	Limited customization options due to abstraction.	Full control over WebRTC behavior, including custom SDP manipulation and advanced features.
    Dependencies	Lightweight and standalone.	Relies on native WebRTC APIs, which may require polyfills or additional libraries.
    Use Case	Ideal for quick prototyping, small projects, or when simplicity is preferred.	Suitable for complex applications requiring fine-grained control over WebRTC behavior.
    When to Use:	You need a quick and easy way to set up WebRTC connections. You are building a small project or prototype. You don’t need advanced customization or control over WebRTC behavior.	You need fine-grained control over WebRTC behavior (e.g., custom SDP manipulation, advanced error handling). You are building a complex application with specific requirements. You need to support advanced features like simulcast, bandwidth management, or custom codecs.



11. My own WebRTC test peer - https://github.com/AAlex-11/WebRTCpeer, to bo honest this is very old my project what using as responder to testing my various WebRTC program. But now I decide to publish this project as public repository.



12. Implement simple-peer as responder to Android apps:

	simple-peer (JavaScript)	WebRTC Android SDK (Java/Kotlin)
ICE Candidate Handling	Automatically gathers and manages ICE candidates.	Requires manual handling of ICE candidates using PeerConnection.Observer.
SDP Offer/Answer Exchange	Automatically generates and processes SDP offers/answers.	Requires manual creation and exchange of SDP offers/answers using PeerConnection.
Data Channels	Simplifies creating and managing WebRTC data channels.	Requires manual setup and management of DataChannel objects.
Media Streams	Supports attaching media streams but does not handle media capture.	Requires manual setup of CameraCapturer or VideoCapturer for media capture.
Error Handling	Provides basic error events but may require additional handling.	Requires manual error handling for all WebRTC events and states.
NAT Traversal	Automatically uses STUN/TURN servers if provided.	Requires manual configuration of STUN/TURN servers in PeerConnection.IceServer.
Customization	Limited customization options due to abstraction.	Full control over WebRTC behavior, including custom SDP manipulation and advanced features.
Use Case	Ideal for quick prototyping, small projects, or when simplicity is preferred.	Suitable for building native Android applications with WebRTC support.
SDP Exchange	simple-peer automatically generates and processes SDP offers/answers.	On the Android side, you need to manually create and process SDP offers/answers using the PeerConnection class.
ICE Candidate Exchange	simple-peer automatically gathers and exchanges ICE candidates.	On the Android side, you need to manually handle ICE candidates using the PeerConnection.Observer interface.
Signaling	Does not handle signaling. Both simple-peer and the WebRTC Android SDK require a signaling mechanism (e.g., WebSocket, Socket.IO, or a custom signaling server) to exchange SDP offers/answers and ICE candidates.
Data Channels and Media Streams	Both simple-peer and the WebRTC Android SDK support data channels and media streams. You need to ensure that the SDP and ICE candidates are exchanged correctly to establish a connection.



13. Free STUN servers, Helps devices discover their public IP address and port. STUN is a protocol used to discover the public IP address and port of a device behind a NAT. It helps devices determine how they are seen from the outside network, enabling them to establish direct communication with other devices. https://en.wikipedia.org/wiki/STUN

STUN Server URL	Provider	Notes
stun:stun.l.google.com:19302	Google	Reliable and widely used. Supports multiple ports (e.g., 19302, 19305).
stun:stun1.l.google.com:19302	Google	Alternate Google STUN server.
stun:stun2.l.google.com:19302	Google	Alternate Google STUN server.
stun:stun3.l.google.com:19302	Google	Alternate Google STUN server.
stun:stun4.l.google.com:19302	Google	Alternate Google STUN server.
stun:stun.voipbuster.com	VoIPBuster	Public STUN server provided by VoIPBuster.
stun:stun.voipstunt.com	VoIPStunt	Public STUN server provided by VoIPStunt.
stun:stun.ekiga.net	Ekiga	Public STUN server provided by Ekiga (open-source softphone).
stun:stun.sipgate.net	sipgate	Public STUN server provided by sipgate.
stun:stun.ideasip.com	IdeaSIP	Public STUN server provided by IdeaSIP.
stun:stun.services.mozilla.com	Mozilla	Public STUN server provided by Mozilla for WebRTC testing.
stun:stun.iptel.org	IPTel	Public STUN server provided by IPTel.
stun:stun.rixtelecom.se	Rix Telecom	Public STUN server provided by Rix Telecom.
stun:stun.schlund.de	Schlund	Public STUN server provided by Schlund Technologies.
stun:stun.voip.aebc.com	AEBC	Public STUN server provided by AEBC.
stun:stun.voiparound.com	VoIPAround	Public STUN server provided by VoIPAround.
stun:stun.voipgate.com	VoIPGate	Public STUN server provided by VoIPGate.
stun:stun.voipraider.com	VoIPRaider	Public STUN server provided by VoIPRaider.
stun:stun.voipwise.com	VoIPWise	Public STUN server provided by VoIPWise.
stun:stun.voxgratia.org	VoxGratia	Public STUN server provided by VoxGratia.
stun:stun.12connect.com	12Connect	Public STUN server provided by 12Connect.
stun:stun.12voip.com	12VoIP	Public STUN server provided by 12VoIP.
stun:stun.counterpath.com	CounterPath	Public STUN server provided by CounterPath.
stun:stun.internetcalls.com	InternetCalls	Public STUN server provided by InternetCalls.
stun:stun.voip.blackberry.com	BlackBerry	Public STUN server provided by BlackBerry (primarily for BBM calls).



14. Free TURN server for NAT traversal in cases where STUN fails. Acts as a relay when direct communication is blocked. TURN is a protocol used to relay communication between devices when direct communication is not possible due to NAT or firewall restrictions. It acts as an intermediary server, forwarding data between devices. https://en.wikipedia.org/wiki/Traversal_Using_Relays_around_NAT

TURN Server URL	Provider	Notes
turn:freeturn.net:3478	FreeTURN	Public TURN server provided by FreeTURN. May have usage limits.
turn:turn.anyfirewall.com:3478	AnyFirewall	Public TURN server provided by AnyFirewall. Requires registration for higher usage.
turn:turn.bistri.com:80	Bistri	Public TURN server provided by Bistri. May have usage limits.
turn:turn.webrtc.ecl.ntt.com:3478	NTT	Public TURN server provided by NTT. May have usage limits.
turn:turn.xten.com:3478	XTen	Public TURN server provided by XTen. May have usage limits.
turn:turn.voiparound.com:3478	VoIPAround	Public TURN server provided by VoIPAround. May have usage limits.
turn:turn.voipstunt.com:3478	VoIPStunt	Public TURN server provided by VoIPStunt. May have usage limits.
turn:turn.voip.aebc.com:3478	AEBC	Public TURN server provided by AEBC. May have usage limits.
turn:turn.voipgate.com:3478	VoIPGate	Public TURN server provided by VoIPGate. May have usage limits.
turn:turn.voipraider.com:3478	VoIPRaider	Public TURN server provided by VoIPRaider. May have usage limits.
turn:turn.voipwise.com:3478	VoIPWise	Public TURN server provided by VoIPWise. May have usage limits.
turn:turn.voxgratia.org:3478	VoxGratia	Public TURN server provided by VoxGratia. May have usage limits.
turn:turn.12connect.com:3478	12Connect	Public TURN server provided by 12Connect. May have usage limits.
turn:turn.12voip.com:3478	12VoIP	Public TURN server provided by 12VoIP. May have usage limits.
turn:turn.counterpath.com:3478	CounterPath	Public TURN server provided by CounterPath. May have usage limits.
turn:turn.internetcalls.com:3478	InternetCalls	Public TURN server provided by InternetCalls. May have usage limits.




If you're using WebRTC, you can configure TURN servers in the iceServers array of the RTCPeerConnection configuration:




   1:  const peerConnection = new RTCPeerConnection({

   2:    iceServers: [

   3:      { urls: "stun:stun.l.google.com:19302" }, // STUN server

   4:      { urls: "turn:freeturn.net:3478", username: "your-username", credential: "your-password" }, // TURN server

   5:    ],

   6:  });



15. What is NAT Traversal. https://en.wikipedia.org/wiki/NAT_traversal, NAT Traversal (Network Address Translation Traversal) is a technique used to establish and maintain communication between devices located behind NATs (Network Address Translators). NATs are commonly used in routers to allow multiple devices on a local network to share a single public IP address. NAT Traversal ensures that devices behind NATs can communicate directly with each other, even when their private IP addresses are not directly accessible from the internet.

Android context:

Front context:

Order a job

Comments ( )