나 자신을 위해 영상 통화를 걸어보세요.

Web Real-Time Communication(영어: Web Real-Time Communication)의 약어에서 이름을 따온 WebRTC는 실시간 음성을 위한 웹 브라우저를 지원하는 API입니다. 대화 또는 영상 대화. 2011년 6월 1일에 오픈 소스로 제공되었으며 Google, Mozilla 및 Opera의 지원을 받아 World Wide Web Consortium의 W3C 권장 사항에 포함되었습니다.

우선 API이자 프로토콜입니다.

둘째, 브라우저에서 음성 및 영상 통화를 할 수 있는 API입니다. 실제로 화면 공유 기능도 있습니다.

마지막으로 이는 이제 W3C 표준이 되었으며 주요 브라우저 제조업체는 이를 호환 가능하게 만들었습니다.

하지만 webrtc를 잘 사용하려면 먼저 websocket을 이해해야 합니다. 웹소켓의 경우 소셜 채팅, 멀티플레이어 게임, 공동 편집, 화상 회의, 위치 기반 애플리케이션(지도) 및 높은 실시간성을 요구하는 기타 시나리오 등 모든 사람이 익숙해야 합니다. 더 일반적으로 사용되는 WeChat, QQ, 일부 라이브 방송 소프트웨어 등도 웹 소켓을 기반으로 메시지와 신호를 전달합니다. 이 내용을 보시면 시그널링을 망설이실 수도 있으니 계속해서 읽어주세요.

webrtc는 P2P 기술입니다. 실제로 이는 엔드투엔드(end-to-end)입니다. 즉, 오디오 및 비디오 스트림이 서버에 의해 중계되지 않고 한 쪽 끝에서 다른 쪽 끝으로 직접 전송된다는 의미입니다.

서버를 거치지 않고, 즉 진행 중에 갑자기 서버가 다운되는 경우에도 통화를 계속할 수 있나요?

네! 그러나 오디오 및 비디오 스트림을 보내기 전에 P2P 연결을 설정해야 합니다. 연결을 설정하기 전에 서버는 이 신호를 통화의 양쪽 끝의 식별자로 전달해야 합니다.

webrtc를 사용하여 호출을 구현하려면 먼저 신호를 전달하고 연결을 설정해야 합니다. 연결을 설정할 때 신호 전달을 위해 웹소켓을 사용하는 것이 가장 좋습니다. 우리 모두 알고 있듯이 websocket은 이 채널의 모든 끝에서 메시지를 보낸 사람을 포함하여 모든 끝에서 메시지 흐름을 수신할 수 있습니다.

왜 서버를 거치지 않고 상대방의 영상, 음성 스트림을 직접 얻을 수 있나요? 이는 P2P 채널이 이미 설정되어 있기 때문입니다. 비디오 및 오디오 스트림을 전송할 때 어떤 종류의 서버가 필요합니까? 이때 일부 친구들은 의구심을 표시했을 것입니다. 오디오 및 비디오 스트림이 서버를 통과하지 못할 수 있습니까? 예, 모두에게 거짓말을 했습니다. 서버를 통과해야 하지만 온라인으로 서버를 전달하는 것만 필요합니다. webrtc 오디오 및 비디오 스트림을 전달하는 동일한 LAN의 두 개 이상의 로컬 터미널이 있는 경우에는 실제로 필요하지 않습니다. 전송 서버, 그러나 온라인 필요할 수도 있고 필요하지 않을 수도 있으며 여기서도 구멍 뚫기 개념이 포함됩니다.

우리는 일반적으로 홀 펀칭, 인트라넷 침투, NAT 통과 및 모든 종류의 고급 용어와 같은 멋진 어휘를 들을 수 있지만 실제로는 매우 이해하기 쉽습니다. 우리 모두 알고 있듯이 서로 다른 두 네트워크에 있는 두 호스트는 직접 통신할 수 없으며 대신 공용 네트워크나 해당 게이트웨이를 통과해야 합니다. 홀 드릴링, 인트라넷 침투 및 NAT 통과는 실제로 동일한 것을 의미합니다. 즉, 공용 네트워크를 거치지 않고 직접 연결하지 않고 UDP를 사용하여 서로 다른 네트워크에 있는 두 호스트를 상호 연결하는 것입니다. 땅콩 껍질을 가지고 놀아 본 학생들은 인트라넷 침투의 개념을 확실히 이해할 것입니다.

