[WebRTC] ICE, SDP 심화

WebRTC 3가지 주요기능

• MediaStream
  • 카메라, 마이크 등의 데이터 스트림 접근
• RTCPeerConnection
  • 암호화, 대역폭 관리 및 오디오/비디오 연결
• RTCDataChannel
  • 일반적인 데이터의 P2P통신

---

ICE (Interactive Connectivity Establishment)

• 두 Peer간 데이터 송수신시 최적의 경로를 찾아주는 프레임워크
• 두 Peer간 연결 테스트를 위해 SDP를 이용해 미디어 패킷을 보내 연결 가능한지 확인 함

ICE Candidate

• STUN, TURN 서버를 이용해 얻어낸 IP주소, 프로토콜, 포트의 조합으로 구성된 네트워크 주소들
  • private IP , 포트번호
  • public IP, 포트번호 (STUN, TURN 서버에서 구해옴)
  • TURN 서버의 IP, 포트번호 (TURN 서버에서 구해옴)

ICE를 이용해 P2P 통신할수 있는 주소 후보(ICE Candidate)들을 찾고, 정보들을 주고받게 해줘야 하는데 이때 사용하는게 SDP

 

---

SDP(Session Description Protocol)

해상도, 형식, 코덱, 암호화등 멀티미디어 컨텐츠 연결을 설명하기 위한 표준.

두 peer간 다른 한쪽이 데이터가 전송되고 있다는걸 알게 해줌.

구조

SDP는 한줄 이상의 UTF-8 텍스트로 구성 되어있음.

등호기호(”=”) 를 기준으로,

좌측: letter-lines

우측: 포맷에 맞게 값이나 설명이 적혀있음.

예)

v=0 /// 프로토콜 버전
o=- 6137031273746274589 2 IN IP4 127.0.0.1 /// SDP를 생성한 Peer의 식별자
/// (유저이름), sessionId, sessionVersion, network type, address type, unicast address 
s=- /// 세션이름 (여기선 생략)
t=0 0 /// 세션이 활성화 됐을 시간 (좌측: start time / 우측: end time 세션만료없이 영구적)
a=group:BUNDLE audio video data ///미디어 라인들 간 관계 (오디오, 비디오, 데이터채널 사용)
m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 126 /// 미디어라인
/// 미디어타입, 포트번호, 프로토콜, 코덱 프로파일 번호 (peer간 협상과정에 번호. 코덱이 상호 간 가능한지 확인하고 실패시 순서대로 적용)
/// ...

https://headendinfo.com/session-description-protocol/

 

 

SDP Offer ↔ Answer 흐름

 

Device A 

1. getUserMedia() 로 미디어 캡처
2. RTCPeerConnection 생성, RTCPeerConnection.addTrack() 호출 (addStream deprecated)
3. RTCPeerConnection.createOffer() 메서드로 offer를 생성
4. RTCPeerConnection.setLocalDescription() 메서드로 offer를 localDescription으로 설정
5. setLocalDescription() 호출 후, Ice candidates를 STUN 서버에 요청
6. 시그널링 서버(AWS)를 이용해 Device B에 Offer를 전송

Device B

1. Device A의 Offer 를 수신
2. RTCPeerConnection.setRemoteDescription()호출해서 remoteDescription 기록
3. 호출 종료시, local media 캡처, 각 mediaTrack을 RTCPeerConnection.addTrack()을 통해 peer connection에 연결
4. RTCPeerConnection.createAnswer() 메서드로 answer 생성
5. RTCPeerConnection.setLocalDescription() 으로 생성된 answer에 localDescription을 설정
6. 시그널링 서버를 사용해 Device A에 answer를 전달

Device A

1. answer을 받고
2. RTCPeerConnection.setRemoteDescription() 호출로 answer를 remoteDescription으로 설정
3. 이제 Device A ↔ Device B 서로의 구성을 모두 알 수 있음.

 

요약 짤

위의 과정을 Signaling 이라고 합니다.

즉, RTCPeerConnection 통신에 사용할 프로토콜, 채널, 미디어 코덱, 데이터 전송방법, 라우팅 정보, NAT 통과방법을 포함한 통신 규격을 교환하기 위해 두 장치의 제어 정보를 교환하는 과정을 말합니다.

 

Signaling은 WebRTC자체에서 지원하는 기능이 아니라

Signaling 서버를 직접 만들거나, 외부 솔루션을 이용해 적용할 수 있습니다.

직접 구축한다면 WebSocket이나,

XHR/XMLHttpRequest (.NET, PHP용),

대표적으로 아마존의 KVS(Kinesis Video Stream)이 있습니다.

 

 

ICE Trickle

보통 각 Peer(기기)는 ICE Candidate들을 수집해서 그 목록을 완성한 후 한꺼번에 교환하게 됩니다.

동기적으로 교환 하는 방식을 비동기적으로 교환하도록 하는 방식을 ICE Trickle 라고 합니다.

해당 기능은 옵션이며, 기본적으로는 동기적으로 처리합니다.

 

비동기적으로 처리하다 보니 두 Peer 간 연결이 더 빠르고, 최적화된 경로를 계속해서 찾아낼 수 있겠죠!

 

 

• 참고
  1. https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API/Connectivity
  2. https://wormwlrm.github.io/2021/01/24/Introducing-WebRTC.html