SIP 통화가 VPN으로 등록되지만 오디오를 보내지 않는 이유
등록과 오디오는 서로 다른 경로를 갑니다. 통화 하나를 터널을 통해 따라가며 PBX가 사용할 수 있는 주소와 RTP가 실제로 멈추는 지점을 확인하세요.
등록이 성공해도 오디오에 대해 알려주는 것은 거의 없습니다. 소프트폰은 사무실 PBX와 유효한 바인딩을 몇 시간이고 유지하면서도 침묵을 전달할 수 있습니다. 터널은 누군가 의도적으로 보낸 패킷만 운반하며, 통화는 바인딩, 대화 설정, 그리고 RTP 스트림이라는 세 가지 별도 경로를 사용합니다. 이를 분리하면 장애는 VPN이라는 단어가 아니라 한 경로에 떨어집니다.
가정용 Wi-Fi에 연결된 노트북이 승인된 터널을 통해 사무실 내선으로 전화하는 상황을 상상해 보세요. PBX는 사용자를 인증하고 REGISTER를 수락하며 내선은 사용 가능으로 표시되지만, 통화는 한 방향으로 완전한 무음 상태로 연결됩니다.
등록은 연락처를 묶을 뿐, 미디어 경로를 묶지 않는다
REGISTER 요청은 등록 서버에 레코드 주소와 하나 이상의 연락처 URI 사이의 매핑을 저장하도록 요청합니다. 그 매핑은 새 대화를 지금 어디로 보내야 하는가라는 좁은 질문에 답합니다. 미디어가 어디에 속하는지는 말하지 않으며, 수락된 등록은 이후 INVITE가 도달 가능한 미디어 주소를 담는다는 것을 증명하지 않습니다. 등록은 타이머로 만료되므로 갱신을 멈춘 전화기는 터널이 여전히 정상으로 보여도 착신 통화를 잃습니다. 터널 상태가 아니라 연락처 만료를 지켜보세요.
소프트폰이 터널 뒤에 있으면 연락처 헤더에 사설 주소가 담길 수 있습니다. 이를 다른 엔드포인트로 전달하는 PBX는 착신 측이 도달할 수 없는 네트워크를 향하는 대화를 만듭니다. PJSIP 엔드포인트에서 rewrite_contact=yes를 설정하면 PBX가 관찰한 소스 주소로 대체하며, 이것이 종종 벨소리와 타임아웃의 차이입니다.
INVITE가 제시하는 것과 그것을 사용할 수 있는 사람
SDP 본문이 있는 INVITE는 발신자가 미디어를 어디서 받고 싶은지, 즉 주소와 포트, 코덱 목록을 제안합니다. 착신 측은 자기 주소와 포트로 응답하고, 그다음 각 측이 상대가 제안한 곳으로 RTP를 보냅니다. 발신자가 자기 집 네트워크 안에만 존재하는 192.168.x.x 주소를 제안했다면, 신호 방식이 아무리 깨끗해도 착신 측에는 오디오를 보낼 곳이 없습니다. 마스커레이딩은 패킷이 라우터를 떠날 때 IP 헤더를 다시 쓰지만, SDP 본문 안의 텍스트는 절대 다시 쓰지 않습니다.
이 격차가, 신호 방식은 양쪽 엔드포인트가 PBX에 도달하기 때문에 작동하고 오디오는 한쪽 엔드포인트가 다른 NAT 뒤에만 존재하는 주소로 보내라는 지시를 받았기 때문에 실패하는, 고전적인 단방향 통화를 설명합니다.
| Path | Who picks the address | Typical failure |
|---|---|---|
| REGISTER | Softphone, rewritten by the registrar if configured | Binding expires or points at a private address |
| INVITE and SDP | Each endpoint in its own offer or answer | Offer names a media address nobody can route to |
| RTP | PBX relay policy or the two endpoints | Port range blocked, or no return path |
누가 오디오를 운반하는지는 구성 선택이다
신호 방식과 미디어는 별개의 역할입니다. 프록시는 통화 전체 동안 신호 경로에 머물면서 RTP 패킷을 하나도 건드리지 않을 수 있습니다. PBX가 미디어 릴레이가 되는지는 터널의 존재가 아니라 구성에 달려 있습니다.
직접 미디어에서는 엔드포인트가 스스로 RTP를 교환하는데, 이는 하나의 LAN에서는 잘 작동하지만, 한쪽이 좁은 포트 범위 뒤에 있으면 나쁩니다.
direct_media=no를 설정하면 PBX가 미디어 경로로 들어가 두 레그가 PBX가 제어하는 주소에서 종료되어 대역폭과 CPU를 예측 가능한 주소 지정과 맞바꾸는 셈입니다. 릴레이할 때도 PBX는 도달 가능한 주소를 알려야 합니다. 다중 네트워크 호스트에서는 pjsip.conf의 external_media_address와 external_signaling_address가 SDP와 Via 헤더에 무엇이 나타날지 결정합니다. 이를 설정하지 않으면 PBX가 유일한 경로가 터널 반대편인 발신자에게 자기 LAN 주소를 제안할 수 있습니다.
설정을 건드리기 전에 각 방향을 추적하라
통화가 연결된 동안 PBX의 소켓 표에서 시작하되, ss -uanp | grep -E '5060|10000'로 RTP 포트가 바인딩되었는지, 어떤 로컬 주소를 쓰는지 확인하세요. 미디어 범위에 바인딩된 것이 없으면 릴레이가 관여하지 않고 엔드포인트가 직접 통신합니다. 그다음 소프트폰 쪽에서 tcpdump -ni any -s0 udp portrange 10000-20000 -w rtp.pcap로 캡처하세요. 들어오는 패킷 없이 나가는 패킷만 있으면 문제는 반환 경로나 상대방이 쓰라고 지시받은 주소로 좁혀지고, 캡처가 비어 있으면 미디어가 터널 인터페이스에 전혀 도달하지 않은 것입니다. sngrep로 하는 신호 캡처는 전송된 그대로의 SDP 연결 줄을 보여 주어 나머지 절반에 답합니다.
그 연결 줄의 주소를 상대방이 실제로 라우팅할 수 있는 주소와 비교하세요. 이 한 번의 비교가 대부분의 단방향 오디오 보고서를 어떤 구성 검토보다 빠르게 해결합니다.
암호화는 터널 가장자리에서 멈춘다
TLS 위의 SIP는 구성된 신호 홉을 보호하고, SRTP는 양쪽이 협상할 때 미디어를 보호하며, 터널은 자기 엔드포인트 사이의 트래픽을 보호합니다. 어느 것도 다른 것을 보장하지 않습니다. 터널 안에서 암호화된 통화도 게이트웨이를 나와 PBX로 향할 때 평문이 될 수 있으며, 이는 결함이 아니라 설계 결정입니다.
티켓을 닫기 전에 등록이 최신인지, SDP가 상대방이 도달할 수 있는 주소를 담고 있는지, 미디어 포트에서 패킷이 양방향으로 흐르는지를 순서대로 확인하세요. 하나라도 사실이 아니면 문제는 터널에 있지 않습니다. 실패한 경로를 고친 뒤 같은 캡처를 다시 실행해 변경을 확인하세요. 전후 캡처를 남겨 두면 다음 단방향 보고서는 반나절이 아니라 오 분 점검이 됩니다.