WebRTC : WebRTC란?

• 
• Sugoi Ebooks(Write in English)
• Naver Cafe
• Sugoi Japanese
• Find a Job in Japan

• WebRTC란?
  • • WebRTC 아키텍처
    • WebRTC를 사용하는 이유?
  • WebRTC는 무엇을 할 수 있나?
  • WebRTC의 장점
  • WebRTC는 브라우저에서 어떻게 작동하나?
  • 시그널링이란 ?
  • STUN과 TURN이 무엇인가?
  • WebRTC는 통신은 안전한가?
  • WebRTC 구글 예제
  • WebRTC 기본개념
• CentOS에서 Coturn 서버 설치 및 설정하기
• Coturn 서버 설정
  • • 1. Coturn 서버 설정
    • 2. WebRTC 클라이언트 샘플 코드
    • 연결 테스트
• 퀴즈: WebRTC와 Coturn 서버 설정
• 추가 퀴즈: NAT 트래버셜, 시그널링, ICE 프레임워크
• 추가 퀴즈: WebRTC 소스 코드
• WebRTC 관련 오픈소스
  • kurento-media-server
  • openvidu

WebRTC란?

공식 웹사이트 : https://webrtc.github.io/webrtc-org/architecture/

WebRTC(Web Real-Time Communication)는 Google이 2010년 6,820만 달러에 인수하여 "WebRTC"로 이름을 바꾼 VoIP 소프트웨어 개발업체 Global IP Solutions의 GIPS 엔진으로, 인터넷 브라우저용 오디오, 비디오 및 데이터의 실시간 통신 플랫폼을 구축하기 위해 2011년에 오픈 소스화되었다.

그렇다면 WebRTC는 무엇을 할 수 있나? 주로 의료 분야의 온라인 상담/원격 진료/원격 상담 외에도 전자상거래 대화형 라이브 방송 솔루션과 교육 산업 솔루션이 더욱 인기를 얻고 있다. 또한 클라우드 게임에서도 사용해서 저사양핸드폰이나 컴퓨터에서 고사양게임을 즐길수 있도록 하는 서비스도 있다.

WebRTC 아키텍처

아래 그림은 WebRTC 공식 웹사이트 에 있는 WebRTC의 전체 아키텍처 다이어그램 이다.

그림에서 보듯이 WebAPI 를 통해서 브라우져에 WebRTC가 내장되어있다면 누구라도 web 에서 브라우져를 통해서 영상,오디오 통신을 할수 있다.

WebRTC를 사용하는 이유?

WebRTC 가 인기를 얻는 데에는 여러 가지 이유가 있다. 그 이유 중 일부는 다음과 같다.

• WebRT* 는 플러그인이 필요 없는 최신 실시간 통신 기술이다. 오디오, 비디오 스트리밍 및 데이터 공유를 위해 추가 플러그인이나 애플리케이션이 필요하지 않다. Javascript , API(응용 프로그래밍 인터페이스) 및 HTML5를 사용하여 브라우저에 통신 기술을 내장한다 . Google Hangouts , Facebook Messenger , ZOOM , Zendesk Customer Support, Skype for Web 등과 같은 제품은 모두 WebRTC기반으로 운영된다.
• 브라우저는 P2P 방식으로 다른 브라우저와 직접 실시간 미디어를 교환할 수 있다.
• 타사 소프트웨어 없이도 다른 다양한 스트리밍 시스템보다 높은 수준의 보안을 제공한다.
• 실시간 통신을 위한 별도의 플러그인이 필요하지 않다.

WebRTC는 무엇을 할 수 있나?

• 온라인 채팅방
• 온라인 영상 채팅
• 원격 실시간 모니터링
• 화면 공유
• 대용량 파일의 지점간 전송
• 실시간 게임
• 라이브 스트리밍
• . . .
• 실시간이 필요한 기타 애플리케이션 시나리오

WebRTC의 장점

