WebRTC 세션의 수명
WEbRTC 를 사용하면 임의 데이터, 오디오, 또는 비디오 (혹은 이들의 조합)의
Peer to Peer 통신을 브라우저 애플리케이션으로 축할 수 있다
연결 설정 부터 연결 종료까지의 WebRTC 수명
연결 설정에 대한 설명과 실제 예는 아래의 링크 참조
연결 설정
웹은 너무 빠르게 성장해서 32비트 IP 주소 시스템의 한계를 극복하기 위해
64비트 주소 시정 시스템을 설계하였다
하지만 32비트 주소를 64비트로 변경하는 것이 어렵고 오래걸린 다는 것을 깨달았다
때문에 여러 컴퓨터가 32비트 IP 주소를 공유하도록 하는 방법을 생각해냈다
이것이 NAT(Network Address Translation)로
WAN(글로벌) IP 주소를 공유하는 LAN의 장치에 대한 데이터 인바운드 및 아웃바운드 라운딩을 처리하여
주소 공유를 지원하는 표준이다
사용자의 문제는 인터넷의 각 개별 컴퓨터가 더 이상 고유한 IP 주소를 가질 필요가 없고
각 장치의 IP 주소는 한 네트워크에서 다른 네트워크로 이동할 때뿐만 아니라
네트워크 주소가 변경될 경우에도 변경될 수 있다는 것이다
NAT 또는 DHCP로 peer to peer 네트워킹을 시도하는 개발자에게 이는 수수꼐끼를 야기한다
모든 사용자 장치에 대한 고유 식별자가 없으면 인터넷에서 특정 장치에 연결하는 방법을 즉시 알 수 없다
누구와 대화하고 싶은지 알고 있어도 연락 방법이나 주소를 반드시 알 필요는 없다
이는 친구 Michelle의 주소를 모를 때 소포에 "Michelle"이라는 라벨을 붙이고
우편함에 넣어 우편으로 보내는 것과 같다
그녀의 주소를 찾아 패키지에 포함시켜야 한다
그렇지 않으면 그녀는 당신이 왜 그녀의 생일을 또 잊어버렸는지 궁금해 할 것..
이것은 신호가 들어오는 곳이다
시그널링
시그널링은 두 장치 간 제어 정보를 전송하여 통신 프로토콜, 채널, 미디어 코덱 및 형식,
데이터 전송 방법 및 필요한 라우팅 정보를 결정하는 프로세스다
WebRTC의 시그널링 프로세스에 대해 알아야할 가장 중요한 사항은 사양에 정의되어있지 않다는 것이다
WebRTC 연결을 설정하는 프로세스의 기본 사항이 사양에서 제외된 이유는
두 장치가 서로 집접 접촉할 수 있는 방법이 없고
사양이 WebRTC의 가능한 모든 사용 사례를 예측할 수 없기 때문에
개발자가 적절한 네트워킹 기술과 메시징 프로토콜을 선택하도록 하는 것이 더 합리적이다
특히 개발자가 이미 두 장치를 연결하기 위한 방법을 가지고 있는 경우
WebRTC에 대해서만 사양에 정의된 다른 방법을 사용해야 하는 것은 의미가 없다
WebRTC는 진공 상태에 있지 않기 때문에 다른 연결이 작동할 가능성이 있으므로
기존 채널을 사용할 수 있는 경우 신호를 위한 추가 연결 채널을 추가하지 않아도 된다
신호 정보를 교환하기 위해 WebSocket 연결을 통해 JSON 개체를 앞뒤로 보내도록 선택하거나
적절한 채널을 통해 XMPP 또는 SIP를 사용하거나 폴링 또는
기타 기술 조합과 함께 HTTPS를 통해 XMLHttpRequest를 사용할 수 있다
이메일을 신호 채널로 사용할 수도 있다
시그널링을 수행하기 위한 채널이 네트워크를 통해 있을 필요조차 없다는 점도 주목할 가치가 있다
한 피어는 인쇄할 수 있는 데이터 개체를 출력하고, 다른 장치로 물리적으로 운반하고,
해당 장치에 입력한 다음 해당 장치에서 응답을 출력하여 도보로 반환하는 등의 작업을 수행할 수 있다 WebRTC 피어 연결이 열릴 때까지 대기 시간이 매우 길지만 할 수 있다
시그널링 중에 교환되는 정보
시그널링 중에 교환해야 하는 세 가지 기본 유형의 정보가 있다
- 통신 채널을 설정하고 열고 닫고 오류를 처리하는 데 사용되는 제어 메시지
- 연결을 설정학 위해 필요한 정보: 피어가 서로 대화할 수 있도록 하는데 IP 주소 지정 및 포트 정보
- 미디어 기능 협상: 피어가 일해할 수 있는 코덱 및 데이터 형식은 WebRTC 세션 시작 전 동의해야 함
시그널링이 성공적으로 완료되면 WebRTC 피어 연결을 여는 진정한 프로세스가 시작될 수 있습니다
신호 서버는 실제로 신호를 보내는 동안 두 피어가 이를 통해 교환하는 데이터를 이해하거나
아무 것도 할 필요가 없다는 점에 주목할 가치가 있다
시그널링 서버는 본질적으로 릴레이로 시그널링 데이터가 이를 통해 전송될 수 있음을 알고
양측이 연결하는 공통 지점이다 서버는 어떤식으로든 정보에 반응할 필요가 없다
신호 프로세스
WebRTC 세션을 시작할 수 있도록 하기 위해 발생하는 일련의 작업
1. 각 피어는 WebRTC 세션의 끝을 나타내는 RTCPeerConnection 객체를 생성한다
2. 각 피어는 icecandidate 이벤트에 대한 핸들러를 설정하여 시그널링 채널을 통해 해당 후보를 다른 피어로 보내는 작업을 처리한다
3. 각 피어는 원격 피어가 스트림에 트랙을 추가할 때 수신되는 트랙 이벤트에 대한 핸들러를 설정합니다. 이 코드는 <video> 요소와 같은 소비자에게 트랙을 연결해야 한다
4. 호출자는 신호 서버의 코드로 그들 사이의 호출을 식별할 수 있도록 고유 식별자 또는 일종의 토큰을 생성하고 수신 피어와 공유한다 이 식별자의 정확한 내용과 형식은 당신에게 달려 있다
5. 각 피어는 메시지 교환 방법을 알고 있는 WebSocket 서버와 같은 합의된 신호 서버에 연결한다
6. 각 피어는 동일한 WebRTC 세션 (4단계에서 설정된 토큰으로 식별됨)에 참여하기를 원한다고 시그널링 서버에 알린다
7. description, candidates 등..
ICE restart
때때로 WebRTC 세션이 진행되는 동안 네트워크 조건이 변경된다
사용자 중 한 명이 셀룰러에서 wifi 네트워크로 전환하거나 네트워크 정체 등이 일어날 수 있다
이 경우 ICE agent 는 ICE 재시작을 수행하도록 선택할 수 있다
네트워크 연결이 재협상되는 프로세스로, 한 가지 예외를 제외하면 초기 ICE 협상 수행과 같은 방식이다
미디어는 새 네트워크 연결이 시자고디어 실행될 때까지 원래 네트워크 연결을 통해
계속 통신된다
그 다음 미디어가 새 네트워크로 이동하면 기존 연결이 제거된다
각 브라우저는 서로 다른 조건에서 ICE 재시작을 지원한다
네트워크 정체 등의 이유로 모든 브라우저가 ICE 재시작을 수행하지는 않는다연결 구성을 변경해야 하는 경우 ICE를 다시 시작하기 전에
업데이트된 구성 개체로 RTCPeerConnection.setConfiguration() 을
호출하여 ICE를 다시 시작하기 전 변경할 수 있다
ICE 재시작을 명시적으로 트리거하려면 RTCPeerConnection.createOffer()를 호출하고 값이 iceRestart 옵션의 값을 true 로 지정하여 재협상 프로세스를
시작한다
그 후 일반적인 연결 과정을 처리한다
ICE 사용자 이름 조각(ufrag) 및 암호에 대한 새 값이 생성되며,
이 값은 재협상 프로세스 및 resulting connection 에 사용된다
ICE ufrag 및 ICE password 에 대한 새 값이 감지되면 연결의 응답자 측에서
자동으로 ICE 재시작을 한다
