10 min to read

WebRTC 시동걸기

WebRTC 개발을 하기 위한 사전준비

Featured image

들어가며

우리는 2021년 오늘도 아직 COVID-19의 여파로 달라진 일상을 받아드리며 살아가고 있다.

이제는 자연스레 문 밖을 나서면 마스크를 쓰고 나선다.

출근 또한 사무실로 뚜벅뚜벅 걸어가기도 하지만, 집앞 책상에 앉아서 재택근무를 하기도 한다.

온라인 스터디등의 활동도 저마다의 노트북이나 스마트폰 앞에서 자연스레 다중 화상모임으로 진행한다.

이제는 비대면 활동이 너무나도 자연스러워졌다. 아마, COVID-19 팬데믹이 완전 종식되더라도, 우리는 이전의 삶으로 돌아가기에는 너무 멀리 와버렸는지도 모르겠다.

COVID-19라는 비대면 환경을 강력히 권고하는 제한적인 사회 구조속에서 Unified Communications(이하 UC)의 수요가 급격하게 늘어 났다. 특히 UC 중 영상통화 및 다자회의를 하고자 하는 경우가 늘어났다.

통합 커뮤니케이션(Unified communications, UC)은 전화, 팩스, 이메일, 핸드폰, 메신저, 영상통화, 음성메일 등 기업 내 다양한 커뮤니케이션 도구를 단일한 플랫폼을 통해 제공하는 것을 말한다. wikipedia/ 통합 커뮤니케이션

개발을 하는 우리는 무엇을 준비하면 될까? 특히 웹개발자는 할 수 있는 일이 없을까?

아니다. 영상통화 등과 같은 비대면 원격 커뮤니케이션에 사용 될 수 있는 웹기술이 있다. 바로 WebRTC 이다.

2020년의 경우 1월 대비 12월에 Chrome을 통한 WebRTC의 사용량이 100배정도 증가 한 것으로 분석된다.

이번 아티클에서는 WebRTC를 간략하게 다뤄보고자 한다.

WebRTC 여정의 시작

후……. 그렇다. 이미 WebRTC를 사용하고자 노력했던 많은 분들이 이 글 또한 찾아오셨다고 생각된다.

초심자의 눈에서는 관련자료가 너무 적고, 관련 주제의 범위가 너무 방대하다.

(그렇지만 이 글을 시작으로 한걸음씩 써볼 예정이다.)

WebRTC 란 ?

WebRTC (Web Real-Time Communication)는 웹 브라우저 간에 플러그인의 도움 없이 서로 통신할 수 있도록 설계된 API이다. W3C에서 제시된 초안이며, 음성 통화, 영상 통화, P2P 파일 공유 등으로 활용될 수 있다.

IETF(Internet Engineering Task Force, 국제 인터넷 표준화 기구) RTCWEB 워킹그룹에서 통신에 필요한 프로토콜 규격을 정의하고, W3C WebRTC 워킹그룹에서 로컬 미디어 장치 연동을 위한 API 규격을 정의한다.

W3C WebRTC 표준해설서에 따르면 2010년 구글이 주최하고 W3C, 모질라, 마이크로소프트, 인텔, 애플, 아이비엠, 에릭슨, 시스코, 로지텍, 오페라, 야후 등 여러 업체가 참석한 RTC Web 워크숍에서 웹에서 실시간 미디어 통신을 하기 위해 필요한 통신방법, 코덱, 암호화, 보안, API 수준 등의 내용들을 처음으로 논의했고 한다.

위의 기능들을 지원하기위해 각 브라우저 개발사는 Spec에 맞춰 개발을 진행하였으며, WebRTC의 대표적인 지원 API는 아래와 같다.

WebRTC 프로토콜

WebRTC는 TCP와 UDP 기반의 다양한 프로토콜로 이뤄진다.

프로토콜 스택은 아래와 같다.

막막하다. 알아야 할 프로토콜도 많고, 그 깊이도 짐작하기 어렵다. 머리는 복잡해지고 자신감은 떨어진다. 괜찮다. 천천히 하나씩 해보자!

우선 대략적으로 WebRTC가 위에서 말했던 프로토콜들을 아래와 같이 사용한다.

  1. Signalling
  2. Connecting
  3. Securing
  4. Communicating

조금 더 자세한 버전을 확인하고 싶다면 W3의 예시 문서를 참고 하길 권한다.

각 단계별 프로토콜은 아래와 같다.

Signalling

Connecting

Securing

Communicating

WebRTC 주요 기술 살펴보기

SDP (Session Description Protocol)