• 플랫폼 및 장치 독립성. 개발자는 단말 및 운영체제 수준의 호환성 문제에 대한 걱정 없이 WebRTC를 지원하는 브라우저를 통해 WebRTC 기반의 다양한 애플리케이션을 개발할 수 있다. 또한 WebRTC는 플랫폼 호환성 문제를 방지하기 위해 표준 API(W3C)와 표준 프로토콜 지원(IETF)도 제공한다.
• 음성 및 영상의 보안 처리, WebRTC는 SRTP를 통해 음성 및 영상을 암호화한다. 브라우저를 사용하여 로그인하여 음성 및 영상에 액세스하는 사용자는 사용자 시나리오의 보안 요구 사항(예: 보안되지 않은 Wi-Fi 환경의 음성 및 영상)을 충족하는 비교적 안전한 설정이 필요하며 다른 사람은 이를 모니터링할 수 없다.
• 고급 언어 및 비디오 처리를 지원하고 WebRTC는 최신 인코딩을 지원하며 음성은 Opus를 지원하고 비디오는 VP8을 지원한다. 내장된 인코딩은 다른 타사 다운로드의 보안 위험을 제거하고 더 나은 음성 또는 비디오 품질을 달성하기 위해 네트워크 환경 조정을 지원할 수 있다.
• 안정적인 전송 생성을 지원하는 WebRTC는 NAT 환경에서도 얻을 수 있는 전송 안정성을 포함하여 안정적인 전송 방법을 제공한다.
• 멀티미디어 스트림 처리를 지원하는 WebRTC는 멀티미디어와 다중 리소스의 집합을 제공하고 RTP 및 SDP의 확장을 제공한다.
• 다양한 네트워크 환경 조정을 지원한다. WebRTC는 네트워크 플랫폼에서 실행되기 때문에 네트워크 환경과 대역폭에 매우 민감한다. 네트워크 혼잡을 피하기 위해 네트워크 환경과 대역폭 요구 사항을 스스로 감지하고 조정할 수 있다. RTCP 및 SAVPF를 통해 이 기능을 보장한다.
• WebRTC는 VoIP 음성 및 비디오와 잘 호환되며 SIP, Jingle 및 XMPP 도킹을 포함한 다른 미디어와의 호환성 작업을 구현한다. 동시에 다른 기존 프로토콜과 인터페이스해야 하는 경우 WebRTC 게이트웨이를 사용하여 원활한 호환성을 달성하고 기존 프로토콜과의 호환성을 보장할 수 있다.

WebRTC는 브라우저에서 어떻게 작동하나?

WebRTC는 기본적으로 브라우저를 통해 웹을 통한 실시간 통신이다. 브라우저 간의 통신을 허용한다. WebRTC 웹 애플리케이션은 HTML 과 *
JavaScript 의 혼합 으로 프로그래밍된다. 사용자는 CSS를 사용하여 사용자 정의 할 수도 있다 . 표준화된 WebRTC API를 통해 웹 브라우저 와 작동하고 통신한다. 따라서 WebRTC API는 일련의 유틸리티를 제공 한다. 그 중 일부는 연결 관리(P2P 방식), 인코딩/디코딩 기능 협상, 선택 및 제어, 미디어 제어, 방화벽 설정 등과 같다.

WebRTC는 사용자 정의가 가능하기 때문에 구현 범위가 넓다. WebRTC 의 기능은 세 부분으로 나눌 수 있다.

1. MediaStream : 첫 번째 단계는 사용자가 공유하려는 데이터를 가져오는 것이다. 이 경우 사용자가 원하는 스트림(오디오/비디오)을 캡쳐하여 통신 패턴을 설정한다. 로컬 미디어 스트리밍을 사용하면 브라우저가 카메라 및 웹 마이크와 같은 스트리밍 장치에 액세스할 수 있다. 또한 브라우저가 미디어를 캡처할 수도 있다. 사용자는 브라우저 기능을 활용하여 getUserMedia()액세스 권한을 얻을 수 있다.
2. RTCPeerConnection : 사용자가 통신 흐름을 결정하고 나면 다음 단계는 이를 원격 서비스 시스템에 연결하는 것이다. 이를 통해 당사의 브라우저는 음성 및 영상 통화를 위해 원격 서비스 브라우저(피어)와 직접 데이터를 교환할 수 있다. STUN 및 TURN 서버를 통해 발신자와 수신자 간의 상관관계를 허용한다 .
3. RTCDataChannel : 브라우저가 지점 간 양방향으로 데이터를 교환할 수 있도록 한다.

시그널링이란 ?

WebRTC는 RTCPeerConnection을 사용하여 브라우저 간(종단간)에 스트리밍 데이터를 전송하지만 통신을 조정하고 제어 메시지를 보내는 메커니즘(시그널링이라는 프로세스)도 필요한다. WebRTC는 신호 방법과 프로토콜을 지정하지 않다.

STUN과 TURN이 무엇인가?

WebRTC는 P2P로 작동하도록 설계되었으므로 사용자는 가장 직접적인 경로를 통해 연결할 수 있다. 그러나 WebRTC는 실제 네트워킹을 처리하도록 구축되었다. 클라이언트 애플리케이션은 NAT 게이트웨이와 방화벽을 통과해야 하며 P2P 네트워크는 직접 연결이 실패할 경우 대체해야 한다. 이 과정에서 WebRTC API는 STUN 서버를 사용하여 컴퓨터의 IP 주소를 획득하고 지점 간 통신이 실패하는 경우 TURN 서버를 중계 서버로 사용한다.
즉, STUN은 클라이언트가 자신의 공용 IP와 포트를 알아내는 프로토콜이고, TURN은 클라이언트 간의 직접적인 연결이 불가능할 때 중계 서버를 통해 데이터를 전달하는 프로토콜이다. ( 그렇다고 서버를 통해 통신을 하는건 아니고 기본적으로 개인대 개인이 통신하는 것이다.)

WebRTC는 통신은 안전한가?

모든 WebRTC 구성 요소는 암호화되어야 하며 보안 소스( 또는 localhost) JavaScript API에서만 사용해야 한다 . HTTPS신호 메커니즘은 WebRTC 표준에 의해 정의 되지 않으므로 보안 프로토콜을 사용해야 한다.
WebRTC는 고급 오디오 및 비디오 코덱(Opus 및 VP8/9), 필수 암호화 프로토콜(SRTP 및 DTLS) 및 네트워크 주소 변환기(ICE 및 STUN)를 포함한 고급 실시간 통신 기술을 결합한다.