로컬 개발의 경우 두 개의 호스트와 하나의 LAN이 인트라넷 침투 없이 직접 통신할 수 있습니다.

온라인 개발의 경우 STUN이 성공적으로 구멍을 뚫을 수 있다면 전송 서버가 필요하지 않습니다. 하지만 홀 드릴링이 실패할 가능성이 있습니다. 왜일까요? 공용 네트워크가 없기 때문에 사업자에게는 수익이 발생하지 않지만 통신 비용이 발생하므로 이를 제한해야 합니다. 해외에서는 시추 성공 확률이 70%지만, 중국에서는 50%도 안 된다.

따라서 홀 드릴링이 실패하는 것을 방지하기 위해 TURN 전송 서버를 사용하여 최종 보증을 위해 스트리밍 미디어 데이터를 전달합니다.

또한 P2P 설정을 달성하는 데 도움이 될 수 있는 역방향 연결이라는 또 다른 방법이 있습니다. 그 원칙은 한 쪽이 공용 네트워크를 사용해야 한다는 것인데, 여기에도 제한이 있습니다.

Coturn 릴레이 서버는 STUN과 TURN의 두 부분으로 구성됩니다. STUN은 구멍을 파는 데 도움이 되고 TURN은 스트리밍 데이터를 전달하는 데 도움이 됩니다.

##연결 프로세스

다음 API는 모두 2021.12.06 기준 최신 API입니다.

##질문이 있습니다

For 모두가 볼 수 있도록 sdp의 본질은 자신의 미디어 정보와 코덱 정보입니다

우리는 서로의 미디어 정보와 코덱 정보를 알고 있으므로 협상을 잘 해야 합니다. 비디오 및 오디오 스트림을 디코딩하고 렌더링하는 방법은 무엇입니까?

특정 프로세스의 경우 친구가 이 기사를 읽을 수 있습니다. WebRTC TURN 프로토콜 및 턴서버 실습에 대한 첫 번째 소개입니다.

webrtc의 오디오 및 비디오 컬렉션과 데스크탑 컬렉션을 이해합니다.

websocket 및 webrtc의 전체 링크 설정 프로세스를 이해합니다.

1V1 텍스트 전송, 비디오를 실현합니다. 통화, 음성 통화, 화면 공유

영상 통화, 음성 통화 및 화면 공유 중에 스크린샷, 녹화, 화면 녹화 및 스크린샷, 녹화 및 화면 녹화의 온라인 재생을 실현합니다.

위 기능을 온라인으로 배포합니다.

여기서는 오디오 및 비디오 생성 프로세스에 대한 기본 흐름도를 그려보겠습니다.

기본 흐름도

이러한 신호 전달을 위해 웹소켓을 사용합니다. 여기에서 http를 사용하면 안 될까요?

우선 우리가 구현하려는 데모에는 원래 일반 문자 메시지를 보내는 기능이 포함되어 있는데, 이는 websocket을 사용하는 것입니다. (장기 및 단기 폴링은 너무 오래되었고 성능이 너무 나쁩니다.)

둘째, 첫 번째 점은 무시할 수 있습니다. http 요청은 서버에 대한 원래 경로로 다시 전송되지 않습니다. B에게 보내진다.

하지만 websocket을 사용하여 신호를 전달하려면 이 메시지가 동일한 파이프의 모든 끝에서 수신된다는 점을 분명히 이해해야 합니다. 따라서 위의 흐름도에서 모든 작은 화살표는 실제로 양방향입니다.

이때 노드 서비스 또는 클라이언트 측에서 푸시 메시지의 방향을 제어할 수 있습니다. 여기서는 AB 측에서 제어하도록 선택합니다.

둘째, 로컬에서 개발할 경우 컴퓨터 한 대와 브라우저 두 대를 사용하면 웹소켓 문자 메시지가 가능합니다. 그러나 음성 및 영상 통화는 전송 채널과 음성 및 영상 장비(마이크, 스피커 등)가 충돌하기 때문에 작동하지 않습니다. 따라서 동일한 LAN을 통해 두 대의 컴퓨터를 사용하여 이 문제를 해결할 수 있습니다. 또한 webrtc의 보안 제한으로 인해 https(온라인이든 로컬이든)와 도메인 이름을 사용해야 합니다. https와 도메인 이름을 온라인으로 구성하고 브라우저에서 https를 무시하고 호스트 파일 매핑을 구성하면 이 문제를 해결할 수 있습니다. .

