[WebRTC] 🖥️ 0. What, Why and How

미디어 스트리밍에 관심이 있지만 관련 도메인 지식이 부족해서 공부해보고자 포스트를 작성합니다.
WebRTC Guide 원문을 읽고 정리한 글입니다.

What is WebRTC?

WebRTC는 Web Real Time Communication의 약자로, API와 프로토콜 둘 다 의미합니다. WebRTC 프로토콜은 안전한 실시간 양방향 통신을 위한 두 agent간의 약속의 집합입니다. WebRTC API는 개발자들이 WebRTC protocol을 사용하게 해줍니다.

WebRTC는 새로운 것이 아니라, 기존 기술들의 집합!

WebRTC는 크게 순서대로 아래 4가지 스텝을 가지고 있습니다.

1. Signaling
2. Connecting
3. Securing
4. Communicating
   각 단계는 다른 프로토콜들의 집합으로 이루어져 있습니다.

   Signaling: 어떻게 peer간 서로 찾을 수 있을까?

   시그널링은 WebRTC agent가 누구와 무엇을 통신해야하는지에 대한 해답을 가지고 있습니다.
   
   시그널링은 순수 텍스트 프로토콜인 SDP(Session Description Protocol)을 사용합니다. SDP로 다음의 정보를 주고 받습니다.

• IP / Port (후보)
• 보내고 싶은 오디오/비디오 트랙 수
• 지원하는 오디오/비디오 코넥
• 연결 시 사용하는 값(uFrag / uPwd) 유저네임 / 비밀번호
• 보안에 사용하는 인증값
  여기서 중요한 사실은 시그널링은 연결에 WebRTC 사용하지 않는다. 별도의 통신 채널이 필요한데 Rest API를 사용하거나, WebSocket 등을 사용한다.

  연결과 NAT Traversal with STUN/TURN

  한 번 agent간에 SDP를 교환하고 나면, 연결하기 위한 필요한 정보들이 모였다. 연결을 위해 ICE(Interactive Connectivity Establishment)를 사용한다.

ICE는 중앙 서버 없이 P2P로 agent간 연결을 수립하기 위해 사용되는 프로토콜이다. agent는 같은 네트워크 상에 있거나 전혀 다른 네트워크에 있을 수 있다.

ICE는 P2P를 가능하게 해주지만, 진짜 놀라운 일은 연결 과정에서 NAT Traversal과 STUN/TURN 서버를 이용하는데에 있다.
agent가 ICE 연결을 수립하고 나면, 암호화된 오디오/비디오/데이터 전송을 수립하는 다음 스텝으로 넘어간다.

DTLS와 SRTP를 이용하여 전송 레이어 암호화하기

이제 ICE를 통해 양방향 통신이 가능해졌으니, 안전하게 전송하는 것이 필요하다. 이를 위해 DTLS(Datagram Transport Layer Security)와 SRTP(Secure Realtime Transport Protocol)가 필요하다. DTLS는 간단하게 말해, TLS Over UDP이다. TLS는 HTTPS위에서 안전하게 통신하기 위해 사용되는 암호화 프로토콜이다.) SRTP는 RTP(Realtime TransportProtocol) 패킷을 암호화하는데 사용된다.

먼저 DTLS가 ICE에 의해 설립된 연결을 통해 handshake를 한다. HTTPS와 다르게, 중앙 인증서를 사용하지 않고, 시그널링을 통해 교환된 인증서와 일치하는지 검증한다. 이후 DTLS 연결은 DataChannel messages를 위해 사용된다.

다음으로, 오디오/비디오 전송을 위해 SRTP를 사용한다. DTLS 세션에서 키를 추출하여 SRTP 세션을 초기화한다.

왜 데이터와 미디어 정보를 전송하는데 다른 프로토콜을 사용했는지는 나중에 다룰 것입니다.

이제 안전한 양방향 통신을 구축하였습니다!

RTP와 SCTP를 통한 피어간 통신

agent간 안전한 양방향 통신이 구축되었으니 이제 통신을 시작해보죠. RTP(Realtime Transport Protocol)과 SCTP(Stream Control Transmission Protocol)을 사용합니다. 미디어를 교환하는데 SRTP를 이용하여 암호화하고, SCTP를 이용하여 DTLS로 암호화된 DataChannel message들을 주고 받습니다.

RTP는 작지만 실시간 통신을 위해 필요한 도구를 제공합니다. RTP는 개발자들에게 지연과 패킷 유실, 혼잡성을 조작하게 해줌으로써 유연성을 제공합니다.
마지막으로 SCTP는 메세지 전송과 안전성을 끌 수 있습니다. 이를 통해 실시간 지연을 조작하게 해줍니다.

WebRTC, 프로토콜의 집합

WebRTC는 모든 문제를 해결하기 보다는 기존의 존재하는 단일 목적의 프로토콜들을 묶어 놓은 번들입니다.
WebRTC agent는 다른 프로토콜을 제어하는 역할을 합니다.

WebRTC API가 어떻게 동작하는가?

new RTCPeerConnection

WebRTC Session의 가장 상위 레벨에 존재합니다. 위에 언급한 모든 프로토콜을 가지고 있으며, 모든 서스시템이 할당되어있지만 아직 아무것도 일어나지 않은 상태입니다.

addTrack

새로운 RTP stream을 만듭니다. 임의의 Synchronization Source(SSRCE)가 이 stream을 위해 생성됩니다. 이 stream은 createOffer가 생성하는 Session Description의 미디어 섹션에 포함됩니다. 'addTrack'이 호출될 때마다 새 미디어 섹션과 SSRC가 생성됩니다.

SRTP 세션이 생선된 이후, 미디어 패킷은 즉시 SRTP에 의해 암호화되며, ICE를 통해 보내집니다.

createDataChannel

SCTP가 만들어지지 않았다면, 새 SCTP가 생성됩니다. SCTP는 기본적으로 활성되지 않습니다. 한 쪽이 data channel을 요청했을 때만 시작됩니다.

createOffer

remote peer에 공유될 local state의 Session Description을 생성합니다.

local peer의 어떤 것도 변경하지 않습니다.

setLocalDescription

ㅇ청된 변경 사항을 반영합니다. addTrack, createDataChannel 및 비슷한 호출들은 이 호출이 요청되기 전까지는 반영되지 않습니다. 이 요청은 ₩createOffer`로 만들어진 값을 사용합니다.

ㅣㄹ반적으로 이 요청 이 후, remote peer에게 해당 제안을 전송합니다.

setRemoteDescription

remote candidates의 상태를 local agents에게 알리기 위해 사용됩니다. 시그널링이 어떻게 수행됐는지입니다.

agent간 모두 이 메서드가 호출되었을 때, P2P를 위한 정보가 충족된 것입니다.

addIceCandiate

agent에게 언제든지 더 많은 후보를 추가할 수 있습니다. 연결에는 영향이 가지 않습니다.

ontrack

remote peer에게 받은 RTP 패킷 콜백입니다. 이 패킷들은 remote Description으로 전송된 Session Description에 선언될 것입니다.

WebRTC는 SSRC를 사용하여 관련있는 MediaStream과 MediaStreamTrack을 찾습니다. 또한 해당 콜벡을 발행합니다.

oniceconnectionstatechange

ICE agent 상태의 변경 사항을 콜백입니다. 네트워크 연결 상태가 변경되면 알림이 갑니다.

onconnectionstatechange

ICE agent와 DTLS agent 상태의 조합해 보여줍니다. ICE와 DTLS 모두 성공적으로 완료되었을 때 등을 알림받을 수 있습니다.