WebRTC 구글 예제

https://github.com/webrtc/samples 에 구글이 제공해 주는 표준 예제가 있다.
git clone 도는 다운로드 해서 npm install & npm start 하면 WebRTC samples 화면이 나오는데 테스트 하고 자 하는 링크를 클릭하면 된다.

WebRTC 기본개념

WebRTC는 WebComponent와 마찬가지로 기술 세트이며 API는 세 부분으로 구성된다.

• getUserMedia : 로컬 미디어 리소스(카메라, 마이크) 가져오기

• RTCPeerConnections : 미디어 스트림의 지점 간 전달을 위한 로컬 프록시 설정

• RTCDataChannel : 지점 간 데이터 연결 채널

• SDP

  • SDP는 세션 설명 프로토콜(SDP로 약칭)이다. SDP는 해상도, 형식, 인코딩, 암호화 알고리즘 등과 같은 멀티미디어 링크 콘텐츠를 설명하는 데 사용되므로 이러한 콘텐츠는 미디어 스트림 자체가 아닙니다. SDP는 프로토콜이 아니라 데이터 형식이다. 해당 데이터 구조는 하나 이상의 UTF-8 텍스트 줄로 구성된다. 각 줄은 한 문자 유형으로 시작하고 그 뒤에 등호("=")가 오고, 형식에 따라 값이나 설명이 포함된 구조화된 텍스트가 온다. 유형. 주어진 문자로 시작하는 텍스트 줄을 종종 "문자 줄"이라고 한다. 예를 들어, 미디어 설명을 제공하는 줄은 “m” 유형이므로 이러한 줄을 "m 줄"이라고 한다.

• ICE

  • (대화형 연결 설정)은 네트워크에서 안정적인 실시간 통신 연결을 설정하기 위한 프레임워크 및 프로토콜이다. ICE는 별도의 서버가 아니라 STUN(Session Traversal Utilities for NAT) 및 TURN(Traversal Using Relays around NAT) 서버를 활용하여 목표를 달성하는 방식이다. 실제로 ice는 STUN과 TURN의 기능을 통합한 종합 솔루션이다. ICE는 다양한 네트워크 조건에서 최적의 연결 경로를 선택하여 가장 안정적이고 효율적인 통신을 보장한다.

• STUN 서버

  • NAT(Network Address Translation)로 인해 발생하는 연결 문제를 해결하는 데 사용된다. STUN 프로토콜을 사용하면 클라이언트가 NAT 뒤의 공용 주소와 포트를 발견하여 직접 통신이 가능해진다.

• TURN 서버

  • 두 엔드포인트가 직접 통신할 수 없는 경우 릴레이 서비스를 제공하는 데 사용된다. TURN 서버는 NAT와 같은 문제를 해결하기 위해 두 끝점 모두에 데이터를 전송하는 중계 역할을 한다.

• RTP 프로토콜

  • 실시간 대화형 라이브 방송 시스템은 UDP를 사용하여 전송하지만 일반적으로 데이터 스트림을 전송할 때 오디오 및 비디오 데이터를 UDP로 직접 전송하지 않고 오디오 및 비디오 데이터에 RTP 헤더를 먼저 추가하여 전송한다. 그런 다음 전송을 위해 UDP로 전송된다.

• WebRTC는 기본적으로 실시간 통신을 위해 웹 브라우저를 지원한다.

  • 실시간 통신 데이터에는 플러그인을 다운로드하지 않고도 음성, 오디오, 비디오 및 기타 모든 유형의 데이터가 포함된다.
  • WebRTC를 통해 임의의 데이터를 전송할 수 있다. 이 프로세스는 WebRTC의 데이터 채널에서 수행된다. 서버를 거치지 않고 브라우저 시간에 정보를 전송해야 하는 경우(메시지를 전달하려면 TURN 서버가 필요함)를 사용할 수 있다. 데이터 채널.
  • 데이터 채널은 메시지를 순서대로 또는 비순서적으로 안정적으로 또는 신뢰할 수 없게 전송하도록 구성할 수 있다.

• WebRTC는 JavaScript API를 사용하는 미디어 엔진이다.

  • WebRTC는 JavaScript API를 상위 계층으로 사용하는 단순한 미디어 엔진이다.