다음으로 vue와 nodejs를 사용하여 가장 빠르고 쉬운 방법으로 데모를 구현합니다.

더 이상 고민하지 말고 시작해 보세요!

코드 일부 표시

여기서는 메시지를 신속하게 시작하고 신호를 전달하기 위해 타사 패키지인 소켓.io를 사용합니다. (vue-socket.io 사용을 권장합니다.) 컴포넌트에서 메시지와 시그널링을 주고받을 수 있습니다.

vuex에서 연결을 설정하고, 메시지를 받고, 신호를 수신하기 위해 소켓-io의 웹소켓을 넣습니다.

마찬가지로 노드 서비스에서도 소켓-io 패키지를 사용합니다.

비디오, 오디오 및 화면 공유의 경우 코드가 유사합니다. 예를 들어 비디오 캡처.

getUserMedia를 사용하면 오디오 및 비디오 듀얼 트랙 미디어 스트림을 수집할 수 있으며 구성할 수 있는 매개변수 제약 조건을 전달할 수 있습니다(오디오 또는 비디오 수집 여부 제어)

수집합니다 동적 미디어 스트림이 비디오 태그에 할당되고 자체 화면이 웹 페이지에 표시됩니다.

마찬가지로 오디오 컬렉션인 경우 Constraints 매개변수의 오디오를 false로 구성하기만 하면 됩니다.

컴퓨터 화면을 캡처하려면 getUserMedia API를 getDisplayMedia로 바꾸면 됩니다.

이때 비디오 개시자는 미디어 스트림을 수집한 후 수신단에 적용 신호를 보내야 합니다. 이는 수신자에게 영상 통화를 받을지 여부를 묻는 신호입니다.

수신되면 수신측에서는 자체 오디오 및 비디오 듀얼 트랙 미디어 스트림을 수집하고 피어 연결을 초기화하고 미디어 스트림을 이 파이프에 넣고 ICE 후보 정보를 모니터링하고 수집된 경우 전송합니다. 상대방에게 동의를 표시하고 동영상 작성자에게 답장합니다.

수신을 거부하는 경우 수신 측에서는 동영상 시작 측에 거부 신호를 보내는 회신을 보냅니다.

이때 수신 측에서 거부를 받으면 비디오 및 오디오 스트림 수집을 닫습니다.

수신 측에서 호출을 받으면 PeerConnection을 초기화하고 자신의 미디어 스트림을 이 파이프에 넣고 ICE 후보 정보를 모니터링하고 수집된 경우 상대방에게 보냅니다. 그리고 제안(이 제안에는 sdp가 포함되어 있음)을 생성하고 제안을 로컬에 넣은 다음 제안을 비디오 수신기로 보냅니다.

비디오 수신 측에서는 제안을 수신하여 원격 측에 배치하고 답변을 생성한 다음 로컬에 응답을 배치하고 이를 비디오 개시자에게 보냅니다.

영상 발신자는 답변을 수신하고 원격 측에 답변을 배치합니다.

이때 수신측과 개시측 모두 ICE 후보 정보를 듣고 있으며, 수집되면 상대방에게 전송됩니다. 모니터링되면 상대방의 동적 미디어 스트림이 B에 할당되어 재생됩니다.

스크린샷: 캔버스를 사용하고 관련 메서드인 getContext("2d").drawImage를 사용하여 웹 수준에서 이미지 캡처를 실현할 수 있습니다.

오디오/비디오/화면 녹화: MediaRecorder를 사용하여 우리의 미디어 스트림 또는 상대방의 미디어 스트림을 배열에 저장합니다.

저장된 정적 미디어 스트림을 비디오 태그에 할당하기만 하면 됩니다.

동일한 방식으로 오디오 및 비디오 스트림을 다운로드할 수 있습니다.

webrtc를 배포하려면 도메인 이름과 https라는 두 가지 중요한 조건이 필요합니다.

우리의 노드 서비스는 https + 도메인 이름일 뿐만 아니라 websocket에도 더 안전한 wss 프로토콜이 필요합니다. 우리의 websocket에 대해 wss를 구성해야 합니다.

지역 개발이 성공적이고 효과적일 수 있는 이유는 인트라넷이 공공망을 통하지 않고 직접 소통하기 때문에 인트라넷 침투가 이뤄지지 않기 때문이라고 앞서도 언급한 바 있다.

