WebRTC on Chrome
•
Real-time communication 을 웹에 제공
•
Chrome 에 최첨단 미디어 스택 구축
•
새로운 커뮤니케이션 플랫폼 개발
Three main tasks
1.
로컬의 오디오와 비디오 획득
2.
오디오와 비디오를 통신함
3.
임의의(arbitary) 데이터를 통신함
Three main Javascript APIs
1.
MediaStream (aka getUserMedia)
2.
RTCPeerConnection
3.
RTCDataChannel
1. MediaStream (로컬의 오디오와 비디오 획득)
•
Represents a stream of audio and/or video
•
Can contain multiple tracks
•
Obtain a MediaStream with navigator.getUserMedia()
2. RTCPeerConnection (많은 걸 함)
•
Signal processing
•
Codec handling
•
Peer to peer communication
•
Security
•
Bandwidth management
•
…
3. RTCDataChannel (임의 데이터 통신)
•
Same API as WebSockets
•
Ultra-low latency
•
Unreliable or reliable (신뢰할 수 없는 or 신뢰할 수 있는)
•
Secure
여기까지 중간정리
•
WebRTC 란 브라우저간 Peer-to-peer (P2P) 연결을 통해 오디오와 비디오 뿐만 아니라, 임의의 데이터까지 매우 빠른속도로 통신 할 수 있는 기술이다.
•
로컬의 오디오와 비디오를 획득할 때는 MediaStream 의 navigator.getUserMedia() 를 사용한다
•
그렇다면 어떻게 브라우저간 P2P 연결을 수립할 수 있는가?
•
Signaling 이라는 연결 수립 과정을 이제부터 설명한다.
Abstract Signaling
•
Need to exchange ‘session description’ objects :
◦
What formats I support, what I want to send
◦
Network information for peer-to-peer setup
•
Can use any messaging mechanism
•
Can use any messaging protocol
STUN (Session Traversal Utilities for NAT)
•
위 그림 중 An ideal world 는, 두 Peer 가 모두 각각의 Public IP 를 가지고 있는 경우이다. 이 때는 두 피어 모두 서로와 즉시 통신 할수 있다.
•
하지만 현실은 아래그림(The real world)과 같이 대부분 NAT(사설망) 뒤에 있다.
•
해서 이러한 네트워크 상태일 때 P2P 연결을 위해서 STUN Server 를 사용한다.
•
SUTN 은 Peer 의 Public IP 주소가 무엇인지 말해주는 녀석이다.
•
아주 심플한 서버이고, 저렴하게 유지할 수 있다.
•
STUN 을 사용하여 연결이 가능한 경우 P2P 연결 상태는 아래와 같다.
NAT 끼리 직접 연결되어 있는 것을 볼수 있다. 따라서 ideal 한 케이스와 거의 동일하게 Media(또는 Data) 를 주고 받을 수 있다.
TURN (Traversal Using Relays around NAT)
•
모든 경우를 STUN 으로만 해결 할 수 있는 것은 아니다. 두 Peer 가 모두 같은 Public IP 를 가지고 있거나, Symmetric NAT의 경우 어플리케이션이 달라 지면 NAT 의 맵핑 테이블이 바뀔 수 있기 때문에 불가능 하다.
•
이 경우 어쩔수 없이 중간에 중계서버를 두고 통신을 해야 하는데, 이 중계서버를 TURN 이라고 한다.
•
TURN provide a cloud fallback if peer-to-peer communication fails
•
Data is sent through server, uses server bandwidth
•
Ensures the call works in almost all environments
•
TURN 을 통해 통신하는 경우 아래와 같은 형태가 된다.
NAT 끼리 바로 연결되지 못하고 각각의 TURN server 에 연결되어 데이터(또는 미디어) 를 주고받는다. 당연히 더 느릴 수 밖에 없을듯 하다.
여기까지 중간정리
•
모든 Peer 들이 서로 직접 연결가능한 Public IP를 가지고 있는 것은 아니다. 해서
•
Peer-to-peer 연결 수립을 위해 STUN 이나 TURN 서버를 활용하게 되는데 내 생각으로는 TURN Server 는 STUN Server 의 기능을 모두 포함하면서, 데이터를 송수신 해주는 기능까지 추가된 서버인 것 같다.
•
아니 그렇다면 총 3가지 연결방법이 존재하는데,
◦
Peer 끼리 직접 연결 (둘다 공인 IP가 있을 때) → Direct Connection
◦
NAT 을 통해 연결 (둘중하나라도 NAT 뒤에 있을 때) → Server Reflexive Connection
◦
TURN Server 를 통해 연결 (NAT 을 통한 연결이 불가능 할 때) → TURN Relay Connection
•
이 연결을 모두 구현해야 하나?
•
아니다 알아서 두 피어간의 가능한 연결을 체크하고, 이중 우선순위를 정해서 최적의 방법으로 연결해주는 프레임워크가 있다. 아래에서 설명한다.
ICE (Interactive Connectivity Establishment)
•
ICE : a framework for connecting peers
•
최적의 연결 경로를 찾아내주는 녀석이다.
•
대부분의 연결은 STUN 을 활용하는 선에서 끝난다 (TURN 이용하는 것이 극단적이는 얘기)
•
•
이미 제공되고 있는 STUN 과 TURN Server 는 아래와 같다.
◦
WebRTC stunserver, turnserver
◦
rfc5766-turn-server
◦
restund
•
위에서 설명한 3연결을 candidate 로 하여 SDP(참조 : https://ko.wikipedia.org/wiki/%EC%84%B8%EC%85%98_%EA%B8%B0%EC%88%A0_%ED%94%84%EB%A1%9C%ED%86%A0%EC%BD%9C ) 내에 포함시켜 전송한다.
Security throughout WebRTC (WebRTC 전반에 걸친 보안)
•
미디어 및 데이터에 대한 암호화가 필수적으로 포함되어 있다.
•
Secure UI, (명시적으로 옵션을 넣었을 때)
•
plugin 없는 Sandbox 화
Architecture
1. Peer to peer : one-to-one call
2. Mesh: small N-way call
3. Start: Medium N-way call
4. MCU: Large N-way call