• WebRTC P2P 데이터 전송 원리

  • P2P는 브라우저 간에 직접 데이터를 보낼 수 있다.
  • 상대방의 네트워크 정보를 얻기 위해서는 먼저 시그널링 서버를 통해 서로의 데이터를 교환해야 한다.
  • 시그널링 서버는 세 가지 유형의 정보를 교환하는 데 사용된다.
    • 세션 제어 메시지: 초기화/종료, 다양한 비즈니스 로직 메시지, 오류 보고
    • 네트워크 메시지: 외부에서 식별 가능한 IP 주소 및 포트(ICE 메시지)
      • 미디어 채널을 연결하기 위해 ICE가 구현된다(때로는 TURN을 통해 메시지를 전달해야 하는 경우도 있음).
      • ICE(Interactive Connectivity Deployment: Interactive Connection 확립)는 STUN, TURN(Traversal Using Relay NAT) 등 다양한 NAT 통과 기술을 통합할 수 있다.
        • STUN 서버는 공용 네트워크에 위치하며 자신의 IP, Port 및 NAT 정보를 얻은 후 이 정보를 시그널링 서버를 통해 교환하고 마지막으로 두 클라이언트가 IP, Port 및 NAT를 기반으로 해당 통신을 수행하도록 한다. 이를 통해 얻은 NAT 정보이다.
      • ICE는 먼저 STUN(NAT 세션 통과 애플리케이션 - 공개 IP 주소 획득)을 사용하여 UDP 기반 연결 설정을 시도한다. 실패할 경우 TCP를 사용하고, 실패할 경우 릴레이 TURN(중간)을 사용한다. ) NAT) 서버를 관통한 후
      • ICE는 클라이언트가 연결을 설정하는 데 가장 적합한 경로를 찾거나 가능한 모든 옵션을 시도하고 가장 적합한 경로를 선택한다.
    • 미디어 기능: 클라이언트는 코덱, 해상도, 통신 대상(SDP 정보)을 제어할 수 있다.
  • 신호가 성공적으로 전송되면 메시지는 두 브라우저 간에 직접 전송될 수 있으며 웹 서버는 이 정보를 얻지 못한다.

• WebRTC에는 네트워크를 통한 두 가지 유형의 상호 작용이 필요한다.

  • 신호 전송
    • JS 코드를 통해 구현된 HTTPS 연결 또는 WebSocket에서 발생한다.
    • 신호 전달에서 발생해야 하는 모든 작업은 사용자가 서로를 찾고 대화를 시작하는 것이다.
    • 현재 WebSocket+JSON/SDP 솔루션은 업계에서 널리 사용되고 있으며 WebSocket은 신호 전송 채널을 제공하는 데 사용되고 JSON/SDP는 신호의 특정 내용을 캡슐화하는 데 사용된다.
      • WebSocket은 TCP를 기반으로 구축되어 긴 연결 기능을 제공하고 반이중 및 중복 헤더 정보만 지원하는 HTTP의 비효율성 문제를 해결한다.
      • SDP(Session Description Protocol)는 스트리밍 미디어 기능 협상의 신호 내용을 캡슐화하는 데 사용되는 세션 설명 프로토콜이다. 두 개의 WebRTC 에이전트는 이 프로토콜을 통해 연결을 설정하는 데 필요한 모든 상태를 공유한다.
      • 프로토콜은 표준/관례이고, 프로토콜 스택은 프로토콜의 구현으로, 코드, 함수 라이브러리 및 상위 계층 응용 프로그램이 호출할 수 있는 것으로 이해될 수 있다.
  • 전송 매체
    • 미디어 채널(미디어 채널) 사용 필요, SRTP(음성 및 영상용), SCTP(데이터 채널용) 사용
      • SCTP와 SRTP는 멀티플렉싱, 정체 및 흐름 제어 제공, 부분적으로 신뢰할 수 있는 전달 및 부분적으로 UDP 위에 기타 추가 서비스를 제공하는 데 사용된다.
      • DTLS는 반대쪽 끝의 데이터 전송을 보호하는 데 사용된다.
    • 신호와 달리 미디어는 네트워크를 통해 이동하는 데 다른 경로를 사용하고 다르게 동작한다.

• WebRTC는 미디어와 비디오를 처리한다.

  • WebRTC는 VoIP 기술을 사용하여 미디어를 처리하고 SRTP(안전하고 암호화된 RTP 버전)를 기반으로 네트워크를 통해 전송한다.
  • WebRTC 오디오 및 비디오는 비디오 및 오디오 데이터를 압축하고 압축 해제하는 알려진 알고리즘인 코덱을 사용하여 작동한다.

• WebRTC 작동 방식에 대한 간략한 설명

  • 오디오, 비디오 또는 모든 데이터를 실시간으로 보낼 수 있다.
  • 브라우저가 서로 액세스할 수 있도록 하려면 NAT 통과 메커니즘을 사용해야 한다.
  • 때로는 P2P가 중계서버(TURN)를 거쳐야 하는 경우도 있다.
  • WebRTC를 사용하려면 신호와 미디어를 서로 분리하여 고려해야 한다.
  • 물론, P2P를 사용하지 않고 미디어 서버를 통해서도 P2P 관련 기능을 구현할 수 있다.
    • 미디어 서버: 여러 사람이 음성 및 영상 통화를 할 때 기존의 P2P 통신은 다소 어려워집니다. 이때 수신하거나 전송해야 하는 클라이언트 수를 줄이고, 중계 역할을 한다.

CentOS에서 Coturn 서버 설치 및 설정하기

1. Coturn 설치

   Coturn 서버를 설치하기 위해 먼저 CentOS의 패키지 관리자를 통해 설치한다.

   sudo yum install epel-release
   sudo yum install coturn
   

