2026-06-02

RTP \"Unknown Write\" NDPI 오류 해결 — RTSP 스트림의 동적 페이로드 타입 불일치

\"unknown write\" RTP NDPI 오류를 해결합니다. 단계별 가이드: SDP rtpmap 읽기, RTP 페이로드 타입 바이트 교차 검증, 코덱 디패킷라이저 매칭. H.264, H.265, AAC, ONVIF 메타데이터.

RTSP 세션은 미디어 파서가 RTP 패킷을 해석하려고 시도할 때까지는 건강해 보일 수 있습니다. DESCRIBE가 SDP를 반환합니다. SETUP이 성공합니다. PLAY가 성공합니다. RTP 패킷이 도착합니다. 그러면 애플리케이션이나 패킷 분류기가 unknown write, unknown RTP payload, NDPI unknown, unsupported payload type, depacketizer not found, invalid codec mapping, no decoder for payload type 96, 또는 stream contains unknown track을 보고합니다.

이 오류들은 보통 바이트는 존재하지만 분석기가 RTP 페이로드 타입을 SDP의 코덱과 트랙 정의에 매핑할 수 없음을 의미합니다. RTSP에서 페이로드 타입 96이 자동으로 H.264는 아닙니다. 이는 세션 로컬 동적 ID입니다. SDP를 읽어야 합니다.

빠른 답변: NDPI나 카메라를 탓하기 전에 SDP부터 확인

캡처가 unknown write / RTP / NDPI를 보고하면 여기서부터 시작하세요:

RTSP DESCRIBE 응답을 찾습니다.
SDP를 복사합니다.
모든 m= 미디어 라인과 그 페이로드 번호를 찾습니다.
각 동적 페이로드(96-127)에 대해 매칭되는 a=rtpmap:<id> 라인을 찾습니다.
해당 코덱 파라미터에 대한 a=fmtp:<id> 라인을 확인합니다.
RTP 패킷의 페이로드 타입 바이트를 해당 SDP 매핑과 비교합니다.

RTP 패킷이 페이로드 타입 96을 사용하고 SDP가 a=rtpmap:96 H265/90000이라고 명시한다면, H.264를 기대하는 분석기는 엉뚱한 결과를 보고할 것입니다. SDP에 a=rtpmap:96 vnd.onvif.metadata/90000이 있다면, 알 수 없는 페이로드는 비디오가 아니라 ONVIF 메타데이터이며 재생이 실패해서는 안 됩니다.

이것이 NDPI unknown과 같은 일반적인 DPI 라벨만으로는 충분하지 않은 이유입니다. DPI 엔진은 패킷 바이트를 봅니다. RTSP 제어 평면의 컨텍스트를 항상 갖고 있는 것은 아니며, 이는 세션 로컬 동적 페이로드 ID를 해석하는 데 필요합니다. RTSP의 경우, 제어 평면과 미디어 평면을 함께 읽어야 합니다.

이는 프로토콜 해석 문제입니다. RTSP Inspector가 유용한 이유는 SDP와 RTP 증거를 함께 유지하기 때문입니다. 동적 RTP 페이로드 ID를 정의하는 SDP 없이는 이를 올바르게 해석할 수 없습니다.

정적 vs 동적 페이로드 타입

일부 RTP 페이로드 타입은 정적입니다. 일부는 동적입니다. 동적 페이로드 타입은 보통 96-127 범위에 있으며 SDP에 의해 매핑되어야 합니다.

예시:

m=video 0 RTP/AVP 96
a=rtpmap:96 H264/90000

여기서 페이로드 타입 96은 이 세션에서 H.264를 의미합니다. 다른 스트림에서는 페이로드 타입 96이 H.265, AAC, 메타데이터, 또는 벤더 특정 무언가를 의미할 수도 있습니다. 숫자만으로는 충분하지 않습니다.

클라이언트가 페이로드 타입 96을 항상 H.264라고 가정하면 결국 실패합니다.

동적 페이로드에는 SDP rtpmap이 필수

동적 페이로드 타입의 경우 SDP에는 a=rtpmap이 포함되어야 합니다:

a=rtpmap:96 H264/90000
a=rtpmap:97 MPEG4-GENERIC/48000/2
a=rtpmap:98 H265/90000

SDP에 rtpmap이 없으면 클라이언트는 어떤 디패킷라이저를 사용해야 할지 모를 수 있습니다. 일부 카메라는 불완전한 SDP를 생성합니다. 일부 릴레이나 프록시는 SDP를 변경합니다. 일부 클라이언트는 공통 트랙만 파싱하고 메타데이터 트랙은 무시합니다.

