회사·학교 네트워크에서 화상통화가 막힐 때
작성 · 수정
사무실, 캠퍼스, 호텔 네트워크에서 웹사이트가 열리고 텍스트 채팅도 되는데 화상통화만 연결되지 않거나 몇 초 뒤에 끊기는 경우가 많습니다. 이는 우연이 아니라, 브라우저가 실시간 통화를 연결하는 방식과 네트워크 관리 주체가 적용하는 규칙 때문에 생기는 결과입니다. 이 글은 그 패턴을 쉬운 말로 설명하고, 확인하는 방법과 관리자에게 무리 없이 요청할 수 있는 변경을 정리합니다.
통화가 웹 페이지와 다른 이유
웹 페이지를 열거나 채팅 메시지를 보내는 일은 웹의 다른 모든 일과 같은 종류의 연결을 씁니다. 브라우저가 서버에 암호화된 연결을 열고 글을 주고받는 방식입니다. 이것이 막히면 아무도 일을 못 하니, 거의 모든 네트워크가 허용합니다. 화상통화는 다릅니다. 지연을 줄이려고 브라우저는 영상과 소리를 UDP라는 빠르고 느슨한 프로토콜로 보내고, 중간 서버를 거치지 않고 상대 브라우저로 곧바로 보내려 합니다. 이것을 설정하는 기술이 WebRTC입니다.
통화가 시작되기 전에 두 브라우저는 서로 사이의 경로를 찾습니다. 가능한 경로 하나하나가 ICE 후보입니다. 브라우저는 직접 경로를 먼저 선호하고, 그다음 STUN 서버에서 알아낸 공인 주소를 쓰는 경로, 마지막 수단으로 TURN이라는 릴레이 서버를 씁니다. MDN 문서는 UDP가 더 빠르고 중단에서 더 쉽게 회복하므로 선호되며, TCP 후보는 대체로 UDP를 쓸 수 없거나 미디어 스트리밍에 부적합한 방식으로 제한될 때만 쓰인다고 설명합니다. 네트워크가 UDP를 막고 TCP 경로도 주지 않으면 브라우저가 쓸 수 있는 경로를 하나도 못 찾을 수 있습니다.
네트워크 관리 주체가 막는 것과 그 이유
- 나가는 UDP 트래픽. 일부 방화벽은 웹 포트와 DNS만 허용합니다. 사무실에는 안전한 기본값이지만 직접 통화를 깨뜨립니다. 그러면 통화는 릴레이가 있을 때 릴레이로 넘어갑니다.
- 낯선 서버로의 연결. 필터가 목록에 있는 사이트만 허용하고 나머지는 거절할 수 있습니다. 통화 서비스가 쓰는 STUN과 릴레이 서버도 거기에 포함됩니다.
- 웹 프록시. 프록시는 웹 트래픽을 처리하지만 대개 UDP를 실을 수 없어, 프록시를 거쳐야 하는 통화는 품질이 떨어지거나 실패합니다. 브라우저가 WebRTC에서 IP 주소를 다루는 방식을 정의한 RFC 8828도 프록시에는 대개 UDP 지원이 없어서 미디어가 낮은 품질의 TCP로 넘어간다고 적고 있습니다.
- 암호화된 트래픽 검사. 일부 조직은 웹 트래픽을 복호화했다가 다시 암호화해 검사하며, 이를 예상하지 못한 서비스는 깨질 수 있습니다.
- 기기 정책. 회사·학교에서 관리하는 컴퓨터와 기기에서는 관리자가 브라우저의 카메라, 마이크, WebRTC를 통째로 꺼 둘 수 있고, 개인 설정으로 바꿀 수 없습니다.
- 호텔, 카페, 기차의 시간제 또는 캡티브 포털 와이파이. 먼저 약관에 동의해야 하고 대량 트래픽이 제한될 수 있습니다.
네트워크를 관리하는 쪽에는 보통 보안, 대역폭, 학생의 사생활, 시험 공정성 같은 정당한 이유가 있습니다. 이 글의 목적은 규칙을 우회하는 것이 아니라 문제를 정확히 설명하도록 돕는 것입니다.
이 패턴을 알아보는 방법
- 메시지는 되는데 통화는 안 됩니다. ChatLite와 많은 서비스에서 텍스트 메시지는 서버를 거칠 수 있지만 통화는 두 브라우저 사이의 경로가 필요하므로, 실시간 미디어를 막는 네트워크는 바로 이런 차이를 보입니다.
- 통화는 연결되지만 잠시 뒤 화면이 멈추거나 소리가 끊깁니다. 제한된 경로로 간신히 지나가고 있다는 뜻인 경우가 많습니다.
- 같은 통화가 휴대폰 핫스팟이나 집에서는 바로 됩니다. 처음 네트워크가 원인이고 기기는 정상이라는 가장 분명한 신호입니다.
- 한쪽에서는 상대 소리가 들리는데 반대쪽에서는 들리지 않습니다. 네트워크마다 막는 방향이 다를 수 있습니다.
- 이 사이트의 카메라 테스트는 통과하는데 통화는 안 됩니다. 카메라는 정상이고 다음 의심 대상은 네트워크입니다.
2분 안에 확인하기
- 이 사이트의 무료 카메라·마이크 테스트를 실행하세요. 통과하면 장치와 브라우저 권한은 정상이고 문제는 연결에 있습니다.
- 문제의 네트워크에서 WebRTC 연결 테스트를 실행하세요. 통화를 시작할 때 하는 것과 같은 탐색을 실행해 공인 주소를 알아낼 수 있었는지 알려 줍니다. 로컬 주소만 나오고 STUN 서버가 응답하지 않으면 인터넷으로의 UDP가 막혀 있을 가능성이 큽니다.
- 휴대폰 핫스팟에서 다시 실행하세요. 거기서는 결과가 좋고 처음 네트워크에서는 나쁘면 진단이 확인됩니다.
- VPN이나 프록시가 있다면 끄고 반복하세요. VPN은 자체 제한을 더할 수 있습니다.
어떤 테스트, 어떤 네트워크, 어떤 판정이었는지 적어 두세요. 짧고 사실 위주의 보고가 네트워크를 운영하는 사람에게 보낼 수 있는 가장 유용한 자료입니다.
직접 해 볼 수 있는 것
- 유선 연결이나 더 가까운 접속 장치를 쓰세요. 혼잡한 와이파이는 차단과 같은 증상을 만듭니다.
- 통화 중에 대용량 다운로드나 클라우드 백업 같은 대역폭을 많이 쓰는 프로그램을 닫으세요.
- 음성 통화로 바꾸거나 카메라를 끄세요. 오디오는 대역폭을 훨씬 적게 쓰고 좁은 경로에서도 살아남습니다.
- 조직의 정책이 허용한다면 중요한 통화에는 휴대폰 핫스팟을 쓰세요. 먼저 정책을 확인하세요. 회사 기기를 개인 핫스팟 같은 다른 네트워크에 연결하는 것을 금지하는 조직도 있습니다.
- 회사에서 관리하는 노트북 대신 모바일 데이터를 쓰는 휴대폰으로 참여하세요.
- 다른 통화 서비스를 써 보세요. 자체 릴레이 서버를 운영하는 서비스는 그렇지 않은 서비스가 연결하지 못하는 곳에서도 연결될 수 있습니다. ChatLite는 직접 연결에 의존하며 릴레이 서버를 항상 쓸 수 있다고 보장하지 않습니다.
네트워크 관리자에게 요청할 것
관리자는 불평보다 구체적인 요청에 잘 응답합니다. 테스트 결과를 보내고 도움이 될 가장 좁은 변경을 요청하세요. 서비스에 따라 다음 중 일부가 해당될 수 있습니다.
- 실시간 미디어를 위한 통화 서비스로의 나가는 UDP를 허용하거나, 서비스의 STUN·TURN 서버를 이름으로 허용해 달라고 하세요. RFC 8489에 따르면 STUN의 기본 포트는 3478이고 TLS 위의 STUN은 5349입니다.
- 서비스의 릴레이 서버를 TCP로 허용해 달라고 하세요. 서비스가 제공한다면 443 포트의 TLS도 포함됩니다. RFC 8656은 클라이언트가 UDP, TCP, TLS, DTLS로 TURN 서버에 접속할 수 있다고 규정하며, 이 때문에 웹 트래픽만 허용하는 네트워크에서도 릴레이가 동작할 수 있습니다.
- 웹 필터의 허용 목록에 서비스의 도메인을 추가해 달라고 하세요.
- 회사·학교에서 관리하는 브라우저 정책이 통화 사이트의 카메라, 마이크, WebRTC를 끄고 있지 않은지 확인해 달라고 하세요.
- 정책이 허락한다면 실시간 트래픽을 복호화와 검사에서 제외해 달라고 하세요.
ChatLite의 경우 브라우저는 stun.l.google.com, stun1.l.google.com, stun2.l.google.com의 19302 포트 공개 STUN 서버를 시도하며, 이 사이트의 연결 테스트도 같습니다. 통화에는 브라우저 사이의 직접 경로가 필요하므로, 네트워크가 그 경로를 막으면 ChatLite 메시지는 도착해도 통화는 연결되지 않을 수 있습니다.
규칙 안에서 해결하세요
학교나 직장 네트워크를 피하려고 트래픽을 숨기는 도구를 쓰지 마세요. 정책이 허용하는 경우가 아니라면 규칙 위반이 되거나 조직의 데이터가 노출되거나 계정이 잠길 수 있습니다. 예외를 요청하거나, 허용되는 기기와 네트워크에서 통화하세요.
ChatLite에 대해
ChatLite도 같은 패턴을 보입니다. 메시지는 서버를 통해 도착할 수 있지만 통화에는 직접 경로가 필요합니다. 이 사이트의 WebRTC 연결 테스트로 내 네트워크가 어느 쪽인지 빠르게 확인할 수 있습니다.
참고 자료
이 글을 확인하는 데 쓴 공식 문서입니다. 문서는 각 운영 주체가 관리하며 바뀔 수 있습니다. 한국어 메뉴 이름은 버전과 언어 설정에 따라 다를 수 있으니, 화면의 이름과 다르면 비슷한 항목을 찾거나 공식 문서의 영어 이름을 참고하세요.
ChatLite의 현재 동작을 기준으로 검토한 날짜: .