2. Coturn 설정 파일 수정

   Coturn의 주 설정 파일은 /etc/coturn/turnserver.conf에 위치한다. 이 파일을 수정하여 Coturn 서버를 설정한다.

   sudo vi /etc/coturn/turnserver.conf
   

   주요 설정 항목은 다음과 같다. 각 항목을 필요에 맞게 설정한다.:

   # 리스닝 포트 설정
   listening-port=3478
   
   # 외부 IP 설정 (Coturn 서버의 공인 IP)
   external-ip=<YOUR_EXTERNAL_IP>
   
   # relay IP 설정 (Coturn 서버의 내부 IP)
   relay-ip=<YOUR_INTERNAL_IP>
   
   # 사용자 인증 시크릿 설정
   static-auth-secret=<YOUR_STATIC_AUTH_SECRET>
   
   # realm 설정 (Coturn 서버의 도메인 이름)
   realm=<YOUR_REALM>
   
    lt-cred-mech
   
    user=id:password
   

   위 설정에서 <YOUR_EXTERNAL_IP>, <YOUR_INTERNAL_IP>, <YOUR_STATIC_AUTH_SECRET>, <YOUR_REALM> 부분은 실제로 사용할 서버의 정보로 대체되어야 한다.

3. Coturn 서버 시작

   Coturn 서버를 시작한다.

   sudo systemctl start coturn
   또는 
   /usr/bin/turnserver -c /etc/turnserver.conf --pidfile /run/coturn/turnserver.pid
   

   서버가 시작되면 Coturn 서버가 지정된 포트에서 실행된다.

4. 방화벽 설정

   Coturn 서버가 올바르게 작동하려면 방화벽에서 포트를 열어야 한다. 기본적으로 Coturn은 UDP 및 TCP 포트 3478을 사용한다. 필요에 따라 방화벽 설정을 조정한다…

   sudo firewall-cmd --zone=public --add-port=3478/tcp --permanent
   sudo firewall-cmd --zone=public --add-port=3478/udp --permanent
   sudo firewall-cmd --reload
   

5. 부가적인 설정

   필요에 따라 추가적인 Coturn 설정을 수행할 수 있다. 예를 들어, TLS(SSL)을 사용하거나 TURN REST API를 활성화하는 등의 설정을 변경할 수 있다.

   • TLS 설정: /etc/turnserver.conf에서 TLS 관련 설정을 추가 및 수정한다.
   • TURN REST API 설정: 필요한 경우 REST API를 활성화하고 관련 설정을 수정한다.

Coturn 서버 설정

Coturn 서버와 WebRTC가 작동하는 샘플 코드는 다음과 같은 구성으로 설정할 수 있다. Coturn 서버를 먼저 설정하고, WebRTC 클라이언트를 구성하여 서로 통신하게 한다.

1. Coturn 서버 설정

위의 단계를 따라 Coturn 서버를 설정한다.

2. WebRTC 클라이언트 샘플 코드

다음은 WebRTC를 사용하여 피어 연결을 설정하는 간단한 HTML/JavaScript 샘플 코드이다. 이 코드에서는 Coturn 서버를 사용하여 피어 간의 직접 연결이 불가능한 경우에 중계를 수행한다.

HTML (index.html)

<!DOCTYPE html>
<html>
<head>
    <title>WebRTC Sample</title>
</head>
<body>
    <h1>WebRTC Sample</h1>
    <video id="localVideo" autoplay playsinline></video>
    <video id="remoteVideo" autoplay playsinline></video>

    <script>
        const configuration = {
            iceServers: [
                {
                    urls: 'stun:stun.l.google.com:19302'
                },
                {
                    urls: 'turn:<YOUR_TURN_SERVER_IP>:3478',
                    username: '<YOUR_USERNAME>',
                    credential: '<YOUR_CREDENTIAL>'
                }
            ]
        };

        const localVideo = document.getElementById('localVideo');
        const remoteVideo = document.getElementById('remoteVideo');

        let localStream;
        let peerConnection;

        async function start() {
            localStream = await navigator.mediaDevices.getUserMedia({ video: true, audio: true });
            localVideo.srcObject = localStream;

            const servers = null;
            peerConnection = new RTCPeerConnection(configuration);

            peerConnection.addEventListener('icecandidate', event => {
                if (event.candidate) {
                    console.log('New ICE candidate: ', event.candidate);
                }
            });

            peerConnection.addEventListener('track', event => {
                remoteVideo.srcObject = event.streams[0];
            });

            localStream.getTracks().forEach(track => {
                peerConnection.addTrack(track, localStream);
            });

            const offer = await peerConnection.createOffer();
            await peerConnection.setLocalDescription(offer);

            // Normally you'd send the offer to the remote peer through signaling server
            // Here we're simulating it by setting the remote description locally
            await simulateRemoteAnswer(offer);
        }

        async function simulateRemoteAnswer(offer) {
            const remotePeerConnection = new RTCPeerConnection(configuration);
            remotePeerConnection.addEventListener('icecandidate', event => {
                if (event.candidate) {
                    peerConnection.addIceCandidate(event.candidate);
                }
            });

            remotePeerConnection.addEventListener('track', event => {
                remoteVideo.srcObject = event.streams[0];
            });

            localStream.getTracks().forEach(track => {
                remotePeerConnection.addTrack(track, localStream);
            });

            await remotePeerConnection.setRemoteDescription(offer);
            const answer = await remotePeerConnection.createAnswer();
            await remotePeerConnection.setLocalDescription(answer);
            await peerConnection.setRemoteDescription(answer);
        }

        start();
    </script>