세션 기술 프로토콜(Session Description Protocol, SDP)은 스트리밍 미디어의 초기화 인수를 기술하기 위한 포맷이다. 이 규격은 IETF의 RFC 4566로 규정되어 있다. - 세션_기술_프로토콜

WEB RTC는 시그널링 서버의 구현은 별도의 제약이 없다. 따라서 Http Long polling, Web socket, MQTT, SIP등을 사용해서 자유롭게 구현이 가능하다.

WebSocket 이나 SIP등을 통해 공유 신호 채널(시그널링)을 도입 후, WebRTC 연결을 하는데 필요한 첫 단계로 SDP는 매체를 운반하지 않는 대신, 운반할 매체의 종류, 네트워크 전송 수단, 사용 코덱과 그 설정, 대역폭 정보등 메타데이터와 같은 전반적인 커넥션의 특성을 나열한 세션프로필을 설명한다. 아래와 같이 스트링을 직접 전송도 가능하고, XMPP(XML) 로 매핑하기도 한다.

GetMedia를 통해 브라우저가 현재 OS로부터 카메라 및 마이크 액세스 정보를 가져온 이후, Create Offer 생성시 아래와 같이 SDP 정보를 구성한다. 구성된 정보를 각 Peer 간 주고 받으며 연결 설립 절차를 이어나간다.

자세한 정보는 크롬의 내장 WebRTC 분석도구를 통해서 확인 가능하다.

Session description
        v=  (protocol version)
        o=  (originator and session identifier)
        s=  (session name)
        i=* (session information)
        u=* (URI of description)
        e=* (email address)
        p=* (phone number)
        c=* (connection information—not required if included in
             all media)
        b=* (zero or more bandwidth information lines)
        One or more time descriptions ("t=" and "r=" lines; see below)
        z=* (time zone adjustments)
        k=* (encryption key)
        a=* (zero or more session attribute lines)
        Zero or more media descriptions

NAT Traversal

집에서 인터넷을 사용하는 사람이면 대부분 공유기를 가지고 있을 것이다. 공유기를 사용하는 이유는 명확하다. 우리는 ISP(Internet Service Provider) 인 SKT, KT, LG 등과 계약시 여러개의 공인 IP를 사용토록 계약을 하지 않는다. 본인이 소유한 모든 인터넷 장치별로 공인 IP가 할당되면 좋겠지만, IP의 경우 그 갯수에 한계가 있다. 물론 IPv6라는 대안이 나오기는 했지만, 여전히 우리는 IPv4를 많이 쓰는 환경에 살고 있다.

이를 해결하기 위해서 LAN에서는 NAT를 사용한다.

네트워크 주소 변환(영어: network address translation, 줄여서 NAT)은 컴퓨터 네트워킹에서 쓰이는 용어로서, IP 패킷의 TCP/UDP 포트 숫자와 소스 및 목적지의 IP 주소 등을 재기록하면서 라우터를 통해 네트워크 트래픽을 주고 받는 기술을 말한다.

Full cone NAT

Full cone은 One-to-one NAT이라고 한다. PC1에서 공유기를 거쳐 IP1와 Port1로 패킷이 나가면, 외부에서 IP1와 Port1로 들어오는 모든 패킷은 PC1로 전달된다.

Address Restricted Cone NAT

PC1에서 외부 서버로 패킷을 보내다. 이 때 서버 주소와 포트는 IP2와 Port2이다. 서버에서 PC1으로 보내는 패킷의 Source는 IP2이다. 서버에서 보내는 Source 주소 IP2의 패킷이 공유기에 들어올 때 PC1으로 전달된다. 포트는 아무 포트가 되어도 무방하고 Port2일 필요가 없다.

Port Restricted Cone NAT

Port restricted cone은 Address restricted cone에서 서버의 주소만 보는 것이 아니라 주소와 포트 모두를 보는 것이 다르다. 서버에서 보내는 패킷의 Source가 IP2와 Port2일 때 PC1으로 전달된다.

Symmetric NAT

패킷을 보내는 외부 서버마다 다른 NAT 매핑을 사용한다. PC에서 패킷을 특정 서버로 보내면 그 서버에서 보낸 패킷만 PC로 전달된다. Restricted cone NAT은 공유기 외부 포트가 항상 일정하지만 Symmetric NAT은 접속하는 서버에 따라 외부 포트가 달라진다.

이런 NAT 환경이 VoIP 등 Peer to Peer 환경에서는 문제가 됐다. 아래 그림을 예로 들면 Softphone 1과 Softphone4와의 호 설립시, 중간에 위치한 NAT처리구간 (주로 라우터)을 넘어서 연결가능한 주소(Candidate)를 주고 받아야 한다. 이를 가능하도록 만든 기술이 STUN과 TURN이다.

