나는 TURN 서버를 구현하고 있으며, 궁금한 점은 TURN rfc5766 용어를 사용하려고합니다.서버 냇 탐색 ICE STUN
내가 얻을 수없는 부분이 있습니다. TURN 서버에 연결된 클라이언트 (A)와 아직 연결되지 않은 피어 (B)가 있다고 가정 해 보겠습니다. 우리는 또 다른 메커니즘으로부터 피어 (B)의 재귀 주소를 얻어서 SIP 또는 이메일을 사용하여 클라이언트 (A)에게 전달합니다. 어쩌면 어쨌든.
다음 우리는 클라이언트 (A)에 대한 할당 권한 및 중계 어드레스
그것은 말한다 생성 가정 할 해당 클라이언트 (A)는 서버가이를 중계하는 좌회전 피어 (B)에 대한 데이터 표시를 송신 할 때 피어 (B)의 서버 반사적 주소를 표시에 붙입니다. 그런 다음 서버는 표시와 피어 (B)의 반사 주소에서 udp를 추출하여 피어 (B) 으로 보냅니다. 내가 얻지 못하는 것은 서버가 NAT 뒤에있는 피어 (B)에게 어떻게 도달 할 수 있는가입니다. 피어 (B)의 서버 반사적 주소를 알면 제대로 처리되지 않습니다. 피어 (B)가 서버와 통신하지 않은 경우 피어 (B)의 NAT는 TURN 서버의 피어 (B)에서 클라이언트 (A)의 릴레이 주소로 매핑을 생성하지 않습니다.
서버가 out ip : port 매핑을 사용하여 피어 (B)의 서버 반사 주소에 도달 할 수 있으면 클라이언트 (A)도 클라이언트가 피어 (B)의 서버 반사 주소를 알고 있기 때문에 그렇게 할 수 있습니다. 그리고 턴 서버가 필요 없습니다. 그것은 단지 STUN을 사용합니다.
TURN 서버의 요점은 무엇입니까? 내가 무엇을 놓치고 있습니까?
피어 (B)가 같은 서버에 미리 STUN 바인딩 요청을했을 수도 있고 피어 (B) 서버 반사 주소를 얻은 방법이며 요청이 피어 (B)에서 NAT 매핑을 만들었을 수도 있습니다. 의 편. 이는 Endpoint-Independent Mapping 및 Address-Dependent Mapping을 사용하지만 Address 및 Port-Dependent Mapping은 사용하지 않는 NAT에서만 작동합니다. 클라이언트 (A)의 중계 주소가 STUN 바인딩 요청이 전송되는 Turn 서버의 주소와 다르기 때.입니다. 예 : 서버 주소 : 121.121.121.121:8080 클라이언트 릴레이 주소 : 121.121.121.121:8081 (동일한 서버에서 다른 포트로 이동). 기절 메시지가 121.121.121.121:8080으로 이동하기 때문에 121.121.121.121:8081에 대한 피어 (B)의 NAT 매핑이 없습니다. 기본적으로 브리지가 고장났습니다.
감사합니다.