</body>
</html>

이 코드는 두 개의 <video> 요소를 사용하여 로컬 및 원격 비디오 스트림을 표시한다. Coturn 서버 정보는 iceServers 배열에 설정되어 있다. 실제로는 시그널링 서버를 통해 offer와 answer를 교환해야 하지만, 여기서는 단순화를 위해 로컬에서 이를 시뮬레이션하고 있다.

1. <YOUR_TURN_SERVER_IP>을 Coturn 서버의 IP 주소로 바꾸고,
2. <YOUR_USERNAME>과 <YOUR_CREDENTIAL>을 Coturn 서버에서 설정한 사용자 이름과 비밀번호로 바꿉니다.

이제 웹 서버에서 이 HTML 파일을 호스팅하고 브라우저에서 열면 WebRTC 연결을 테스트할 수 있다.

연결 테스트

서버가 잘 구동(/usr/bin/turnserver -c /etc/turnserver.conf --pidfile /run/coturn/turnserver.pid)되었다면 아래의 사이트에 접속해서
https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/

STUN or TURN URI: turn:xxx,xxx,xxx,xxx
TURN username:설정화일에서 예제로 입력했던 user=id:password 중 id
TURN password:설정화일에서 예제로 입력했던 user=id:password 중 pssword

Gatther 해해보면

7.836 srflx 4172981128 udp 133.130.186.203 60564 100 | 32030 | 255 stun:xxx.xxx.xxx.xxx:3478
7.910 relay 835235681 udp xxx.xxx.xxx.xxx:3478 59541 2 | 32031 | 255 turn:xxx.xxx.xxx.xxx:3478?transport=udp udp
39.946 Done
처럼 접속이 성공한다.

퀴즈: WebRTC와 Coturn 서버 설정

1. 질문: WebRTC 애플리케이션에서 Coturn 서버의 주요 목적은 무엇인가?

   답변: Coturn 서버는 WebRTC 애플리케이션에서 클라이언트 간의 통신을 중계하는 역할을 한다. 직접 연결이 불가능할 때 NAT 트래버셜(Traversal)을 가능하게 하고, 시그널링과 ICE(Interactive Connectivity Establishment) 프레임워크를 지원하여 연결을 용이하게 한다.

2. 질문: Cent에서 Coturn을 설치하기 위해 사용하는 명령어는 무엇인가?

   답변: 아래 명령어를 사용한다:

    CentOS
    sudo yum install epel-release 
    sudo yum install coturn
    
    우분투라면
    sudo apt-get -y update
    sudo apt-get -y install coturn
   

3. 질문: Coturn 설정 파일(/etc/turnserver.conf)에 반드시 포함해야 할 주요 매개변수는 무엇인가?

   답변: Coturn 설정 파일에는 다음과 같은 주요 매개변수가 포함되어야 한다:

   listening-ip:0.0.0.0
   listening-port=3478
   relay-ip=<YOUR_SERVER_IP>
   external-ip=<YOUR_EXTERNAL_IP>
   static-auth-secret=<YOUR_STATIC_AUTH_SECRET>
   realm=<YOUR_REALM>(도에인.컴)
   min-port=10000
   max-port=20000
   user=id:password
   

4. 질문: 사용자 지정 설정으로 Coturn 서버를 시작하는 방법은 무엇인가?

   답변: 다음 명령어로 Coturn 서버를 시작할 수 있다:

   sudo turnserver -c /etc/turnserver.conf -a -v
   

5. 질문: Coturn이 올바르게 작동하도록 하기 위해 열어야 할 방화벽 포트는 무엇인가?

   답변: 방화벽에서 포트 3478과 5349 (TLS)를 열어야 한다:

   sudo ufw allow 3478/tcp
   sudo ufw allow 3478/udp
   sudo ufw allow 5349/tcp
   sudo ufw allow 5349/udp
   또는 
   sudo firewall-cmd --zone=public --add-port=3478/udp --permanent 
   sudo firewall-cmd --zone=public --add-port=5349/tcp --permanent 
   sudo firewall-cmd --reload
   또는
   sudo iptables -A INPUT -p udp --dport 3478 -j ACCEPT 
   sudo iptables -A INPUT -p tcp --dport 5349 -j ACCEPT 
   sudo service iptables save
   

6. 질문: WebRTC 클라이언트 설정에서 iceServers는 무엇을 위해 사용되나?

   답변: iceServers는 클라이언트가 ICE 프레임워크를 통해 NAT 트래버셜을 수행할 수 있도록 STUN 및 TURN 서버 정보를 제공하는 역할을 한다.