ICE, STUN, TRUN

클라이언트는 STUN을 통해 자신의 공인 IP를 확인을 한 뒤 상대 Peer에게 본인의 공인 IP를 알려준다. 상태 Peer 또한 본인의 공인 IP 정보를 제공한다.

다만 이 Stun으로 모든 것을 해이 어려운 경우가 있는데, Client와 상대 Peer이 같은 네트워크에 존재 할 때는 이것만으로 해결이 어렵다고 한다. 또한 Symeetric NAT의 경우에도 Application이 달라지면 NAT 매핑테이블이 바뀔 수 있어 연결이 어렵다고도 한다.[3]

이런경우 TRUN을 이용하여 수집을 한다. ICE(Interactive Connectivity Establishment, RFC 5245)라는 프레임워크가 수행한다. ICE는 두개의 단말이 P2P 연결이 되도록 최적의 경로를 찾아주는 프레임워크다.

ICE 프로토콜 (RFC 5245)를 사용하면 직접연결이 어려울때는 Stun을 사용하고 그래도 실패하면 turn을 사용한다.

구글 libjingle 에서는 92%가 stun을 사용하며, 8%경우에만 trun을 이용하여 중계를 통해 연결에 성공했다. - 네트워킹과 웹 성능 최적화 기법

이렇게 클라이언트는 ICE에 사용할 Candidate(후보)를 수집한다. 각 후보는 미디어를 수신 할 수있는 잠재적 주소와 포트. 일반적으로 세 가지 유형의 후보자가 생성된다.[2]

더 친절한 도움은 아래 링크를 보자

Candidates는 RFC 5245, section 15.1에 자세히 나와 있으며 아래와 같은 형태를 띈다.[1]

a=candidate:4234997325 1 
udp 2043278322 192.168.0.56 44323 typ host

Connection 동작 개요

위에서 지금까지 살펴본 프로토콜도 있고, 아닌경우도 있지만 흐름을 살펴보자

https://programmer.help/blogs/getting-started-with-webrtc-video-communications.html

Communicating

각 Peer 간 연결 호 수립이 완료 되면 미디어 데이터를 주고 받는다.

이때 사용하는 프로토콜은 RTP와 RTCP가 있다.

RTP (Real-time Transport Protocol)

RTCP (Real-time Transport Control Protocol)

실시간 전송 프로토콜(Real-time Transport Protocol, RTP)은 IP 네트워크 상에서 오디오와 비디오를 전달하기 위한 통신 프로토콜이다. RTP는 전화, 그리고 WebRTC, 텔레비전 서비스, 웹 기반 푸시 투 토크 기능을 포함한 화상 통화 분야 등의 스트리밍 미디어를 수반하는 통신, 엔터테인먼트 시스템에 사용된다. RTP는 일반적으로 사용자 데이터그램 프로토콜(UDP)로 동작한다. RTP는 RTCP(RTP Control Protocol)와 결합하여 사용된다. RTP가 오디오/비디오와 같은 미디어 스트림을 전달하는 반면, RTCP는 전송 통계와 QoS를 모니터링하고 다중 스트림의 동기화를 도와준다.

WebRTC 호 설립 이후, 해당 부분의 RTP의 Input과 Output이 보인다.

마무리

이번 글에서는 대략적인 WebRTC에서 이용하는 기반 프로토콜 등 기술을 살펴봤다.

처음 입문 시 어려운점이 생소한 프로토콜과 복잡한 처리과정들이다. 나의 경우에는 ICE부터 막혔다. STUN은 뭔지, TURN은 뭔지…

추후에는 성능 개선을 위해서 코덱설정이나 ICE 서버 설정 등 각 단계별로 자세히 살펴보는 과정이 필요 할 수 있다. 또한 WebRTC를 직접 구현하기보단 미디어 서버를 도입을 통해 N:M, 1:M 구조를 개선하고 해결을 해 볼 수도 있다.

다음 글에서는 시그널링 서버를 간단히 구현해보고, 미디어를 주고 받는 구현을 이어서 진행하려한다.

참고

[1] candidate - https://developer.mozilla.org/ko/docs/Web/API/RTCIceCandidate/candidate

[2] ice-and-webrtc-what-is-this-sorcery-we-explain - https://temasys.io/ice-and-webrtc-what-is-this-sorcery-we-explain/

[3] https://brunch.co.kr/@linecard/156