이 기능을 온라인으로 구현하려면 턴 릴레이 서버를 구성해야 합니다. centos 커널 구성 기사는 이 기사를, ubuntu 커널 구성 기사는 이 기사를 참조하세요.

개발 및 출시 이후 다음과 같은 문제점을 발견할 수 있습니다.

환경, 장비, 신호 오버플로, 알고리즘 비호환, 음향 및 회선으로 인한 에코, 네트워크 정체 및 불안정한 데이터 패킷 전송 속도로 인해 발생하는 지연.

일부 알고리즘을 추가하고 하드웨어 장비의 품질을 향상시켜 소음 반향과 지연을 줄일 수 있습니다.

소음의 경우 오디오를 수집할 때 NoiseSuppression: true를 설정하면 일부 환경 및 장치의 소음을 줄일 수 있습니다.

에코의 경우 오디오를 수집할 때 echoCancellation: true를 설정하여 에코를 제거할 수 있습니다.

나머지는 알고리즘, 기기, 네트워크가 처리합니다.

WebRTC 전송이 오디오 및 비디오 서비스의 품질을 보장하는 방법과 성숙한 애플리케이션이 이러한 세 가지 주요 문제를 어떻게 해결하는지 계속해서 연구할 수 있습니다.

영상 통화 중에 다양한 특수 효과를 사용할 수 있습니다. 미녀, 스티커 등.

하지만 webrtc라는 웹 분야에서 영상특수효과 분야는 매우 잠재되어 있는 분야입니다. 이런 상황이 발생한 이유는 js의 성능 문제 때문입니다.

더 간단한 방법은 캔버스를 사용하여 비디오 이미지에 필터 레이어를 추가하는 것이지만 본질적으로 미디어 흐름을 변경하지는 않습니다. 원격 끝으로 전송될 때 여전히 특별한 효과는 없습니다. 물론 웹소켓을 통해 원격 비디오 특수 효과를 제어할 수 있지만 비디오 스트림이 변경되지 않았으므로 상대방이 비디오 스트림을 다운로드하면 재생할 때 여전히 특수 효과가 없습니다.

또 다른 해결책은 다음과 같습니다. 구현 방법에 대해서는 자세히 설명하지 않겠습니다. (다음은 간단한 특수 효과 및 스티커입니다.)

n-1명의 사람들과 영상을 공유하고 싶기 때문에 n-1 PeerConnection 연결을 만들어야 합니다. 모두가 그렇습니다. 그러나 여기에는 누가 주도적으로 제안을 하느냐의 문제가 포함될 것입니다. 새로 가입한 회원이 다른 n-1 회원에게 제안을 보내도록 하거나 n-1 회원이 새로 가입한 회원에게 제안을 보내도록 할 수 있습니다. 여기서는 순회를 사용하여 PeerConnection을 생성하고 제안할 수 있습니다. 물론 서버가 여러 사람의 통화를 얼마나 잘 처리할 수 있는지에 따라 다릅니다.

여기서는 다단말 통신에 잘 알려진 통신 솔루션인 메시(Mesh)를 무의식적으로 사용했습니다. 메시란 2대2 통신을 통해 메시 구조를 이루는 것을 의미합니다. Mesh와 같은 통신 솔루션 외에 MCU도 있습니다. MCU 솔루션은 주로 같은 방에 있는 모든 단말기의 오디오 및 비디오 스트림을 믹싱하여 각 단말기로 전송하므로 서버에 많은 부담을 줍니다. 전송 서버가 터미널로부터 오디오 및 비디오 스트림을 수신한 후 이를 다른 터미널로 전달하는 SFU 통신 솔루션도 있습니다.

위의 일련의 이해, 사고, 구축, 개발, 배포 등을 마친 후 우리는 webrtc에 대한 예비적인 이해와 이해를 갖게 되었습니다. 우리는 이 분야에 대해 계속해서 심층적인 연구와 탐구를 수행해야 합니다. 지식에 대한 우리의 호기심과 갈증을 충족시키고, 이 분야의 기술을 향상시키며, 우리의 전반적인 지식 시스템을 풍요롭게 하기 때문에, 해보는 것은 어떨까요?

마지막으로 위의 내용은 모두 데이터, 개인 실험 및 개인 요약에서 나온 것입니다. 기사에 오류가 있으면 제때에 수정해 주시기 바랍니다.