흔한 결과:

비디오 페이로드가 도착하지만 디코딩되지 않습니다.
오디오 트랙이 무시됩니다.
ONVIF 메타데이터 트랙이 알 수 없는 페이로드 오류를 트리거합니다.
H.265가 H.264로 잘못 인식됩니다.
AAC 클럭 레이트나 채널 수가 잘못됩니다.

세션 간 페이로드 타입 변경

동적 페이로드 ID를 하드코딩하지 마세요. 카메라는 재부팅, 프로필 변경, 펌웨어 업데이트, 스트림 경로 변경 후에 다른 페이로드 번호를 할당할 수 있습니다.

예를 들어:

세션 A: 페이로드 96 = H264
세션 B: 페이로드 96 = H265
세션 C: 페이로드 97 = H264, 페이로드 96 = 메타데이터

올바른 동작은 세션별로 SDP를 파싱하고 RTP 패킷 페이로드 ID를 해당 세션의 매핑에 바인딩하는 것입니다.

H.264와 H.265 혼동

H.264와 H.265는 모두 종종 90 kHz RTP 클럭을 사용하지만, 패킷화 방식과 코덱 구성이 다릅니다. H.265 패킷에 H.264 디패킷라이저를 사용하는 클라이언트는 유효한 비디오를 생성하지 못합니다.

증상:

RTP 패킷이 도착합니다.
페이로드 타입이 동적입니다.
SDP는 H265라고 명시하지만 클라이언트는 H264를 기대합니다.
디코더가 잘못된 NAL 유닛을 보고합니다.
비디오가 검은색이거나 시작되지 않습니다.

카메라가 "잘못된 비디오를 전송한다"고 결론 내리기 전에 항상 SDP를 확인하세요.

AAC와 MPEG4-GENERIC

오디오 트랙도 똑같이 까다로울 수 있습니다. RTP 위의 AAC는 종종 mode, config, sizeLength, indexLength, profile-level-id와 같은 파라미터와 함께 MPEG4-GENERIC을 사용합니다.

클라이언트가 fmtp를 무시하면 패킷이 도착하더라도 오디오가 실패할 수 있습니다.

메타데이터 트랙과 벤더 확장

ONVIF 메타데이터, 분석 오버레이, 비공개 이벤트 트랙, 그리고 벤더 특정 페이로드가 SDP에 나타날 수 있습니다. 미디어 플레이어는 이들을 어떻게 처리해야 할지 모를 수 있습니다.

이는 반드시 스트림 실패를 의미하지는 않습니다. 클라이언트가 비디오와 오디오를 계속 처리하면서 지원되지 않는 비미디어 트랙을 무시해야 함을 의미할 수도 있습니다. 하지만 클라이언트가 알 수 없는 메타데이터를 치명적 오류로 처리하면 재생이 실패할 수 있습니다.

RTSP Inspector는 트랙 타입, 페이로드 매핑, 그리고 알 수 없는 페이로드가 비디오, 오디오, 메타데이터, 또는 비공개 데이터인지를 식별하는 데 도움이 됩니다.

디버그 체크리스트

다음 과정을 사용하세요:

DESCRIBE가 반환한 SDP를 캡처합니다.
모든 m= 미디어 섹션을 나열합니다.
모든 동적 페이로드 타입을 나열합니다.
페이로드 ID를 a=rtpmap과 매핑합니다.
코덱 구성을 위해 a=fmtp를 검사합니다.
RTP 패킷 페이로드 타입 값을 SDP와 비교합니다.
세션 간에 페이로드 ID가 변경되는지 확인합니다.
비디오, 오디오, 메타데이터, 비공개 트랙을 분리합니다.
각 필수 코덱에 대한 디패킷라이저가 클라이언트에 있는지 확인합니다.
애플리케이션이 안전하게 그렇게 할 수 있는 경우에만 지원되지 않는 선택적 트랙을 무시합니다.

최종 진단

RTP 동적 페이로드 타입 불일치는 클라이언트가 수신된 RTP 패킷을 올바른 코덱이나 트랙에 매핑할 수 없을 때 발생합니다. 해결책은 SDP를 세션의 권위 있는 정보로 취급하는 것입니다: rtpmap을 파싱하고, fmtp를 파싱하고, 페이로드 ID를 세션별로 바인딩하고, 필수 미디어 트랙과 선택적 메타데이터를 구분합니다.

RTSP Inspector는 SDP와 RTP를 나란히 표시하여 카메라, 디코더, 또는 네트워크를 탓하기 전에 페이로드 문제를 진단할 수 있게 해주는 이 증거 우선 워크플로를 지원합니다.