**WebRTC explained / WebRTC 설명**
Page Info
Writer Joshuaa
Hit 12 Hits
Date 26-03-09 13:29
Content
**WebRTC explained / WebRTC 설명**
WebRTC는 **실시간 통신 기술**입니다. 이름 그대로 **Web Real-Time Communication**의 약자이고, 브라우저나 앱이 **오디오, 비디오, 일반 데이터**를 거의 실시간으로 주고받게 해주는 표준/기술 집합입니다. 핵심은 **플러그인 없이**, 그리고 많은 경우 **단말끼리 직접(P2P)** 연결을 시도한다는 점입니다. MDN은 WebRTC를 “오디오/비디오를 캡처하고 스트리밍하며, 중간자 없이 브라우저 간 임의 데이터도 교환할 수 있게 하는 기술”로 설명합니다. ([MDN][1])
한국어로 아주 쉽게 말하면, WebRTC는 이런 것입니다.
* 화상통화 앱의 영상/음성 연결
* 음성통화
* 화면 공유
* 브라우저끼리 파일 전송
* 채팅 메시지나 위치 같은 실시간 데이터 교환
즉, **“실시간으로 주고받는 연결”**을 만들기 위한 기술입니다. ([MDN][1])
---
## 1. WebRTC를 왜 쓰는가
보통 실시간 통신이 필요하면 서버를 거쳐 데이터를 주고받는 구조를 먼저 떠올립니다. 그런데 영상/음성은 데이터량이 크고 지연에 민감합니다. WebRTC는 이런 상황에서 **가능하면 두 사용자 사이를 직접 연결**해서 지연을 줄이고, 실시간성을 높이도록 설계되었습니다. 연결 제어의 중심은 `RTCPeerConnection`이며, 이것이 원격 피어와 연결을 만들고 유지하고 감시하고 종료하는 역할을 합니다. ([WebRTC][2])
쉽게 비유하면 이렇습니다.
* **일반 서버 중계형**: A → 서버 → B
* **WebRTC**: A ↔ B 직접 연결을 우선 시도
다만 직접 연결이 안 되면 TURN 같은 중계 서버를 사용할 수 있습니다. WebRTC 관련 프로토콜 설명에는 ICE, STUN, TURN, NAT, SDP가 핵심 요소로 소개됩니다. ([MDN][3])
---
## 2. WebRTC로 무엇을 보낼 수 있는가
WebRTC는 크게 세 종류를 다룹니다.
### 2-1. 오디오
마이크 음성을 상대방에게 보냅니다.
인터넷 전화, 음성 채팅, 음성 회의에 사용됩니다. `getUserMedia()`는 카메라와 마이크 같은 미디어 장치에서 `MediaStream`을 얻는 데 사용됩니다. ([WebRTC][2])
### 2-2. 비디오
카메라 영상이나 화면 공유 영상을 전송합니다.
WebRTC 개요 문서는 카메라/마이크는 `getUserMedia()`, 화면 캡처는 `getDisplayMedia()`로 다룬다고 설명합니다. ([WebRTC][2])
### 2-3. 일반 데이터
문자, JSON, 바이너리, 파일 조각 같은 것도 보낼 수 있습니다.
이때 쓰는 것이 `RTCDataChannel`입니다. MDN은 이를 **임의의 데이터를 양방향 peer-to-peer로 전송하는 네트워크 채널**이라고 설명합니다. ([MDN][4])
즉, WebRTC는 단순히 영상통화 전용이 아닙니다.
**실시간 데이터 통신 플랫폼**에 더 가깝습니다.
---
## 3. WebRTC 핵심 구성요소
### 3-1. Media Capture
사용자의 카메라, 마이크, 화면을 가져옵니다.
대표 API:
* `navigator.mediaDevices.getUserMedia()`
* `navigator.mediaDevices.getDisplayMedia()`
이 단계는 “무엇을 보낼 것인가”를 준비하는 단계입니다. ([WebRTC][2])
---
### 3-2. RTCPeerConnection
WebRTC의 중심입니다.
두 단말의 연결을 만들고, 유지하고, 상태를 추적하고, 협상과 ICE 처리를 담당합니다. 공식 문서에서는 원격 피어에 연결하고, 연결을 유지/모니터링하고, 더 이상 필요 없으면 닫는 인터페이스라고 설명합니다. 또한 `connectionState`로 `new`, `connecting`, `connected`, `disconnected`, `failed`, `closed` 같은 상태를 볼 수 있습니다. ([MDN][5])
이 객체가 실질적으로 하는 일은 다음과 같습니다.
* 내 미디어 트랙 추가
* 상대의 트랙 수신
* offer/answer 협상
* ICE candidate 수집 및 교환
* 데이터 채널 관리
* 연결 상태 감시
---
### 3-3. RTCDataChannel
텍스트, JSON, 바이너리 데이터 등을 주고받는 채널입니다.
채팅, 게임 상태 동기화, 간단한 파일 전송, 실시간 위치 공유, 제어 메시지 교환에 자주 씁니다. MDN에 따르면 모든 `RTCDataChannel` 데이터 전송은 DTLS로 보호되며, 자동 협상 방식과 수동 협상 방식이 있습니다. ([MDN][6])
---
### 3-4. Signaling
이 부분이 아주 중요합니다.
WebRTC는 피어끼리 직접 연결되지만, **처음 서로를 찾고 연결 조건을 협상하는 과정은 별도의 signaling 서버가 필요**합니다. MDN은 이 discovery와 negotiation 과정을 signaling이라 설명하고, 양쪽 장치가 공통의 제3 서버를 통해 서로를 찾고 협상 메시지를 교환한다고 설명합니다. ([MDN][7])
여기서 많은 초보자가 오해합니다.
**WebRTC에는 signaling 서버가 내장되어 있지 않습니다.**
즉,
* WebRTC가 음성/영상/데이터 전송을 해준다
* 그러나 처음 연결을 잡기 위한 메시지 전달은 개발자가 따로 구현해야 한다
보통 signaling에는 다음이 쓰입니다.
* WebSocket
* Firebase Realtime Database / Firestore
* Socket.IO
* 자체 HTTP + polling
* MQTT 같은 방식
앱 개발에서는 Firebase로 signaling을 구성하는 경우도 많습니다.
---
## 4. WebRTC 연결이 실제로 성립되는 과정
이 부분이 WebRTC 이해의 핵심입니다.
### 단계 1. 로컬 미디어 준비
사용자 A와 B가 카메라/마이크를 켭니다.
또는 데이터 채널만 쓸 경우 미디어 없이도 가능합니다. `getUserMedia()`로 카메라/마이크 스트림을 얻습니다. ([WebRTC][2])
### 단계 2. PeerConnection 생성
양쪽이 `RTCPeerConnection`을 만듭니다.
여기서 STUN/TURN 서버 설정도 같이 넣습니다. ICE, STUN, TURN은 NAT 환경에서 연결 경로를 찾기 위한 핵심 요소입니다. ([MDN][3])
### 단계 3. 트랙 추가 또는 DataChannel 생성
* 영상통화면 오디오/비디오 트랙 추가
* 채팅/파일 전송이면 `createDataChannel()` 사용
`createDataChannel()`은 상대방에게 연결된 데이터 채널을 생성하도록 협상할 수 있습니다. 상대는 `datachannel` 이벤트로 이를 받습니다. ([MDN][6])
### 단계 4. Offer 생성
A가 SDP offer를 생성합니다.
SDP는 미디어 형식, 코덱, 연결 정보 등 세션 설명을 담는 형식이며, WebRTC 관련 프로토콜 설명에서도 핵심 항목으로 제시됩니다. ([MDN][3])
### 단계 5. Signaling 서버로 offer 전달
A가 offer를 WebSocket이나 Firebase 같은 signaling 경로로 B에게 보냅니다. signaling은 제3 서버를 통해 negotiation 메시지를 교환하는 과정입니다. ([MDN][7])
### 단계 6. Answer 생성
B는 offer를 받고 answer를 생성해서 다시 signaling 서버를 통해 A에게 돌려보냅니다.
### 단계 7. ICE candidate 교환
양쪽은 연결 가능한 네트워크 후보 주소를 찾습니다. 이 후보가 ICE candidate입니다.
MDN은 `icecandidate` 이벤트가 발생하면 그 candidate를 signaling 채널을 통해 상대에게 보내고, 상대는 `addIceCandidate()`로 추가해야 한다고 설명합니다. ([MDN][8])
### 단계 8. 연결 성립
적절한 경로가 선택되면 P2P 또는 TURN 릴레이 경로로 연결됩니다.
---
## 5. 어려운 용어를 쉽게 정리
### 5-1. SDP
Session Description Protocol
“나는 이런 코덱을 지원하고, 이런 미디어를 보내고 싶고, 이런 연결 정보가 있다”를 설명하는 교환 문서 같은 것입니다. WebRTC 프로토콜 소개에서 SDP는 핵심 요소로 다뤄집니다. ([MDN][3])
---
### 5-2. ICE
Interactive Connectivity Establishment
양쪽이 서로 통신 가능한 최적 경로를 찾는 절차입니다. 어떤 주소로 연결 가능한지 여러 후보를 모아 시험합니다. WebRTC 프로토콜 설명의 핵심입니다. ([MDN][3])
---
### 5-3. STUN
단말이 “내가 인터넷에서 어떻게 보이는지”를 알아내도록 도와주는 서버입니다.
즉, NAT 뒤에 있는 자신의 외부 주소 후보를 찾는 데 도움을 줍니다. WebRTC 프로토콜 소개에 포함됩니다. ([MDN][3])
---
### 5-4. TURN
직접 연결이 안 될 때 데이터를 대신 중계해주는 서버입니다.
TURN을 쓰면 연결 성공률은 올라가지만, 트래픽 비용과 서버 부담이 증가합니다. TURN 역시 WebRTC 프로토콜 핵심 요소입니다. ([MDN][3])
---
### 5-5. NAT
집/회사/모바일망의 라우터 환경 때문에 단말이 직접 보이지 않는 문제입니다.
WebRTC가 어려운 가장 큰 이유 중 하나가 바로 NAT traversal입니다. WebRTC 프로토콜 문서는 NAT를 주요 개념으로 다룹니다. ([MDN][3])
---
## 6. WebRTC는 완전한 P2P인가
많은 경우 **P2P를 우선 시도**하지만, 항상 완전한 직접 연결이 되는 것은 아닙니다.
실제로는:
* signaling 서버는 거의 항상 필요
* STUN 서버도 거의 필요
* 직접 연결 실패 시 TURN 서버가 필요할 수 있음
즉, “브라우저끼리 바로 다 된다”는 말은 절반만 맞습니다.
**실시간 미디어/데이터는 P2P가 가능하지만, 연결 성립을 위한 주변 인프라는 따로 필요**합니다. signaling은 별도 서버를 통해 이루어진다고 MDN이 분명히 설명합니다. ([MDN][7])
---
## 7. WebRTC의 장점
### 7-1. 지연이 낮다
영상통화, 음성채팅, 실시간 제어는 지연이 가장 중요합니다. WebRTC는 이런 목적에 맞게 설계되었습니다. WebRTC는 실시간 peer-to-peer 미디어 교환 기술로 설명됩니다. ([MDN][7])
### 7-2. 브라우저 표준
플러그인 설치 없이 최신 브라우저에서 널리 지원됩니다. MDN은 WebRTC 기능이 브라우저에서 플러그인 없이 동작하는 기술 집합이라고 설명합니다. ([MDN][1])
### 7-3. 보안 기본 적용
데이터 채널은 DTLS로 보호되며, WebRTC 구성요소는 암호화를 요구합니다. MDN은 모든 WebRTC 컴포넌트가 암호화를 사용하며, `RTCDataChannel` 전송은 자동으로 DTLS로 보호된다고 설명합니다. ([MDN][6])
### 7-4. 서버 대역폭 절감 가능
P2P 직결이 성립하면 미디어가 중앙 서버를 계속 통과하지 않으므로 서버 부담이 줄 수 있습니다. 다만 TURN 사용이 늘면 이 장점은 줄어듭니다. 이 점은 ICE/STUN/TURN 구조에서 자연스럽게 도출되는 설명입니다. ([MDN][3])
---
## 8. WebRTC의 단점과 어려운 점
### 8-1. 구현이 쉽지 않다
처음 보면 API 몇 개로 끝날 것 같지만 실제로는 어렵습니다.
왜냐하면:
* signaling 직접 구현
* ICE candidate 처리
* NAT/방화벽 문제
* 기기/브라우저별 호환성
* 재연결 처리
* TURN 비용 문제
이런 운영 이슈가 많기 때문입니다. signaling, ICE, STUN, TURN이 따로 존재한다는 사실 자체가 복잡성을 보여줍니다. ([MDN][7])
### 8-2. 그룹 통화는 더 어렵다
1:1은 비교적 단순하지만 다자간 통화는 구조가 달라집니다.
WebRTC 프로토콜 문서에서도 multi-party video conferencing을 별도 주제로 다룹니다. 보통은 SFU/MCU 서버가 필요해집니다. ([MDN][3])
### 8-3. TURN 비용
직접 연결이 자주 실패하는 환경이면 TURN 트래픽 비용이 커질 수 있습니다. 특히 영상은 대역폭을 많이 씁니다. 이 점은 TURN이 릴레이 역할을 한다는 구조에서 따라옵니다. ([MDN][3])
---
## 9. WebRTC와 WebSocket의 차이
이 둘을 많이 헷갈립니다.
### WebSocket
* 클라이언트 ↔ 서버 지속 연결
* 서버를 통해 데이터 송수신
* 채팅, 상태 동기화, 알림 등에 좋음
* 구현이 비교적 단순
### WebRTC
* 실시간 오디오/비디오/데이터용
* 피어 간 직접 연결을 우선 시도
* NAT traversal, ICE, STUN, TURN 필요
* 구현 난이도가 더 높음
아주 단순하게 말하면:
* **채팅 텍스트만**: WebSocket이 보통 더 단순
* **영상/음성/화면공유**: WebRTC가 핵심
* **실시간 P2P 데이터 전송**: WebRTC DataChannel이 유리할 수 있음
Signaling 자체는 WebRTC가 제공하지 않으므로, 실제 서비스에서는 **WebRTC + WebSocket** 조합이 매우 흔합니다. signaling이 별도의 서버를 통해 이루어진다는 공식 설명이 이를 뒷받침합니다. ([MDN][7])
---
## 10. 안드로이드 앱 개발 관점에서 WebRTC
당신처럼 앱을 만드는 입장에서 가장 중요한 부분입니다.
WebRTC는 “웹 브라우저 기술”이라는 이름 때문에 웹 전용처럼 보이지만, 실제로는 **안드로이드/모바일 앱에서도 많이 사용**됩니다. 앱에서는 보통 네이티브 WebRTC 라이브러리를 씁니다.
### 안드로이드에서 활용 예
* 위치추적 앱에서 보호자와 피보호자 간 **즉시 음성 연결**
* 긴급 상황에서 **실시간 영상 확인**
* **실시간 위치 + 음성/영상** 결합
* 앱 내부 채팅이나 알림과 별도로 **저지연 데이터 채널** 구성
* PTT(push-to-talk) 스타일 기능
* 현장 확인용 화면/카메라 공유
특히 geofence 앱과 엮으면 다음 같은 구조를 생각할 수 있습니다.
* geofence 이탈 발생
* FCM 또는 자체 알림 발송
* 보호자 앱이 대상자 앱에 접속 요청
* signaling 서버로 offer/answer 교환
* 필요 시 WebRTC로 음성/영상 연결 시작
즉, **위치 이벤트를 트리거로 해서 실시간 연결로 넘어가는 구조**가 가능합니다.
---
## 11. 위치추적 앱에서 WebRTC를 쓰면 좋은 경우
당신 상황에 맞춰 구체적으로 설명하면:
### 좋은 경우
1. **긴급 확인이 필요할 때**
* geofence 이탈
* SOS 버튼
* 일정 시간 위치 정지/비정상 이동
* 보호자가 즉시 음성/영상 확인
2. **실시간 음성 대화가 중요할 때**
* 서버 중계형보다 지연이 낮은 편
* 빠른 반응이 중요할 때 적합
3. **데이터 채널로 상태를 같이 보낼 때**
* 현재 속도
* 배터리 상태
* 위치 정확도
* 간단한 센서 이벤트
* JSON 형태 메시지
`RTCDataChannel`은 임의 데이터의 양방향 전송용 채널이므로 이런 상태 데이터와 잘 맞습니다. ([MDN][4])
---
## 12. 위치추적 앱에서 WebRTC를 바로 넣기 어려운 이유
하지만 무조건 좋은 것은 아닙니다.
### 12-1. 백그라운드 제약
안드로이드에서는 백그라운드에서 카메라/마이크/네트워크를 다루는 데 제약이 많습니다.
실시간 호출 기능은 포그라운드 서비스, 알림, 사용자 동작 흐름 설계가 중요합니다.
### 12-2. 배터리 사용량
영상/음성 실시간 연결은 배터리를 씁니다.
위치 추적도 배터리를 쓰는데 WebRTC까지 더하면 부담이 커질 수 있습니다.
### 12-3. TURN 비용
실제 사용자가 이동통신망, 회사 와이파이, 공용망을 쓰면 직접 연결이 잘 안 되는 경우가 있어 TURN 의존도가 높아질 수 있습니다.
### 12-4. 수익 모델과 직접 연결되지 않음
AdMob 중심 수익화 앱이라면 WebRTC는 기능 강화에는 좋지만, 구현 복잡도와 운영비가 증가할 수 있습니다.
즉, **매출 직접 효과보다 비용/복잡도 상승이 먼저 오는 경우**가 많습니다.
그래서 앱 초반에는 흔히 이렇게 갑니다.
1. 위치 추적/알림 안정화
2. geofence 정확도 개선
3. 배터리 최적화
4. 광고 흐름 안정화
5. 그 다음 WebRTC 음성/영상 기능 추가
이 순서가 현실적입니다.
---
## 13. WebRTC의 내부 기술을 조금 더 기술적으로
이 부분은 개발자 시각으로 보겠습니다.
WebRTC는 단일 API 하나가 아니라 여러 기술을 묶은 것입니다.
* 미디어 캡처
* 코덱 협상
* 보안 전송
* 연결 협상
* 네트워크 후보 탐색
* 데이터 채널 전송
MDN은 WebRTC의 기반 프로토콜로 ICE, STUN, TURN, NAT, SDP를 소개합니다. 또한 `RTCDataChannel`은 암호화되어 전송되고, `RTCPeerConnection`은 상태 관리와 연결 제어의 중심입니다. ([MDN][3])
실무에서 보면 중요 포인트는 다음입니다.
* **Offer/Answer 모델**
* **Trickle ICE**
* **연결 상태 감시**
* **재협상**
* **코덱 호환**
* **TURN fallback**
* **media track lifecycle 관리**
특히 `icecandidate` 이벤트는 매우 중요합니다. 새 ICE candidate가 생성될 때마다 signaling 경로로 상대에게 보내야 하고, 상대는 이를 추가해야 합니다. MDN이 이 동작을 명시합니다. ([MDN][8])
---
## 14. 아주 단순한 개념 흐름도
텍스트로 그려보면 이렇습니다.
### 1:1 영상통화
1. A와 B가 앱 실행
2. A가 통화 요청
3. signaling 서버를 통해 A의 offer 전달
4. B가 answer 생성 후 전달
5. 양쪽이 ICE candidate 교환
6. P2P 또는 TURN 경유 연결 성립
7. 오디오/비디오 송수신 시작
### DataChannel 채팅/파일 전송
1. A가 `createDataChannel()` 호출
2. 상대방은 `datachannel` 이벤트로 채널 수신
3. 연결 성립 후 문자열/JSON/바이너리 송수신
4. 모든 전송은 암호화됨
이 동작은 MDN data channel 및 signaling 설명과 일치합니다. ([MDN][6])
---
## 15. WebRTC를 쓸지 말지 판단 기준
### 써야 하는 경우
* 영상통화가 핵심
* 음성통화가 핵심
* 화면 공유 필요
* 초저지연이 중요
* P2P 데이터 전달이 중요
### 굳이 안 써도 되는 경우
* 단순 채팅
* 일반 푸시 알림
* 서버 저장형 메시지
* 지연에 크게 민감하지 않은 상태 동기화
* 파일 업로드/다운로드 정도만 필요
즉, **“실시간성”과 “미디어 통신”이 핵심이면 WebRTC**입니다.
---
## 16. 초보 개발자가 자주 하는 오해
### 오해 1. WebRTC가 있으면 서버가 아예 필요 없다
아닙니다. signaling 서버가 필요하고, TURN도 필요할 수 있습니다. ([MDN][7])
### 오해 2. 영상통화만 하는 기술이다
아닙니다. 데이터 채널도 강력합니다. `RTCDataChannel`은 임의 데이터를 양방향으로 주고받는 채널입니다. ([MDN][4])
### 오해 3. 브라우저에서만 된다
이름은 WebRTC지만 모바일 앱/네이티브 환경에서도 많이 씁니다. 다만 구현 방식은 라이브러리 레벨에서 달라집니다.
### 오해 4. 연결만 되면 끝이다
실제 서비스는 재연결, 품질 저하 대응, 네트워크 전환, 권한 처리, 배터리, UI/UX, 통화 수명주기 관리가 중요합니다.
---
## 17. 당신에게 맞춘 현실적인 해석
지금 당신이 **위치추적앱 + geofence + AdMob** 쪽이라면, WebRTC는 “핵심 기본 기능”이라기보다 **고급 실시간 기능**입니다.
가장 현실적인 적용 순서는 이런 식입니다.
### 1단계
* 위치 수집 안정화
* geofence 진입/이탈 정확도 개선
* 백그라운드 제약 대응
* 배터리 최적화
* 알림 흐름 안정화
### 2단계
* 보호자/관리자 실시간 확인 기능 추가
* 우선 음성 통화부터
* 이후 영상 확장
### 3단계
* DataChannel로 부가 상태 데이터 전송
* 예: SOS, 배터리, GPS 정확도, 이동 상태, 네트워크 상태
이렇게 가면 구현 난이도를 통제하기 좋습니다.
---
## 18. 한 문장으로 정리
**WebRTC는 브라우저나 앱에서 오디오, 비디오, 일반 데이터를 실시간으로 주고받기 위한 기술이며, `RTCPeerConnection`을 중심으로 signaling, ICE, STUN, TURN, SDP 같은 요소를 이용해 두 피어의 직접 연결을 시도하는 구조**입니다. ([MDN][1])
---
## 19. 영어 / English
**WebRTC is a real-time communication technology that allows browsers and apps to exchange audio, video, and arbitrary data, usually by attempting a peer-to-peer connection. It relies on APIs such as `RTCPeerConnection`, media capture APIs like `getUserMedia()`, and supporting mechanisms such as signaling, ICE, STUN, TURN, and SDP.** ([MDN][1])
---
## 20. 일본어 / 日本語
**WebRTC は、ブラウザやアプリで音声・映像・任意のデータをリアルタイムにやり取りするための技術です。通常は P2P 接続を試み、`RTCPeerConnection`、`getUserMedia()`、そして signaling、ICE、STUN、TURN、SDP などの仕組みによって接続を成立させます。** ([MDN][1])
---
## 21. 스페인어 / Español
**WebRTC es una tecnología de comunicación en tiempo real que permite a navegadores y aplicaciones intercambiar audio, video y datos arbitrarios, normalmente intentando una conexión peer-to-peer. Se apoya en `RTCPeerConnection`, en APIs de captura como `getUserMedia()`, y en mecanismos como signaling, ICE, STUN, TURN y SDP.** ([MDN][1])
---
## 22. 프랑스어 / Français
**WebRTC est une technologie de communication en temps réel qui permet aux navigateurs et aux applications d’échanger de l’audio, de la vidéo et des données arbitraires, généralement en essayant une connexion pair à pair. Elle repose sur `RTCPeerConnection`, sur des API de capture comme `getUserMedia()`, ainsi que sur des mécanismes comme le signaling, ICE, STUN, TURN et SDP.** ([MDN][1])
다음 단계로 이해해야 할 핵심은 **“WebRTC 자체”보다 “signaling과 ICE 처리”**입니다. WebRTC를 처음 공부할 때 대부분 막히는 지점이 바로 그 부분입니다.
[1]: https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API?utm_source=chatgpt.com "WebRTC API - MDN Web Docs - Mozilla"
[2]: https://webrtc.org/getting-started/overview?utm_source=chatgpt.com "Getting started with WebRTC"
[3]: https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API/Protocols?utm_source=chatgpt.com "Introduction to WebRTC protocols - Web APIs - MDN - Mozilla"
[4]: https://developer.mozilla.org/en-US/docs/Web/API/RTCDataChannel?utm_source=chatgpt.com "RTCDataChannel - Web APIs | MDN - Mozilla"
[5]: https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection?utm_source=chatgpt.com "RTCPeerConnection - Web APIs | MDN"
[6]: https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API/Using_data_channels?utm_source=chatgpt.com "Using WebRTC data channels - Web APIs | MDN - Mozilla"
[7]: https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API/Signaling_and_video_calling?utm_source=chatgpt.com "Signaling and video calling - WebRTC API - MDN"
[8]: https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/icecandidate_event?utm_source=chatgpt.com "RTCPeerConnection: icecandidate event - Web APIs - MDN"
WebRTC는 **실시간 통신 기술**입니다. 이름 그대로 **Web Real-Time Communication**의 약자이고, 브라우저나 앱이 **오디오, 비디오, 일반 데이터**를 거의 실시간으로 주고받게 해주는 표준/기술 집합입니다. 핵심은 **플러그인 없이**, 그리고 많은 경우 **단말끼리 직접(P2P)** 연결을 시도한다는 점입니다. MDN은 WebRTC를 “오디오/비디오를 캡처하고 스트리밍하며, 중간자 없이 브라우저 간 임의 데이터도 교환할 수 있게 하는 기술”로 설명합니다. ([MDN][1])
한국어로 아주 쉽게 말하면, WebRTC는 이런 것입니다.
* 화상통화 앱의 영상/음성 연결
* 음성통화
* 화면 공유
* 브라우저끼리 파일 전송
* 채팅 메시지나 위치 같은 실시간 데이터 교환
즉, **“실시간으로 주고받는 연결”**을 만들기 위한 기술입니다. ([MDN][1])
---
## 1. WebRTC를 왜 쓰는가
보통 실시간 통신이 필요하면 서버를 거쳐 데이터를 주고받는 구조를 먼저 떠올립니다. 그런데 영상/음성은 데이터량이 크고 지연에 민감합니다. WebRTC는 이런 상황에서 **가능하면 두 사용자 사이를 직접 연결**해서 지연을 줄이고, 실시간성을 높이도록 설계되었습니다. 연결 제어의 중심은 `RTCPeerConnection`이며, 이것이 원격 피어와 연결을 만들고 유지하고 감시하고 종료하는 역할을 합니다. ([WebRTC][2])
쉽게 비유하면 이렇습니다.
* **일반 서버 중계형**: A → 서버 → B
* **WebRTC**: A ↔ B 직접 연결을 우선 시도
다만 직접 연결이 안 되면 TURN 같은 중계 서버를 사용할 수 있습니다. WebRTC 관련 프로토콜 설명에는 ICE, STUN, TURN, NAT, SDP가 핵심 요소로 소개됩니다. ([MDN][3])
---
## 2. WebRTC로 무엇을 보낼 수 있는가
WebRTC는 크게 세 종류를 다룹니다.
### 2-1. 오디오
마이크 음성을 상대방에게 보냅니다.
인터넷 전화, 음성 채팅, 음성 회의에 사용됩니다. `getUserMedia()`는 카메라와 마이크 같은 미디어 장치에서 `MediaStream`을 얻는 데 사용됩니다. ([WebRTC][2])
### 2-2. 비디오
카메라 영상이나 화면 공유 영상을 전송합니다.
WebRTC 개요 문서는 카메라/마이크는 `getUserMedia()`, 화면 캡처는 `getDisplayMedia()`로 다룬다고 설명합니다. ([WebRTC][2])
### 2-3. 일반 데이터
문자, JSON, 바이너리, 파일 조각 같은 것도 보낼 수 있습니다.
이때 쓰는 것이 `RTCDataChannel`입니다. MDN은 이를 **임의의 데이터를 양방향 peer-to-peer로 전송하는 네트워크 채널**이라고 설명합니다. ([MDN][4])
즉, WebRTC는 단순히 영상통화 전용이 아닙니다.
**실시간 데이터 통신 플랫폼**에 더 가깝습니다.
---
## 3. WebRTC 핵심 구성요소
### 3-1. Media Capture
사용자의 카메라, 마이크, 화면을 가져옵니다.
대표 API:
* `navigator.mediaDevices.getUserMedia()`
* `navigator.mediaDevices.getDisplayMedia()`
이 단계는 “무엇을 보낼 것인가”를 준비하는 단계입니다. ([WebRTC][2])
---
### 3-2. RTCPeerConnection
WebRTC의 중심입니다.
두 단말의 연결을 만들고, 유지하고, 상태를 추적하고, 협상과 ICE 처리를 담당합니다. 공식 문서에서는 원격 피어에 연결하고, 연결을 유지/모니터링하고, 더 이상 필요 없으면 닫는 인터페이스라고 설명합니다. 또한 `connectionState`로 `new`, `connecting`, `connected`, `disconnected`, `failed`, `closed` 같은 상태를 볼 수 있습니다. ([MDN][5])
이 객체가 실질적으로 하는 일은 다음과 같습니다.
* 내 미디어 트랙 추가
* 상대의 트랙 수신
* offer/answer 협상
* ICE candidate 수집 및 교환
* 데이터 채널 관리
* 연결 상태 감시
---
### 3-3. RTCDataChannel
텍스트, JSON, 바이너리 데이터 등을 주고받는 채널입니다.
채팅, 게임 상태 동기화, 간단한 파일 전송, 실시간 위치 공유, 제어 메시지 교환에 자주 씁니다. MDN에 따르면 모든 `RTCDataChannel` 데이터 전송은 DTLS로 보호되며, 자동 협상 방식과 수동 협상 방식이 있습니다. ([MDN][6])
---
### 3-4. Signaling
이 부분이 아주 중요합니다.
WebRTC는 피어끼리 직접 연결되지만, **처음 서로를 찾고 연결 조건을 협상하는 과정은 별도의 signaling 서버가 필요**합니다. MDN은 이 discovery와 negotiation 과정을 signaling이라 설명하고, 양쪽 장치가 공통의 제3 서버를 통해 서로를 찾고 협상 메시지를 교환한다고 설명합니다. ([MDN][7])
여기서 많은 초보자가 오해합니다.
**WebRTC에는 signaling 서버가 내장되어 있지 않습니다.**
즉,
* WebRTC가 음성/영상/데이터 전송을 해준다
* 그러나 처음 연결을 잡기 위한 메시지 전달은 개발자가 따로 구현해야 한다
보통 signaling에는 다음이 쓰입니다.
* WebSocket
* Firebase Realtime Database / Firestore
* Socket.IO
* 자체 HTTP + polling
* MQTT 같은 방식
앱 개발에서는 Firebase로 signaling을 구성하는 경우도 많습니다.
---
## 4. WebRTC 연결이 실제로 성립되는 과정
이 부분이 WebRTC 이해의 핵심입니다.
### 단계 1. 로컬 미디어 준비
사용자 A와 B가 카메라/마이크를 켭니다.
또는 데이터 채널만 쓸 경우 미디어 없이도 가능합니다. `getUserMedia()`로 카메라/마이크 스트림을 얻습니다. ([WebRTC][2])
### 단계 2. PeerConnection 생성
양쪽이 `RTCPeerConnection`을 만듭니다.
여기서 STUN/TURN 서버 설정도 같이 넣습니다. ICE, STUN, TURN은 NAT 환경에서 연결 경로를 찾기 위한 핵심 요소입니다. ([MDN][3])
### 단계 3. 트랙 추가 또는 DataChannel 생성
* 영상통화면 오디오/비디오 트랙 추가
* 채팅/파일 전송이면 `createDataChannel()` 사용
`createDataChannel()`은 상대방에게 연결된 데이터 채널을 생성하도록 협상할 수 있습니다. 상대는 `datachannel` 이벤트로 이를 받습니다. ([MDN][6])
### 단계 4. Offer 생성
A가 SDP offer를 생성합니다.
SDP는 미디어 형식, 코덱, 연결 정보 등 세션 설명을 담는 형식이며, WebRTC 관련 프로토콜 설명에서도 핵심 항목으로 제시됩니다. ([MDN][3])
### 단계 5. Signaling 서버로 offer 전달
A가 offer를 WebSocket이나 Firebase 같은 signaling 경로로 B에게 보냅니다. signaling은 제3 서버를 통해 negotiation 메시지를 교환하는 과정입니다. ([MDN][7])
### 단계 6. Answer 생성
B는 offer를 받고 answer를 생성해서 다시 signaling 서버를 통해 A에게 돌려보냅니다.
### 단계 7. ICE candidate 교환
양쪽은 연결 가능한 네트워크 후보 주소를 찾습니다. 이 후보가 ICE candidate입니다.
MDN은 `icecandidate` 이벤트가 발생하면 그 candidate를 signaling 채널을 통해 상대에게 보내고, 상대는 `addIceCandidate()`로 추가해야 한다고 설명합니다. ([MDN][8])
### 단계 8. 연결 성립
적절한 경로가 선택되면 P2P 또는 TURN 릴레이 경로로 연결됩니다.
---
## 5. 어려운 용어를 쉽게 정리
### 5-1. SDP
Session Description Protocol
“나는 이런 코덱을 지원하고, 이런 미디어를 보내고 싶고, 이런 연결 정보가 있다”를 설명하는 교환 문서 같은 것입니다. WebRTC 프로토콜 소개에서 SDP는 핵심 요소로 다뤄집니다. ([MDN][3])
---
### 5-2. ICE
Interactive Connectivity Establishment
양쪽이 서로 통신 가능한 최적 경로를 찾는 절차입니다. 어떤 주소로 연결 가능한지 여러 후보를 모아 시험합니다. WebRTC 프로토콜 설명의 핵심입니다. ([MDN][3])
---
### 5-3. STUN
단말이 “내가 인터넷에서 어떻게 보이는지”를 알아내도록 도와주는 서버입니다.
즉, NAT 뒤에 있는 자신의 외부 주소 후보를 찾는 데 도움을 줍니다. WebRTC 프로토콜 소개에 포함됩니다. ([MDN][3])
---
### 5-4. TURN
직접 연결이 안 될 때 데이터를 대신 중계해주는 서버입니다.
TURN을 쓰면 연결 성공률은 올라가지만, 트래픽 비용과 서버 부담이 증가합니다. TURN 역시 WebRTC 프로토콜 핵심 요소입니다. ([MDN][3])
---
### 5-5. NAT
집/회사/모바일망의 라우터 환경 때문에 단말이 직접 보이지 않는 문제입니다.
WebRTC가 어려운 가장 큰 이유 중 하나가 바로 NAT traversal입니다. WebRTC 프로토콜 문서는 NAT를 주요 개념으로 다룹니다. ([MDN][3])
---
## 6. WebRTC는 완전한 P2P인가
많은 경우 **P2P를 우선 시도**하지만, 항상 완전한 직접 연결이 되는 것은 아닙니다.
실제로는:
* signaling 서버는 거의 항상 필요
* STUN 서버도 거의 필요
* 직접 연결 실패 시 TURN 서버가 필요할 수 있음
즉, “브라우저끼리 바로 다 된다”는 말은 절반만 맞습니다.
**실시간 미디어/데이터는 P2P가 가능하지만, 연결 성립을 위한 주변 인프라는 따로 필요**합니다. signaling은 별도 서버를 통해 이루어진다고 MDN이 분명히 설명합니다. ([MDN][7])
---
## 7. WebRTC의 장점
### 7-1. 지연이 낮다
영상통화, 음성채팅, 실시간 제어는 지연이 가장 중요합니다. WebRTC는 이런 목적에 맞게 설계되었습니다. WebRTC는 실시간 peer-to-peer 미디어 교환 기술로 설명됩니다. ([MDN][7])
### 7-2. 브라우저 표준
플러그인 설치 없이 최신 브라우저에서 널리 지원됩니다. MDN은 WebRTC 기능이 브라우저에서 플러그인 없이 동작하는 기술 집합이라고 설명합니다. ([MDN][1])
### 7-3. 보안 기본 적용
데이터 채널은 DTLS로 보호되며, WebRTC 구성요소는 암호화를 요구합니다. MDN은 모든 WebRTC 컴포넌트가 암호화를 사용하며, `RTCDataChannel` 전송은 자동으로 DTLS로 보호된다고 설명합니다. ([MDN][6])
### 7-4. 서버 대역폭 절감 가능
P2P 직결이 성립하면 미디어가 중앙 서버를 계속 통과하지 않으므로 서버 부담이 줄 수 있습니다. 다만 TURN 사용이 늘면 이 장점은 줄어듭니다. 이 점은 ICE/STUN/TURN 구조에서 자연스럽게 도출되는 설명입니다. ([MDN][3])
---
## 8. WebRTC의 단점과 어려운 점
### 8-1. 구현이 쉽지 않다
처음 보면 API 몇 개로 끝날 것 같지만 실제로는 어렵습니다.
왜냐하면:
* signaling 직접 구현
* ICE candidate 처리
* NAT/방화벽 문제
* 기기/브라우저별 호환성
* 재연결 처리
* TURN 비용 문제
이런 운영 이슈가 많기 때문입니다. signaling, ICE, STUN, TURN이 따로 존재한다는 사실 자체가 복잡성을 보여줍니다. ([MDN][7])
### 8-2. 그룹 통화는 더 어렵다
1:1은 비교적 단순하지만 다자간 통화는 구조가 달라집니다.
WebRTC 프로토콜 문서에서도 multi-party video conferencing을 별도 주제로 다룹니다. 보통은 SFU/MCU 서버가 필요해집니다. ([MDN][3])
### 8-3. TURN 비용
직접 연결이 자주 실패하는 환경이면 TURN 트래픽 비용이 커질 수 있습니다. 특히 영상은 대역폭을 많이 씁니다. 이 점은 TURN이 릴레이 역할을 한다는 구조에서 따라옵니다. ([MDN][3])
---
## 9. WebRTC와 WebSocket의 차이
이 둘을 많이 헷갈립니다.
### WebSocket
* 클라이언트 ↔ 서버 지속 연결
* 서버를 통해 데이터 송수신
* 채팅, 상태 동기화, 알림 등에 좋음
* 구현이 비교적 단순
### WebRTC
* 실시간 오디오/비디오/데이터용
* 피어 간 직접 연결을 우선 시도
* NAT traversal, ICE, STUN, TURN 필요
* 구현 난이도가 더 높음
아주 단순하게 말하면:
* **채팅 텍스트만**: WebSocket이 보통 더 단순
* **영상/음성/화면공유**: WebRTC가 핵심
* **실시간 P2P 데이터 전송**: WebRTC DataChannel이 유리할 수 있음
Signaling 자체는 WebRTC가 제공하지 않으므로, 실제 서비스에서는 **WebRTC + WebSocket** 조합이 매우 흔합니다. signaling이 별도의 서버를 통해 이루어진다는 공식 설명이 이를 뒷받침합니다. ([MDN][7])
---
## 10. 안드로이드 앱 개발 관점에서 WebRTC
당신처럼 앱을 만드는 입장에서 가장 중요한 부분입니다.
WebRTC는 “웹 브라우저 기술”이라는 이름 때문에 웹 전용처럼 보이지만, 실제로는 **안드로이드/모바일 앱에서도 많이 사용**됩니다. 앱에서는 보통 네이티브 WebRTC 라이브러리를 씁니다.
### 안드로이드에서 활용 예
* 위치추적 앱에서 보호자와 피보호자 간 **즉시 음성 연결**
* 긴급 상황에서 **실시간 영상 확인**
* **실시간 위치 + 음성/영상** 결합
* 앱 내부 채팅이나 알림과 별도로 **저지연 데이터 채널** 구성
* PTT(push-to-talk) 스타일 기능
* 현장 확인용 화면/카메라 공유
특히 geofence 앱과 엮으면 다음 같은 구조를 생각할 수 있습니다.
* geofence 이탈 발생
* FCM 또는 자체 알림 발송
* 보호자 앱이 대상자 앱에 접속 요청
* signaling 서버로 offer/answer 교환
* 필요 시 WebRTC로 음성/영상 연결 시작
즉, **위치 이벤트를 트리거로 해서 실시간 연결로 넘어가는 구조**가 가능합니다.
---
## 11. 위치추적 앱에서 WebRTC를 쓰면 좋은 경우
당신 상황에 맞춰 구체적으로 설명하면:
### 좋은 경우
1. **긴급 확인이 필요할 때**
* geofence 이탈
* SOS 버튼
* 일정 시간 위치 정지/비정상 이동
* 보호자가 즉시 음성/영상 확인
2. **실시간 음성 대화가 중요할 때**
* 서버 중계형보다 지연이 낮은 편
* 빠른 반응이 중요할 때 적합
3. **데이터 채널로 상태를 같이 보낼 때**
* 현재 속도
* 배터리 상태
* 위치 정확도
* 간단한 센서 이벤트
* JSON 형태 메시지
`RTCDataChannel`은 임의 데이터의 양방향 전송용 채널이므로 이런 상태 데이터와 잘 맞습니다. ([MDN][4])
---
## 12. 위치추적 앱에서 WebRTC를 바로 넣기 어려운 이유
하지만 무조건 좋은 것은 아닙니다.
### 12-1. 백그라운드 제약
안드로이드에서는 백그라운드에서 카메라/마이크/네트워크를 다루는 데 제약이 많습니다.
실시간 호출 기능은 포그라운드 서비스, 알림, 사용자 동작 흐름 설계가 중요합니다.
### 12-2. 배터리 사용량
영상/음성 실시간 연결은 배터리를 씁니다.
위치 추적도 배터리를 쓰는데 WebRTC까지 더하면 부담이 커질 수 있습니다.
### 12-3. TURN 비용
실제 사용자가 이동통신망, 회사 와이파이, 공용망을 쓰면 직접 연결이 잘 안 되는 경우가 있어 TURN 의존도가 높아질 수 있습니다.
### 12-4. 수익 모델과 직접 연결되지 않음
AdMob 중심 수익화 앱이라면 WebRTC는 기능 강화에는 좋지만, 구현 복잡도와 운영비가 증가할 수 있습니다.
즉, **매출 직접 효과보다 비용/복잡도 상승이 먼저 오는 경우**가 많습니다.
그래서 앱 초반에는 흔히 이렇게 갑니다.
1. 위치 추적/알림 안정화
2. geofence 정확도 개선
3. 배터리 최적화
4. 광고 흐름 안정화
5. 그 다음 WebRTC 음성/영상 기능 추가
이 순서가 현실적입니다.
---
## 13. WebRTC의 내부 기술을 조금 더 기술적으로
이 부분은 개발자 시각으로 보겠습니다.
WebRTC는 단일 API 하나가 아니라 여러 기술을 묶은 것입니다.
* 미디어 캡처
* 코덱 협상
* 보안 전송
* 연결 협상
* 네트워크 후보 탐색
* 데이터 채널 전송
MDN은 WebRTC의 기반 프로토콜로 ICE, STUN, TURN, NAT, SDP를 소개합니다. 또한 `RTCDataChannel`은 암호화되어 전송되고, `RTCPeerConnection`은 상태 관리와 연결 제어의 중심입니다. ([MDN][3])
실무에서 보면 중요 포인트는 다음입니다.
* **Offer/Answer 모델**
* **Trickle ICE**
* **연결 상태 감시**
* **재협상**
* **코덱 호환**
* **TURN fallback**
* **media track lifecycle 관리**
특히 `icecandidate` 이벤트는 매우 중요합니다. 새 ICE candidate가 생성될 때마다 signaling 경로로 상대에게 보내야 하고, 상대는 이를 추가해야 합니다. MDN이 이 동작을 명시합니다. ([MDN][8])
---
## 14. 아주 단순한 개념 흐름도
텍스트로 그려보면 이렇습니다.
### 1:1 영상통화
1. A와 B가 앱 실행
2. A가 통화 요청
3. signaling 서버를 통해 A의 offer 전달
4. B가 answer 생성 후 전달
5. 양쪽이 ICE candidate 교환
6. P2P 또는 TURN 경유 연결 성립
7. 오디오/비디오 송수신 시작
### DataChannel 채팅/파일 전송
1. A가 `createDataChannel()` 호출
2. 상대방은 `datachannel` 이벤트로 채널 수신
3. 연결 성립 후 문자열/JSON/바이너리 송수신
4. 모든 전송은 암호화됨
이 동작은 MDN data channel 및 signaling 설명과 일치합니다. ([MDN][6])
---
## 15. WebRTC를 쓸지 말지 판단 기준
### 써야 하는 경우
* 영상통화가 핵심
* 음성통화가 핵심
* 화면 공유 필요
* 초저지연이 중요
* P2P 데이터 전달이 중요
### 굳이 안 써도 되는 경우
* 단순 채팅
* 일반 푸시 알림
* 서버 저장형 메시지
* 지연에 크게 민감하지 않은 상태 동기화
* 파일 업로드/다운로드 정도만 필요
즉, **“실시간성”과 “미디어 통신”이 핵심이면 WebRTC**입니다.
---
## 16. 초보 개발자가 자주 하는 오해
### 오해 1. WebRTC가 있으면 서버가 아예 필요 없다
아닙니다. signaling 서버가 필요하고, TURN도 필요할 수 있습니다. ([MDN][7])
### 오해 2. 영상통화만 하는 기술이다
아닙니다. 데이터 채널도 강력합니다. `RTCDataChannel`은 임의 데이터를 양방향으로 주고받는 채널입니다. ([MDN][4])
### 오해 3. 브라우저에서만 된다
이름은 WebRTC지만 모바일 앱/네이티브 환경에서도 많이 씁니다. 다만 구현 방식은 라이브러리 레벨에서 달라집니다.
### 오해 4. 연결만 되면 끝이다
실제 서비스는 재연결, 품질 저하 대응, 네트워크 전환, 권한 처리, 배터리, UI/UX, 통화 수명주기 관리가 중요합니다.
---
## 17. 당신에게 맞춘 현실적인 해석
지금 당신이 **위치추적앱 + geofence + AdMob** 쪽이라면, WebRTC는 “핵심 기본 기능”이라기보다 **고급 실시간 기능**입니다.
가장 현실적인 적용 순서는 이런 식입니다.
### 1단계
* 위치 수집 안정화
* geofence 진입/이탈 정확도 개선
* 백그라운드 제약 대응
* 배터리 최적화
* 알림 흐름 안정화
### 2단계
* 보호자/관리자 실시간 확인 기능 추가
* 우선 음성 통화부터
* 이후 영상 확장
### 3단계
* DataChannel로 부가 상태 데이터 전송
* 예: SOS, 배터리, GPS 정확도, 이동 상태, 네트워크 상태
이렇게 가면 구현 난이도를 통제하기 좋습니다.
---
## 18. 한 문장으로 정리
**WebRTC는 브라우저나 앱에서 오디오, 비디오, 일반 데이터를 실시간으로 주고받기 위한 기술이며, `RTCPeerConnection`을 중심으로 signaling, ICE, STUN, TURN, SDP 같은 요소를 이용해 두 피어의 직접 연결을 시도하는 구조**입니다. ([MDN][1])
---
## 19. 영어 / English
**WebRTC is a real-time communication technology that allows browsers and apps to exchange audio, video, and arbitrary data, usually by attempting a peer-to-peer connection. It relies on APIs such as `RTCPeerConnection`, media capture APIs like `getUserMedia()`, and supporting mechanisms such as signaling, ICE, STUN, TURN, and SDP.** ([MDN][1])
---
## 20. 일본어 / 日本語
**WebRTC は、ブラウザやアプリで音声・映像・任意のデータをリアルタイムにやり取りするための技術です。通常は P2P 接続を試み、`RTCPeerConnection`、`getUserMedia()`、そして signaling、ICE、STUN、TURN、SDP などの仕組みによって接続を成立させます。** ([MDN][1])
---
## 21. 스페인어 / Español
**WebRTC es una tecnología de comunicación en tiempo real que permite a navegadores y aplicaciones intercambiar audio, video y datos arbitrarios, normalmente intentando una conexión peer-to-peer. Se apoya en `RTCPeerConnection`, en APIs de captura como `getUserMedia()`, y en mecanismos como signaling, ICE, STUN, TURN y SDP.** ([MDN][1])
---
## 22. 프랑스어 / Français
**WebRTC est une technologie de communication en temps réel qui permet aux navigateurs et aux applications d’échanger de l’audio, de la vidéo et des données arbitraires, généralement en essayant une connexion pair à pair. Elle repose sur `RTCPeerConnection`, sur des API de capture comme `getUserMedia()`, ainsi que sur des mécanismes comme le signaling, ICE, STUN, TURN et SDP.** ([MDN][1])
다음 단계로 이해해야 할 핵심은 **“WebRTC 자체”보다 “signaling과 ICE 처리”**입니다. WebRTC를 처음 공부할 때 대부분 막히는 지점이 바로 그 부분입니다.
[1]: https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API?utm_source=chatgpt.com "WebRTC API - MDN Web Docs - Mozilla"
[2]: https://webrtc.org/getting-started/overview?utm_source=chatgpt.com "Getting started with WebRTC"
[3]: https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API/Protocols?utm_source=chatgpt.com "Introduction to WebRTC protocols - Web APIs - MDN - Mozilla"
[4]: https://developer.mozilla.org/en-US/docs/Web/API/RTCDataChannel?utm_source=chatgpt.com "RTCDataChannel - Web APIs | MDN - Mozilla"
[5]: https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection?utm_source=chatgpt.com "RTCPeerConnection - Web APIs | MDN"
[6]: https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API/Using_data_channels?utm_source=chatgpt.com "Using WebRTC data channels - Web APIs | MDN - Mozilla"
[7]: https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API/Signaling_and_video_calling?utm_source=chatgpt.com "Signaling and video calling - WebRTC API - MDN"
[8]: https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/icecandidate_event?utm_source=chatgpt.com "RTCPeerConnection: icecandidate event - Web APIs - MDN"