WebRTC 연결
시그널링
WebRTC는 중간 서버 없이는 연결을 생성할 수 없다
이를 신호 채널 또는 신호 서비스라고 한다
이메일 등을 통한 연결 설정 전 정보를 교환하는 모든 종류의 통신 채널을 말한다
우리가 교환해야 하는 정보는 SDP 만 포함하는 Offer 와 Answer
연결 개시자 피어 A 는 제안을 생성한다
그 후 선택한 신호 채널을 사용하여 피어 B 에게 제안을 보낸다
피어 B는 신호 패널에서 제안을 받고 응답을 생성한다
그 다음 신호 채널을 따라 피어 A 로 보낸다
제안(Offer) 생성 (A) -> 제안 받고 응답(Answer) 생성 (B) -> 피어 A
세션 설명 (Session Description)
WebRTC 연결의 끝점 구성을 세션 설명이라고 한다
설명에는 전송되는 미디어 종류, 형식, 사용중인 프로토콜, 엔드포인트의 IP 주소 및 포트, 미디어 전송 엔드포인트를 설명하는데 필요한 기타 정보가 포함된다
이 정보는 SDP ( Session Description Protocol) 을 사용하여 교환 및 저장된다
(기술적으로 SDP 는 프로토콜이 아니라 장치간 미디어를 공유하는 연결을 설명하는 데이터 형식)
Offer
사용자가 다른 사용자에게 WebRTC 호출을 시작하면 제안이라는 특별한 설명 생성
해당 설명에는 발신자가 제안한 통신 구성에 대한 모든 정보가 포함된다
Answer
수신자는 통화 종료에 대한 설명인 Answer 로 응답한다
이 방식으로 두 장치 간 미디어 데이터를 교환하기 위해 필요한 정보를 서로 공유한다
이 교환은 ICE (대화형 연결 설정) 프로토콜을 사용하여 처리된다
ICE 는 두 장치가 네트워크 주소 변환 (NAT) 에 의해 분리된 경우에도
장치간 Offer 와 Answer 를 교환할 수 있는 중개자를 사용할 수 있도록 한다
각 피어는 자신을 설명하는 local description (로컬 설명) 과
다른 쪽 끝을 설명하는 remote description (원격 설명) 두 가지 설명을 서로 보관한다
Offer/Answer 프로세스는 연결이 처음 설정될 때뿐만 아니라
통화 형식이나 기타 구성을 변경할 때마다 수행된다
새로운 호출과 기존 호출 제안과 응답을 수행하는 기본 단계는 다음과 같다
Offer/Answer 수행 기본 단계
- 발신자는 MediaDevices.getUserMedi a를 통해 로컬 미디어를 캡쳐한다
- 발신자는 RTCPeerConnection 을 만들고 RTCPeerConnection.addTrack() 를 호출한다
- 발신자는 Offer 생성을 위해 RTCPeerConnection.createOffer() 를 호출
- 발신자는 Offer 를 local description (로컬 연결의 끝)으로 설정하도록 RTCPeerConnection.setLocalDescription() 을 호출한다
- setLocalDescription 이후 발신자는 STUN 서버에 ICE candidates (후보) 생성을 요청한다
- 발신자는 신호 서버(signaling server)를 사용하여 의도한 수신자에게 Offer 를 전송한다
- 수신자는 Offer를 받고 이를 remote description (연결의 다른쪽 끝) 으로 기록하도록 RTCPeerConnection.setRemoteDescription() 호출
- 신자는 통화 종료에 필요한 모든 설정을 수행한다
-> 로컬 미디어를 캡처하고 RTCPeerConnection.addTrack() 를 통해 각 미디어 트랙을 피어 연결에 연결한다 - 그 후 수신자는 RTCPeerConnection.createAnswer() 를 호출하여 응답 생성
- 수신자는 RTCPeerConnection.setLocalDescription() 를 호출하여 생성된 응답을 전달하고 응답을 localDescription (로컬 설명) 으로 설정한다 수신자는 이제 연결 양쪽 끝 구성 정보를 가지고 있다
- 수신자는 signaling server (신호 서버)를 사용하여 발신자에게 응답을 보낸다
- 발신자는 수신자의 응답을 받는다
- 호출자는 RTCPeerConnection.setRemoteDescription() 를 호출하여 응답을 호출 종료에 대한 RemoteDescription (원격 설명) 으로 설정한다 이제 호출자도 두 피어의 구성을 알게되고 연결된 구성 대로 미디어 통신이 흐르기 시작한다
Pending and current descriptions (보류와 현재 설명)
프로세스를 한 단계 더 깊이 살펴보면 두 설명을 반환하는 속성인
localDescription, remoteDescription 이 보이는 것 처럼
단순하지 않다는 것을 알 수 있다
재협상 중 호환되지 않는 형식을 제안하기 때문에
제안이 거부될 수 있다
때문에 각 엔드포인트는 새 형식을 제안할 수 있지만
다른 피어에서 수락할 때까지 실제로 전환하지 않는 기능이 필요하다
이러한 이유로 WebRTC는 보류 중인 설명과 현재 설명을 사용한다
current description
current description 은
RTCPeerConnection.currentLocalDescription 및 RTCPeerConnection.currentRemoteDescription 속성에 의해 반환된다
current description 는 현재 연결에서 실제로 사용중인 설명을 나타내는 것으로 양측이 사용하기로 완전히 동의한 가장 최근의 연결
pending description
pending description 은
RTCPeerConnection.pendingLocalDescription 및 RTCPeerConnection.pendingRemoteDescription에 의해 반환된다
setLocalDescription() 또는 setRemoteDescription()을 각각 호출한 후 현재 고려 중인 설명을 나타낸다
when reading the description
RTCPeerConnection.localDescription 및 RTCPeerConnection.remoteDescription에 의해 반환된다
반환된 값은 보류중인 설명이 null 이 아닌 경우
pendingLocalDescription/pendingRemoteDescription 의 값이다
그렇지 않으면 current description (현재 설명)
currentLocalDescription/currentRemoteDescription 이 반환된다
setLocalDescription() 또는 setRemoteDescription()을 호출하여 description (설명) 을 변경하면 지정된 설명이 pending description (보류 중인 설명)으로 설정되고 WebRTC 계층이 허용 여부를 평가하기 시작한다
제안된 설명이 동의되면 currentLocalDescription 또는 currentRemoteDescription 값이 pending description으로 변경되고 pending description 이 다시 null로 설정되어 pending description 이 없음을 나타낸다
pendingLocalDescription 에는 고려 중인 Offer 또는
Answer 뿐만 아니라 Offer 또는 Answer 이 생성된 이후
이미 수집된 모든 local ICE candidates 가 포함된다
마찬가지로 pendingRemoteDescription 에는 RTCPeerConnection.addIceCandidate() 호출에 의해 제공된
모든 remote ICE candidates 가 포함된다자세한 내용은 속성 및 메서드에 대한 개별 문서를 참조
https://developer.mozilla.org/en-US/docs/Web/Media/Formats/WebRTC_codecs