7. 질문: 아래 iceServers 설정을 수정하여 자신의 Coturn 서버를 사용하도록 변경하는 방법은 무엇인가?

   const configuration = {
       iceServers: [
           {
               urls: 'stun:stun.l.google.com:19302'
           },
   

   답변: urls 항목을 자신의 Coturn 서버의 주소로 변경하고, username과 credential을 설정하여 아래와 같이 수정한다:

   const configuration = {
       iceServers: [
           {
               urls: 'turn:<YOUR_TURN_SERVER_IP>:3478',
               username: '<YOUR_USERNAME>',
               credential: '<YOUR_CREDENTIAL>'
           },
   

추가 퀴즈: NAT 트래버셜, 시그널링, ICE 프레임워크

1. 질문: NAT 트래버셜(Traversal)이란 무엇을 의미하나?

   답변: NAT 트래버셜은 네트워크 주소 변환(NAT)과 방화벽을 통과하여 피어 간의 직접적인 연결을 가능하게 하는 기술이다. NAT 트래버셜은 피어 간의 네트워크 주소를 교환하고 중계 서버(STUN 및 TURN)를 통해 데이터를 전달하여 연결을 용이하게 한다.

2. 질문: WebRTC에서 시그널링 서버의 역할은 무엇인가?

   답변: 시그널링 서버는 WebRTC 피어 간의 연결을 설정하기 위해 제안(Offer) 및 응답(Answer) SDP를 중계하고 피어 간의 네트워크 설정 메타데이터를 전송하는 역할을 한다. 시그널링 서버는 피어가 서로의 위치를 알 수 있도록 도와주며, 연결 세션을 초기화하고 해제하는 역할을 담당한다.

3. 질문: ICE(Interactive Connectivity Establishment) 프레임워크는 어떤 역할을 하나?

   답변: ICE 프레임워크는 네트워크 주소 변환(NAT)과 방화벽을 통과하여 최적의 연결 경로를 찾아주는 기술이다. ICE는 STUN(회전 서버)과 TURN(트래버스 서버)을 사용하여 클라이언트가 네트워크 환경에서 직접 피어 간 연결을 수립할 수 있도록 돕다.

4. 질문: ICE 프레임워크에서 ICE 후보(Candidate)란 무엇을 나타내나?

   답변: ICE 후보는 클라이언트가 연결할 수 있는 네트워크 인터페이스의 IP 주소, 포트 및 프로토콜을 나타냅니다. ICE 후보는 클라이언트가 네트워크 환경을 탐색하고 최적의 연결 경로를 선택하는 데 사용된다.

5. 질문: ICE 프레임워크에서 STUN 서버와 TURN 서버의 차이점은 무엇인가?

   답변: STUN(세션 트래버셜 유틸리티 네트워크) 서버는 클라이언트의 공인 IP 주소와 포트를 발견하는 데 사용된다. 반면, TURN(회전 서버)은 클라이언트가 직접 연결할 수 없는 경우 데이터 중계를 제공하여 피어 간의 통신을 가능하게 한다.

6. 질문: ICE 프레임워크에서 Candidate Gathering는 어떻게 이루어지나요?

   답변: Candidate Gathering은 클라이언트가 가능한 모든 네트워크 인터페이스를 탐색하고, 각 인터페이스의 IP 주소와 포트를 수집하는 과정이다. 이 후보들은 ICE 프레임워크를 통해 다른 피어와의 연결을 시도할 때 사용된다.

7. 질문: WebRTC에서 ICE 커넥션 상태가 new, checking, connected, completed, failed, disconnected일 때 각각 무슨 의미인가?

   답변:

   • new: ICE 커넥션 객체가 생성되었지만 아직 초기화되지 않음.
   • checking: ICE 후보를 수집하고 연결 가능성을 검사 중.
   • connected: ICE 커넥션을 통해 피어 간의 데이터 통신이 성공적으로 이루어짐.
   • completed: ICE 프로세스가 완료되고 최적의 연결 경로가 선정됨.
   • failed: ICE 후보를 수집하고 연결을 시도했으나 실패한 상태.
   • disconnected: ICE 커넥션에서 피어와의 연결이 끊어짐.

8. 질문: ICE 프레임워크에서 ICE 커넥션 객체의 역할은 무엇인가?

   답변: ICE 커넥션 객체는 클라이언트 간의 통신을 관리하는 중요한 역할을 한다. ICE 후보의 수집, 검사, 연결 설정 및 관리를 통해 피어 간의 최적의 네트워크 연결을 제공한다.

9. 질문: ICE 프레임워크에서 ICE 실패(Failure)는 어떤 경우에 발생하나?

   답변: ICE 실패는 클라이언트가 모든 가능한 후보를 수집하고 검사한 후에도 연결을 설정할 수 없는 경우 발생한다. 이는 네트워크 환경이나 방화벽 설정 등의 문제로 인해 발생할 수 있다.

10. 질문: WebRTC에서 SDP(Session Description Protocol)가 ICE와 어떻게 관련되나?

    답변: SDP는 WebRTC 세션을 설정하기 위해 피어 간에 교환되는 메타데이터 형식이다. SDP는 ICE 프레임워크를 통해 생성된 후보들과 네트워크 연결 설정을 포함하며, 피어 간의 미디어 스트림을 정의하는 데 사용된다.

추가 퀴즈: WebRTC 소스 코드

1. 질문: WebRTC에서 getUserMedia() 메서드는 무엇을 하나?

   답변: getUserMedia() 메서드는 웹 브라우저에서 사용자의 오디오와 비디오를 얻기 위해 사용된다. 이를 통해 웹 애플리케이션은 사용자의 카메라와 마이크에 접근하여 미디어 스트림을 획득할 수 있다.

2. 질문: RTCPeerConnection 객체는 무엇을 나타내나?

   답변: RTCPeerConnection 객체는 WebRTC 피어 간의 연결을 나타내며, 오디오와 비디오 스트림을 교환할 수 있도록 도와줍니다. ICE 프레임워크를 사용하여 NAT 트래버셜과 통신을 관리하며, 미디어 스트림의 효과적인 전송을 가능하게 한다.

3. 질문: ICE 프레임워크에서 ICE의 역할은 무엇인가?

   답변: ICE(Interactive Connectivity Establishment)는 WebRTC에서 피어 간의 네트워크 연결을 설정하는 프레임워크이다. 네트워크 주소 변환(NAT)과 방화벽을 통과하면서 최적의 연결 경로를 찾아주며, STUN 및 TURN 서버를 사용하여 연결을 가능하게 한다.

4. 질문: createOffer()와 createAnswer() 메서드는 각각 무엇을 하나?

   답변: createOffer() 메서드는 로컬 피어에게 연결을 제안하는 SDP(Session Description Protocol) 오퍼를 생성한다. createAnswer() 메서드는 오퍼에 대한 응답으로 SDP 앤서를 생성하여 원격 피어와의 연결을 수립한다.

5. 질문: addTrack() 메서드는 어떤 역할을 하나?

   답변: addTrack() 메서드는 로컬 스트림에서 트랙을 추가하여 RTCPeerConnection에 연결한다. 이를 통해 오디오 및 비디오 트랙을 원격 피어에게 전송할 수 있다.

6. 질문: ICE 후보(Candidate)는 무엇을 나타내나?

   답변: ICE 후보는 클라이언트가 다른 피어와 연결할 수 있는 네트워크 인터페이스의 IP 주소, 포트 및 프로토콜을 나타냅니다. ICE 후보는 RTCPeerConnection을 통해 생성되고 교환되어 연결을 설정하는 데 사용된다.

7. 질문: icecandidate 이벤트는 어떤 때 발생하나?

   답변: icecandidate 이벤트는 ICE 프레임워크가 ICE 후보를 생성할 때 발생한다. 이 이벤트는 ICE 후보가 생성되었음을 나타내며, 원격 피어와의 연결을 설정하는 데 필요한 정보를 포함한다.

8. 질문: track 이벤트는 어떤 때 발생하나?

   답변: track 이벤트는 원격 피어에서 새로운 미디어 트랙이 수신될 때 발생한다. 이 이벤트를 통해 원격 피어로부터 전송되는 오디오 및 비디오 스트림을 수신할 수 있다.

9. 질문: WebRTC의 SDP(Session Description Protocol)는 무엇을 포함하나?

   답변: SDP는 웹 브라우저 간에 미디어 세션을 설정하는 데 사용되는 텍스트 기반 프로토콜이다. SDP에는 미디어 유형, 포트, 코덱 및 네트워크 정보가 포함되어 있다.

10. 질문: WebRTC에서 시그널링 서버의 역할은 무엇인가?

    답변: 시그널링 서버는 웹RTC 피어 간의 연결을 설정하기 위해 제안(Offer) 및 응답(Answer) SDP를 교환하는 중개 역할을 한다. 시그널링 서버는 피어가 서로 통신할 수 있도록 필요한 메타데이터를 전송한다.

WebRTC 관련 오픈소스

kurento-media-server

출처 : https://qiita.com/Otama75/items/7153607d3cde868aaf5c
추가 : https://onetech.jp/blog/makes-webrtc-applications-easier-with-kurento-5435
docker : https://hub.docker.com/r/kurento/kurento-media-server-dev
참고프로젝트 :https://velog.io/@jupiter-j/프로젝트-종료-EyesTalk

Kurento는 오픈 소스 WebRTC 미디어 서버입니다. 화상 통화 및 화상 회의와 같은 미디어 스트리밍 기능을 갖춘 웹 애플리케이션을 구축하는 메커니즘을 제공합니다. Kurento 이외에도 이러한 WebRTC 미디어 서버에는 여러 가지가 있지만 Kurento의 특징 중 하나는 MCU에 의한 화상 회의 앱을 구축할 수 있다는 것입니다.

openvidu

자료 : https://velog.io/@duddnd904/OpenVidu-총정리

간단설치방법 :https://gigazine.net/news/20200504-openvidu/

안드로이드 오픈미팅: https://gigazine.net/news/20201129-apache-openmeetings/