RTSP의 ONVIF XML 메타데이터를 WebRTC 송출 시 함께 전달할 수 있을까?

📌 오늘의 안건
RTSP의 ONVIF XML 메타데이터를 WebRTC 송출 시 함께 전달할 수 있을까?

RTSP 스트림에 실려 오는 ONVIF 계열 XML 메타데이터 트랙을, 영상과 함께 WebRTC로 브라우저까지 내려보내는 것이 표준상·브라우저 구현상 가능한지 판단하고 싶습니다.

상황은 이렇습니다.

• 입력: 카메라가 RTSP로 내보내는 영상 + 별도 메타데이터 트랙(ONVIF 등에서 정의하는 XML 형태)
• 게이트웨이: Jetson Orin AGX 보드를 미디어 게이트웨이로 두고 RTSP→WebRTC 변환
• 출력: 브라우저에서 영상 재생 + 메타데이터 활용

궁금한 지점은 다음과 같습니다.

1. WebRTC 표준(및 현재 브라우저 구현) 안에 RTSP의 비미디어 메타데이터 트랙을 그대로 실어 나를 자리가 있는가? 즉 별도 변환 없이 "트랙 그대로" 전달이 가능한 시나리오인가, 아니면 원리적으로 불가능해서 다른 경로가 필수인가?
2. 불가능하다면 실무에서 통용되는 대안은 무엇인가? (데이터 채널로 분리 전송, 영상 프레임과의 타임스탬프 동기화 방식, 메타데이터를 영상에 임베드하는 방식 등)
3. 대안을 쓸 때 영상과 메타데이터의 시간 정렬(동기화)은 어느 정도 정확도까지 현실적으로 기대할 수 있는가?
4. 브라우저별 호환성에서 걸리는 지점이 있는가?

최종적으로 원하는 결론은 구현 튜닝 팁이 아니라 "표준·브라우저 관점에서 되는가/안 되는가, 안 된다면 어떤 경로가 사실상 표준인가"에 대한 정리입니다.

포스텔입니다. 저는 소문이 아니라 문서를 읽습니다 — 이번 건도 어떤 규격의 몇 절에 무엇이 적혀 있는지부터 확인해 오겠습니다.

나이퀴스트입니다. 저는 늘 '얼마나 촘촘히 표본을 찍어야 원래 것이 되살아나는가'를 묻습니다 — 이번에도 시간 정렬의 한계와 그 비용을 숫자로 재보겠습니다.

닥터 다운타임입니다. 저는 새벽 세 시에 울리는 알람의 관점에서 구조를 봅니다 — 이 파이프라인이 어디서 먼저 무너질지 짚어드리겠습니다.

반증의 칼입니다. 저는 답보다 먼저 그 답이 틀릴 수 있는 이유를 찾습니다 — 오늘 나올 결론들의 전제부터 하나씩 걸어보겠습니다.

결론: RTSP의 ONVIF XML 메타데이터 트랙을 WebRTC 브라우저 수신단에 “트랙 그대로” 전달하는 표준적 경로는 없다. WebRTC의 브라우저 MediaStreamTrack은 사실상 audio/video만 노출하며, 임의 RTP 메타데이터 트랙을 DOM 트랙으로 받는 API가 없다. 근거: W3C WebRTC는 MediaStreamTrack을 미디어 흐름 중심으로 정의하고, MDN도 kind 값을 audio 또는 video로만 설명한다. WebRTC RTP는 협상된 RTP payload format을 쓸 수 있지만, 브라우저 구현이 ONVIF XML RTP payload를 디코딩·노출하지 않는다. ONVIF 쪽은 별도 metadatastream.xsd/Streaming 규격을 갖지만, 이것이 브라우저 WebRTC 트랙으로 매핑되지는 않는다.

출처: w3.org[1] , developer.mozilla.org[2] , onvif.org[3]

실무 표준에 가까운 해법은 영상은 WebRTC 미디어 트랙, ONVIF XML은 파싱하거나 원문 보존 후 RTCDataChannel로 별도 전송하는 방식이다. 데이터 채널은 임의 문자열/바이너리 전송용으로 표준화되어 있고 브라우저 호환성이 가장 낫다. XML 메시지에는 반드시 camera_time, 원 RTSP/RTP timestamp, 게이트웨이 수신 시각, 가능하면 매칭되는 WebRTC RTP timestamp 또는 프레임 PTS를 붙여야 한다. 영상 안에 태우는 방식은 두 갈래다: 화면 오버레이는 표시 동기는 강하지만 데이터 활용성이 떨어지고, H.264 SEI 같은 코덱 부가정보 삽입은 브라우저 JS에서 안정적으로 꺼내 쓰는 표준 경로가 아니므로 범용 해법이 아니다.
출처: rfc-editor.org[1] , developer.mozilla.org[2]

정렬 정확도는 “원리적으로 같은 트랙 수준”이 아니라 애플리케이션 동기화 수준이다. Jetson 게이트웨이 내부에서 RTSP 영상 RTP timestamp와 메타데이터 timestamp를 같은 클럭 기준으로 잡으면 매칭 자체는 보통 ms 이하~수 ms로 가능하다. 브라우저 표시 시점까지 포함하면 requestVideoFrameCallback()의 mediaTime/expectedDisplayTime 또는 WebCodecs VideoFrame.metadata().rtpTimestamp를 쓰더라도 현실적 체감 정렬은 30fps 기준 1프레임 안팎, 즉 약 33ms, 60fps면 약 16.7ms가 1차 목표다. 부하·네트워크 지터·데이터채널 reliable/ordered 설정까지 들어가면 1~2프레임 오차를 예산으로 잡는 게 안전하다.

Chrome 계열이 저수준 프레임 메타데이터 접근은 가장 유리하고, Safari/Firefox까지 범용으로 가려면 데이터채널 + requestVideoFrameCallback() 기반 정렬을 표준 경로로 보는 것이 맞다. 출처: developer.mozilla.org[1] , developer.mozilla.org[2] , developer.mozilla.org[3]

WebRTC·RTSP·ONVIF 메타데이터 전달 가능 여부를 표준·브라우저 기준으로 확인합니다.결론: RTSP의 ONVIF XML 메타데이터 트랙을 WebRTC 미디어 트랙으로 “그대로” 전달하는 것은 표준·브라우저 모두에서 불가능하다. 사실상 표준 경로는 게이트웨이에서 메타를 분리한 뒤 RTCDataChannel로 실어 보내는 것이며, ONVIF 자체도 WebRTC 명세에서 그 경로를 공식화했다.

1. 트랙 그대로 전달은 원리적으로 막힌다. 브라우저 WebRTC의 미디어 경로는 audio/video MediaStreamTrack + 협상된 코덱(RFC 7742 등)만 다룬다. ONVIF 메타는 RTSP 세션 안의 별도 RTP 트랙(application/vnd.onvif.metadata / VND.ONVIF.METADATA)으로 영상과 병행 전송되지만, 브라우저가 이 페이로드 타입을 디멀티플렉스·노출하는 API가 없다. 미협상·미지원 PT는 드롭되며, “비미디어 메타 트랙을 미디어 트랙처럼 붙인다”는 시나리오는 성립하지 않는다. 일반 데이터는 Peer Connection의 Data API(RTCDataChannel) 로만 간다.

2. 실무·표준 대안은 DataChannel 분리 전송이다. 게이트웨이(Jetson 등)가 RTSP에서 영상·메타를 분리 → 영상은 WebRTC media, XML(또는 JSON 변환본)은 DataChannel로 전송. ONVIF WebRTC Specification이 Metadata data channel subprotocol로 XML 메타를 DataChannel 위에 스트리밍하도록 정의한다. 그 외 임베드(SEI/자막류)는 브라우저 디코더·JS 접근이 불안정해 관제용 1차 경로로는 부적합하다. 동기화는 게이트웨이가 RTP/RTCP 시각을 기준으로 공통 타임스탬프(또는 프레임 인덱스)를 메타에 붙여 보내고, 수신측에서 requestVideoFrameCallback / WebCodecs VideoFrame.timestamp와 매칭하는 방식이 현실 표준 패턴이다. 프레임 단위 잠금은 JS API에 없고, 합리적 기대치는 수십~100ms대 정렬·이벤트 오버레이 수준이며 픽셀-정확 프레임 바인딩은 보장되지 않는다.

혼잡·재연결 시 DataChannel 버퍼 적체·순서·유실이 먼저 터지므로, 관제 판단용이면 타임스탬프 재정렬·최신 상태 스냅샷·드롭 정책을 전제로 설계해야 한다.

3. 브라우저 호환 병목은 메타 코덱이 아니라 DataChannel·동기화 API 쪽이다. Chrome/Edge/Firefox/Safari 모두 DataChannel은 성숙하다. 걸리는 지점은 (a) 대용량 XML 연속 전송 시 버퍼링·메시지 크기 관행 차이, (b) 프레임 콜백·WebCodecs 지원 깊이 차이, (c) 재연결 후 메타 상태 복원 부재다. 요약: “트랙 그대로” = 안 됨. “DataChannel + 타임스탬프 동기화” = 되는 쪽이자 ONVIF·현장 공통 경로.

1. 비미디어 메타데이터 트랙 직접 전송: 원리적 불가능
RTSP의 XML 메타데이터 트랙을 그대로 WebRTC 미디어 트랙(MediaStreamTrack)에 실어 브라우저로 내려보내는 것은 원리적으로 불가능합니다. W3C WebRTC 1.0 명세[1]상 미디어 트랙은 오디오와 비디오로 엄격히 제한되어 있으며, 임의의 XML/RTP 페이로드를 처리할 수 있는 브라우저 파이프라인이나 JavaScript API는 존재하지 않습니다. 표준 미디어 엔진은 규격 외 비미디어 RTP 트랙을 수신하는 즉시 버리므로, 별도 변환이 없는 직송 시나리오는 불가능합니다.

2. 통용 대안의 실체와 브라우저 구현의 맹점
실무에서 대안으로 제시되는 방식들은 모두 크로스 브라우저 호환성 및 동기화 관점에서 명백한 한계를 가집니다. WebRTC DataChannel 분리 송신: SCTP 기반의 DataChannel은 SRTP 미디어 스트림과 전혀 다른 전송 경로를 타기 때문에 네트워크 지터와 버퍼링 차이로 인해 실시간 시간 동기화가 원천적으로 깨집니다. Insertable Streams를 통한 미디어 프레임 임베딩: H.264/H.265 SEI에 데이터를 심거나 WebRTC Encoded Transform[1]을 사용해 바이너리 메타데이터를 프레임에 주입하는 방식이 제안되지만, 이는 Chromium 독점적 기능입니다.

Firefox나 Safari 등 비크로미움 브라우저와의 상호운용성(Interoperability)을 충족하지 못해 서비스 상용화 단계에서 깨질 수밖에 없는 미완의 구현입니다.

3. 시간 동기화의 기술적 한계 및 결론
영상과 메타데이터의 ms 단위 정밀 동기화는 브라우저 환경에서 불가능합니다. 브라우저 렌더링 파이프라인은 블랙박스이며, JavaScript가 실제 화면에 디스플레이되는 비디오 프레임의 정확한 RTP 타임스탬프를 실시간으로 가져오는 크로스 브라우저 표준 API는 존재하지 않습니다. WebCodecs API[1]의 VideoFrame.metadata()를 통해 타임스탬프를 확보하는 우회책 또한 상호운용성이 결여되어 있습니다. 결론적으로, 표준 및 브라우저 관점에서 정밀 동기화 트랙 전송은 불가능하며, 동기화가 반드시 보장되어야 한다면 Jetson 게이트웨이 단에서 메타데이터를 영상에 직접 렌더링(OSD Burn-in)하여 단일 비디오 스트림으로 송출하는 것이 검증된 유일한 해결책입니다.

1) 결론: 표준상 불가능하다 — "트랙 그대로"는 자리가 없다

ONVIF 메타데이터는 RTSP SDP에서 m=application <port> RTP/AVP <pt> + a=rtpmap:<pt> vnd.onvif.metadata/90000 (또는 vnd.onvif.metadata+gzip, vnd.onvif.metadata.exi.ext) 형태의 RTP 스트림으로 규정되어 있다(ONVIF Streaming Spec, 메타데이터 스트림 절). 반면 WebRTC 쪽 조문은 이렇다:

• W3C webrtc-pc / mediacapture-streams: MediaStreamTrack.kind는 "audio" 또는 "video"뿐이고, addTransceiver(kind)는 그 외 값에 TypeError를 던진다. 즉 브라우저 API에 "메타데이터 트랙" 객체가 존재하지 않는다.
• RFC 8829(JSEP): 오퍼/앤서에 생성되는 m-line은 RTP용 audio/video, 그리고 데이터채널용 application뿐이다. 그런데 그 m=application은 RFC 8841에 따라 proto가 UDP/DTLS/SCTP, fmt가 webrtc-datachannel로 고정된다. ONVIF의 m=application ... RTP/AVP는 미디어 타입 문자열만 같고 프로토콜이 다르므로 브라우저는 이 m-line을 port 0으로 거절(rejected) 한다.

따라서 게이트웨이가 ONVIF 메타 RTP를 그대로 릴레이할 경로는 원리적으로 없다. 반드시 게이트웨이에서 역다중화 후 재포장이 필요하다.

2) 사실상의 표준 경로: DataChannel 분리 전송 + RTP 타임스탬프 키잉

실무 표준은 두 가지이며, 1번이 지배적이다.

• (A) RTCDataChannel (RFC 8831 / 8841) — Jetson의 게이트웨이(GStreamer webrtcbin, Pion, mediasoup 등)에서 vnd.onvif.metadata RTP를 디페이로드해 XML/JSON으로 데이터채널에 실어보낸다. 핵심은 페이로드에 원본 RTP 타임스탬프(또는 RTCP SR로 환산한 NTP 캡처시각)를 명시적으로 넣는 것이다. RFC 3550 §6.4.1의 SR은 RTP↔NTP 매핑을 제공하지만, 그 립싱크 메커니즘은 RTP SSRC들 사이에서만 정의된다 — 데이터채널은 RTCP 동기화 대상이 아니므로, 도착 시각으로 맞추면 동기가 깨진다. 브라우저 측에서는 HTMLVideoElement.requestVideoFrameCallback()의 metadata.rtpTimestamp(WebRTC 전용 필드)로 표시 중인 프레임의 RTP 타임스탬프를 얻어 데이터채널 큐와 조인한다.

전송 옵션은 ordered:false, maxRetransmits:0로 SCTP head-of-line 블로킹을 피하는 것이 관례다. - (B) 비디오 비트스트림 임베드 (H.264 SEI user_data_unregistered, payloadType 5) — 프레임과 물리적으로 묶이므로 동기가 완벽하지만, 브라우저 내장 디코더는 SEI를 JS로 노출하지 않는다. 꺼내려면 WebRTC Encoded Transform(RTCRtpScriptTransform) 으로 디코드 전에 가로채 파싱해야 한다. RTP 헤더 확장(abs-capture-time 등)도 마찬가지로 JS에 노출되지 않아 범용 경로가 아니다.

3) 동기 정확도와 4) 브라우저 호환성

정확도는 무엇을 키로 쓰느냐로 갈린다. rtpTimestamp 기준으로 조인하면 프레임 단위 정합(±1프레임, 30fps에서 약 33ms) 이 현실적 상한이고, SEI 임베드(B)는 원리적으로 0프레임 오차다. 반대로 데이터채널 도착 시각/벽시계로 맞추면 지터버퍼 변동과 SCTP 재전송이 겹쳐 100~300ms 수준으로 흔들리며, 이는 튜닝으로 없앨 수 없는 구조적 오차다(경로가 다르므로). 실무 권장은 메타데이터를 소량 버퍼에 넣고 requestVideoFrameCallback이 알려주는 프레임 타임스탬프에 맞춰 렌더 시점에 지연 조인하는 방식이다.

호환성에서 걸리는 지점:

• requestVideoFrameCallback 자체는 Baseline 2024(Chrome/Safari/Firefox 132+)이나, rtpTimestamp·captureTime·receiveTime은 WebRTC 전용 부가 필드여서 구현 편차가 남는다. Chrome이 가장 안정적이며, 미구현 브라우저를 위해 mediaTime/presentedFrames 기반 폴백을 반드시 둬야 한다.
• Encoded Transform은 Firefox 117+/Safari가 표준형 worker-first RTCRtpScriptTransform을, Chrome은 오랫동안 비표준 Insertable Streams(createEncodedStreams)를 별도 구현해 온 이력이 있다(2025년 10월 이후 표준형으로 수렴). 즉 (B) 경로는 어댑터 없이는 크로스브라우저가 아니다.
• 데이터채널(SCTP over DTLS)은 전 브라우저 공통 지원이라 (A)가 유일하게 안전한 상호운용 기반이다.

최종 판단: 트랙 그대로는 안 된다. 게이트웨이에서 ONVIF 메타 RTP를 디페이로드해 RTP 타임스탬프를 페이로드에 실어 DataChannel로 보내고, 브라우저에서 requestVideoFrameCallback으로 프레임 정합하는 것이 사실상의 표준 경로다.

Sources:

• ONVIF Streaming Specification (v26.06)[1]
• RFC 8829 — JSEP[2]
• RFC 8841 — SDP Offer/Answer for SCTP over DTLS[3]
• RFC 8831 — WebRTC Data Channels[4]
• RFC 3550 §6.4.1 — RTCP Sender Report (NTP↔RTP)[5]
• W3C WebRTC 1.0 — RTCRtpTransceiver / addTransceiver[6]
• MDN — HTMLVideoElement.requestVideoFrameCallback()[7]
• WICG — video-rvfc spec[8]
• MDN — Using WebRTC Encoded Transforms[9]
• Mozilla — Intent to ship RTCRtpScriptTransform[10]

결론은 내 초안보다 포스텔/닥터 다운타임 쪽을 일부 흡수해 더 강하게 정리하는 게 맞다.

판정

RTSP의 ONVIF XML 메타데이터 RTP 트랙을 WebRTC 브라우저 수신단에 트랙 그대로 전달하는 것은 안 된다.
안 되는 이유는 단순히 “브라우저가 아직 구현 안 함”이 아니라, 브라우저 WebRTC API 모델에 임의의 application/RTP 메타데이터 트랙을 MediaStreamTrack으로 노출하는 자리가 없기 때문이다. 브라우저가 받는 미디어 트랙은 사실상 audio/video이고, WebRTC의 m=application은 ONVIF RTP 메타 트랙용이 아니라 DataChannel용 SCTP 경로다.

따라서 게이트웨이는 반드시 재포장해야 한다.

다른 초안 비평

포스텔 초안의 장점은 가장 정확하다.
ONVIF 메타가 RTSP SDP에서 m=application ... RTP/AVP + vnd.onvif.metadata/90000 같은 RTP 트랙으로 온다는 점, WebRTC의 m=application은 UDP/DTLS/SCTP webrtc-datachannel이라는 점을 구분한 것이 핵심이다. “application이라는 이름이 같아도 같은 통로가 아니다”가 표준 관점의 결정타다.

닥터 다운타임 초안도 방향은 맞다.
특히 “ONVIF WebRTC 쪽에서도 Metadata data channel subprotocol을 둔다”는 논지는 내 초안보다 보완 가치가 크다. 다만 “수십~100ms대”라고 넓게 잡은 것은 지나치게 보수적이다. 설계가 나쁘거나 부하가 크면 그럴 수 있지만, 정상적인 게이트웨이-브라우저 구조에서 목표값을 그렇게만 말하면 비용 대비 정밀도 판단이 흐려진다.

반증의 칼 초안은 결론 일부는 맞지만 과하게 비관적이다.
“트랙 그대로 불가능”은 맞다. 그러나 “DataChannel이면 실시간 동기화가 원천적으로 깨진다”, “OSD burn-in만이 유일한 해결책”은 틀렸다. DataChannel은 미디어 RTP와 자동 립싱크되지는 않지만, 메타 메시지에 원본 RTP timestamp / NTP 환산 시각 / 프레임 PTS를 실으면 애플리케이션 레벨 동기화는 충분히 가능하다. OSD burn-in은 화면 표시만 필요할 때 강한 방법이지, 메타데이터를 브라우저 JS에서 활용하려는 목적의 유일한 해법은 아니다.

보완된 답변

사실상의 표준 경로는 다음이다.

1. Jetson 게이트웨이가 RTSP를 수신한다.
2. 영상 RTP는 WebRTC video track으로 변환한다.
3. ONVIF XML RTP 트랙은 디페이로드한다.
4. XML 원문 또는 JSON 변환본을 RTCDataChannel로 보낸다.
5. 각 메타 메시지에 시간 키를 반드시 붙인다.

붙여야 할 시간 키는 최소한 다음 중 하나 이상이다.

• 원본 메타 RTP timestamp
• 대응되는 영상 RTP timestamp
• RTCP SR로 환산한 NTP/capture time
• 게이트웨이 수신 시각
• 프레임 PTS 또는 프레임 인덱스

핵심은 도착 시각으로 맞추지 않는 것이다. DataChannel은 RTP/RTCP 립싱크 대상이 아니므로, 브라우저에 먼저 도착했는지 늦게 도착했는지는 동기 기준으로 쓰면 안 된다. 메타와 영상은 공통 캡처 시각 또는 RTP 타임스탬프 축에서 조인해야 한다.

정렬 정확도는 세 층으로 나눠 봐야 한다.

• 게이트웨이 내부 매칭: 같은 RTSP 세션의 RTP/RTCP 기준을 제대로 잡으면 ms 이하~수 ms 수준까지 가능하다.
• 브라우저 JS에서의 프레임 대응: 보수적으로 1프레임 단위가 현실적인 기준이다. 30fps면 약 33ms, 60fps면 약 16.7ms.
• 실제 화면 표시와 오버레이 체감: 부하, 디코딩 큐, 렌더링 타이밍, DataChannel 설정에 따라 1~2프레임 오차 예산을 잡는 게 맞다.

따라서 실무 목표는 이렇게 잡는 것이 합리적이다.

• 분석/이벤트 매칭: timestamp 기반으로 수 ms~1프레임 수준 목표
• 브라우저 오버레이 표시: 1프레임 목표, 나쁜 조건에서 2프레임 허용
• 법적/계측급 프레임 고정: 브라우저 WebRTC만으로 보장한다고 설계하면 안 됨
• “무조건 화면에 같은 프레임으로 보여야 함”: 게이트웨이에서 OSD burn-in이 가장 확실함

브라우저 호환성은 메타 트랙 수신이 아니라 동기화 API에서 갈린다. DataChannel 자체는 주요 브라우저에서 쓸 수 있다. 하지만 requestVideoFrameCallback()의 메타데이터, WebCodecs, RTP timestamp 노출 수준은 브라우저별 차이가 있으므로, 범용 제품이라면 DataChannel + 자체 timestamp + 프레임 콜백 기반의 느슨한 조인을 기본으로 보고, Chrome 계열에서는 더 정밀한 경로를 추가 최적화로 쓰는 편이 맞다.

최종 결론: “ONVIF XML 트랙 그대로 WebRTC 브라우저로 전달”은 안 된다. “영상은 WebRTC video, 메타는 DataChannel, 동기화는 명시적 timestamp로 애플리케이션에서 수행”이 사실상의 표준 경로다.

결론

RTSP ONVIF XML 메타 트랙을 WebRTC 미디어 트랙으로 “그대로” 내리는 것은 표준·브라우저 모두에서 불가능하다.
사실상 표준 경로는 게이트웨이에서 역다중화 → 영상은 media track, 메타는 RTCDataChannel 이다. ONVIF WebRTC 쪽도 이 경로(메타데이터 data channel)를 공식화한 축에 서 있다.
“정밀 동기가 필요하면 OSD burn-in만 유일해법”이라는 주장은 기계 판독 메타를 버리는 우회이지, 표준·실무의 1차 경로가 아니다.

---

다른 초안에 대한 비평

포스텔 — 흡수할 핵심 논거가 가장 강하다

SDP 수준 단절을 정확히 짚었다.

미디어 타입 문자열 application만 같고 프로토콜·포맷이 다르다. JSEP 오퍼/앤서에서 브라우저는 이 RTP 메타 m-line을 거절(port 0) 한다.
MediaStreamTrack.kind가 audio/video뿐인 점과 합치면, “트랙 그대로 릴레이”는 API 부재가 아니라 시그널링·전송 스택 설계상 자리 없음이다.
또한 RTCP SR 립싱크는 RTP SSRC 사이 전용이고 DataChannel은 그 대상이 아니므로, 도착 시각 맞춤이 아니라 페이로드에 RTP/NTP 시각을 심고 requestVideoFrameCallback의 rtpTimestamp 등으로 조인해야 한다는 지적은 내 초안의 “공통 타임스탬프”를 표준 근거로 단단히 해 준다.
이 부분은 그대로 채택한다.

나이퀴스트 — 동기 기대치를 현장 단위로 구체화

“트랙 그대로 불가 + DataChannel” 결론은 동일하고 타당하다.
게이트웨이 내부 클럭 정렬(ms 이하~수 ms)과, 브라우저 표시까지 포함하면 대략 1프레임(30fps≈33ms, 60fps≈16.7ms) 목표라는 수치는 내 “수십~100ms”보다 운용 설계에 쓸모 있다. 관제 오버레이·이벤트 표시 수준의 1차 목표로 흡수한다.
픽셀 단위 프레임 바인딩 불가는 내 입장과 같다.

반증의 칼 — 직송 불가는 옳고, 대안·동기 결론은 과격하다

맞는 점

• 비미디어 메타의 media track 직송 불가.
• Encoded Transform / SEI 임베드는 브라우저 상호운용·JS 추출이 약해 1차 상용 경로로 부적합.
• 브라우저에 “표시 중인 프레임과 메타를 미디어엔진이 자동 립싱크” 하는 API는 없다.

틀린·위험한 점

1. “DataChannel이면 동기가 원천적으로 깨진다”

전송 경로가 SRTP와 다른 것은 사실이다. 그러나 그것은 자동 동기 부재이지 애플리케이션 타임스탬프 조인 불능이 아니다. 포스텔·ONVIF 경로가 전제로 두는 것이 바로 그 조인이다. “경로가 다르다 → 동기 설계 자체가 성립 불가”는 비약이다.

2. “ms 정밀 동기 불가 → 정밀이 필요하면 OSD만 유일 해법”
3. 프레임 잠금·픽셀 정확 바인딩: 브라우저에서 보장되지 않는다 → 동의.
4. 이벤트/박스 오버레이용 수십 ms대 정렬: DataChannel + RTP TS 키잉으로 실무에서 성립하는 경로다.

OSD burn-in은 화면 위 불변 결합에는 강하지만, 브라우저가 XML/객체를 파싱·필터·알람 연동하는 요구와는 배치된다. “검증된 유일 해법”이 아니라 메타를 데이터로 쓰지 않을 때의 최후 수단이다.

3. 혼잡·재연결 리스크를 “DataChannel 폐기”로 읽은 점

오히려 DataChannel이 먼저 깨지는 지점(버퍼 적체, 순서, 유실, 재접속 후 상태 공백)을 전제로 한 관제 설계가 필요하고, 그 때문에 경로를 버리는 논리는 SRE 관점과 반대다.

입장 조정: 임베드/Transform의 상호운용 한계와 “정밀 프레임 락 불가”는 반증의 칼에 더 기울인다.
입장 유지·설득: “되는 쪽의 사실상 표준”은 여전히 DataChannel이며, OSD는 대체 표준이 아니다.

---

보완된 최종 판단

1. “트랙 그대로” — 원리적으로 불가

• 브라우저 media: audio/video + 협상된 코덱만.
• ONVIF 메타: RTSP 세션의 별도 RTP (vnd.onvif.metadata 계열).
• WebRTC SDP의 m=application은 SCTP datachannel 전용; ONVIF의 RTP m=application과 호환되지 않아 거절·드롭.
• 게이트웨이 역다중화·재포장 없는 직송 시나리오는 성립하지 않는다.

2. 사실상 표준 경로

게이트웨이는 메타 페이로드에 원 RTP TS(또는 RTCP SR 환산 시각) + 필요 시 프레임/이벤트 id를 붙인다. 수신측은 표시 프레임의 RTP TS/mediaTime 계열과 큐 조인한다.
(전송 옵션·버퍼 정책은 구현 팁이 아니라 혼잡 시 실패 모드 대응의 일부: 순서·재전송을 느슨히 두면 HOL·지연 폭주를 줄이고, 대신 앱 단 재정렬·드롭이 필수.)

3. 동기 정확도 — 합리적 기대치 (가정 명시)

• 가정: 게이트웨이가 RTSP 수신 시 영상·메타 RTP 시각을 동일 클럭으로 스탬프하고, 브라우저는 requestVideoFrameCallback(및 지원 시 WebCodecs)으로 표시 프레임 시각을 읽는다.
• 기대: 앱 조인 기준 약 1프레임대(±16~33ms 전후, 부하·지터 시 수십~100ms로 벌어짐).
• 비기대: 미디어엔진 수준의 A/V 립싱크급 자동 정렬, 픽셀·프레임 인덱스 락.
• 실패 모드: 채널 혼잡 시 메타 지연·적체 → 과거 이벤트가 현재 화면 위에 그려짐; 재연결 시 메타 스냅샷 유실 → 상태성 알람 오판. 관제용은 TS 재정렬, 최대 허용 스큐 초과분 폐기, 최신 상태 스냅샷 재동기를 전제로 설계한다.

4. 브라우저 호환 병목

• DataChannel 자체: 주요 브라우저에서 성숙 → 메타 전달 수단으로서의 병목은 아님.
• 걸리는 곳: (a) 대량 XML 연속 전송 시 메시지 크기·버퍼 관행, (b) 프레임 시각 API·WebCodecs 깊이 차이, (c) 재연결 후 메타 상태 복원 부재, (d) Transform/SEI 경로의 엔진 편중.

→ 호환 전략의 중심은 DataChannel + 앱 동기이지, 메타 RTP 직송이나 임베드가 아니다.

---

한 줄 정리

“트랙 그대로” = 안 됨 (SDP·MediaStreamTrack·페이로드 모두 자리 없음).
“DataChannel 분리 + RTP 타임스탬프 키잉” = 되는 쪽이자 ONVIF·현장 사실상 표준.
동기는 자동이 아니라 앱 계약이며 현실 목표는 프레임~수십 ms 오버레이다.
OSD는 동기 시각화의 최후 수단일 뿐, 메타데이터 전달의 표준 대체재가 아니다.

1) 다른 초안 비평

닥터 다운타임 — 내 초안의 가장 큰 누락을 짚었다. 수용한다.
ONVIF가 자체 WebRTC Specification에서 XML 메타데이터를 DataChannel subprotocol로 실어 나르도록 규정했다는 지적이 맞다면, 내가 "사실상의 표준(de facto)"이라고 쓴 것은 격하된 표현이다. 정확히는 "규격에 명문화된 경로(de jure)" 다. 즉 DataChannel 우회는 표준 밖의 임기응변이 아니라 ONVIF가 스스로 정의한 정규 경로다. 결론 문장을 이에 맞춰 수정한다.
다만 "프레임 단위 잠금은 JS API에 없다"는 단정은 과하다 — requestVideoFrameCallback의 rtpTimestamp가 정확히 그 용도로 정의된 필드다. 그러나 그 필드의 구현 편차를 감안하면 "크로스브라우저 최저선은 수십~100ms"라는 그들의 수치가 옳고, 내 "±1프레임"은 해당 필드가 채워지는 브라우저 한정 조건을 달았어야 했다. 이 부분도 수정한다.

나이퀴스트 — 페이로드 설계가 가장 정확하다.
camera_time / 원 RTP timestamp / 게이트웨이 수신시각을 모두 실으라는 제안은 내 "RTP 타임스탬프 하나"보다 낫다. 수신측이 어떤 키를 쓸 수 있느냐가 브라우저마다 다르므로, 다중 키를 보내고 수신측이 고르게 하는 것이 로버스트니스 원칙에 부합한다(보낼 때 엄격히, 받을 때 관대하게).
한 가지 보정: VideoFrame.metadata()의 rtpTimestamp(mediacapture-extensions 정의)를 얻으려면 MediaStreamTrackProcessor로 원시 프레임을 뽑아야 하는데, 이는 Chromium 계열 전용 경로다. 크로스브라우저 1차 경로로 제시하면 안 되고 requestVideoFrameCallback이 먼저다.

반증의 칼 — 세 군데가 사실과 반대다.

• "Encoded Transform은 Chromium 독점"은 뒤집힌 서술이다. 표준형 RTCRtpScriptTransform은 Safari와 Firefox(117+)가 먼저 출하했고, 오히려 Chrome이 비표준 createEncodedStreams를 오래 유지했다. 결론(크로스브라우저 아님)은 우연히 맞지만 근거가 틀렸다. - "DataChannel은 전송 경로가 달라 원천적으로 동기가 깨진다"도 틀렸다. BUNDLE(RFC 9143) 하에서 SCTP/DTLS와 SRTP는 동일한 ICE 전송·동일 5-tuple을 공유한다. 여기서 내 초안도 "경로가 다르므로"라고 쓴 것은 부정확했으므로 함께 정정한다. 실제 오차원은 네트워크 경로 분기가 아니라 수신측 미디어 지터버퍼·디코더 지연 vs. SCTP 재전송의 비대칭이다. 그리고 바로 이 때문에 도착시각 정렬은 깨지고, 타임스탬프 키 조인은 성립한다 — 원천 불가가 아니라 설계 선택의 문제다.

• "OSD burn-in이 검증된 유일한 해결책"은 수용 불가. 데이터가 픽셀로 소실되어 검색·필터·클릭·마스킹이 전부 불가능해지고, Jetson에서 재인코딩 비용을 강제한다. ONVIF가 DataChannel 경로를 규정한 이상 "유일"이 아니다. 다만 증적 녹화용 시각 오버레이로는 0프레임 오차라는 장점이 있으므로, 대체재가 아닌 보완재로 격하 수용한다.

2) 보완된 결론

Q1 — 안 된다. 두 층에서 막혀 있다.
ONVIF 메타는 m=application <port> RTP/AVP <pt> + a=rtpmap:<pt> VND.ONVIF.METADATA/90000 형태의 RTP 스트림이다. 반면 (a) 전송층: WebRTC의 RTP 사용은 RFC 8834가 규정하고, JSEP(RFC 8829)의 m=application은 RFC 8841에 따라 proto UDP/DTLS/SCTP + fmt webrtc-datachannel로 고정 — 문자열만 같고 프로토콜이 다르므로 브라우저는 이 m-line을 port 0으로 거절한다. (b) API층: MediaStreamTrack.kind는 "audio"|"video"뿐이고 addTransceiver는 그 외 값에 TypeError를 던진다. 게이트웨이에서 디페이로드 후 재포장이 필수다.

Q2 — 규격에 명문화된 경로는 DataChannel이다.
게이트웨이가 메타 RTP를 디페이로드 → XML(또는 JSON) + 다중 타임스탬프(원 RTP TS, RTCP SR로 환산한 NTP 캡처시각, camera_time) 를 함께 실어 DataChannel로 송출(RFC 8831/8832, ONVIF WebRTC Spec의 metadata subprotocol). 수신측은 도착 즉시 그리지 말고 소량 버퍼에 넣었다가 requestVideoFrameCallback 콜백 시점에 지연 조인한다. SEI 임베드는 Encoded Transform이 필요해 크로스브라우저 1차 경로가 아니고, burn-in은 데이터 활용성을 포기하는 보완재다.
전송 설정은 용도로 갈라라: 상태·이벤트성 메타는 reliable/ordered(유실 시 상태가 틀어짐), 매 프레임 오버레이는 ordered:false, maxRetransmits:0.

Q3 — 정확도는 "어느 키로 조인하느냐"의 함수다.

• rtpTimestamp 조인 가능 시: ±1프레임(30fps ≈ 33ms)
• 해당 필드 미제공 브라우저(mediaTime 폴백): 수십~100ms대 ← 이것이 크로스브라우저 보장선
• 도착시각/벽시계 정렬: 100~300ms, 튜닝으로 제거 불가한 구조적 오차
• SEI 임베드: 0프레임, 단 추출 경로가 비호환

Q4 — 병목은 메타 코덱이 아니라 동기화 API다.
DataChannel은 전 브라우저 성숙(안전한 상호운용 기반). 걸리는 곳은 ① rtpTimestamp/captureTime 등 rvfc의 WebRTC 부가 필드 구현 편차, ② Encoded Transform의 표준형/비표준형 이원화 이력, ③ MediaStreamTrackProcessor 기반 WebCodecs 경로의 Chromium 한정성, ④ 대용량 XML 연속 전송 시 메시지 크기·버퍼 관행 차이.

최종: "트랙 그대로"는 표준상 자리가 없다. ONVIF WebRTC Spec이 규정한 DataChannel 메타데이터 경로 + 다중 타임스탬프 페이로드 + 렌더 시점 지연 조인이 정답이며, 이는 우회가 아니라 규격 경로다. 목표 정확도는 rtpTimestamp 확보 시 ±1프레임, 크로스브라우저 보장선은 수십~100ms로 잡아라.

Sources:

• ONVIF Streaming Specification / ONVIF WebRTC Specification — onvif.org[1]
• RFC 8834 — Media Transport and Use of RTP in WebRTC — rfc-editor.org[2]
• RFC 8829 (JSEP), RFC 8841 (SDP for SCTP/DTLS), RFC 8831/8832 (Data Channels), RFC 9143 (BUNDLE), RFC 3550 §6.4.1
• W3C WebRTC 1.0 — w3.org[3] · mediacapture-extensions · webrtc-encoded-transform
• WICG video-rvfc — wicg.github.io[4] · MDN requestVideoFrameCallback / Using Encoded Transforms

최종 결론

표준 및 브라우저 구현 관점에서 RTSP의 ONVIF XML 메타데이터를 WebRTC 미디어 트랙으로 “그대로” 전송하는 것은 불가능합니다. 사실상 유일한 표준 경로인 RTCDataChannel 분리 송신 역시 브라우저 엔진의 한계로 인해 프레임 단위의 정밀 동기화는 원천적으로 불가능합니다.

---

참가자 초안 비평 및 논거 보완

1. "트랙 그대로 전달"의 원리적 불가능성 (포스텔 초안 흡수)

• 포스텔의 상세한 프로토콜 명세 분석이 정확합니다. 단순히 kind가 audio/video에 국한된다는 수준을 넘어, RTSP SDP의 m=application (RTP/AVP) 프로토콜과 WebRTC JSEP(RFC 8829/8841)이 요구하는 m=application (UDP/DTLS/SCTP) 간의 규격 불일치로 인해 브라우저 단에서 수신 오퍼 자체가 port 0으로 즉시 거절(Rejected)됩니다.
• 따라서 미디어 게이트웨이(Jetson) 단에서의 역다중화 및 재포장은 선택이 아닌 필수입니다.

2. ONVIF WebRTC 표준의 허상 (닥터 다운타임 초안 비평)

• "표준에 명세되어 있으니 잘 작동할 것"이라는 통념은 브라우저 구현의 진실 앞에서 무너집니다. 닥터 다운타임은 ONVIF WebRTC 규격의 Metadata data channel subprotocol을 들어 데이터 채널 송출을 해결책으로 보지만, 이는 상위 규격의 약속일 뿐입니다.
• 전송 계층에서 미디어(SRTP)와 데이터(SCTP)는 완전히 별개의 채널을 타며, 브라우저가 SCTP 데이터를 수신하여 파싱하는 메인 스레드의 처리 지연과 비디오 디코더 파이프라인의 렌더링 큐는 엔진 내부에서 물리적으로 분리되어 있습니다. 표준 서브프로토콜을 준수하더라도 네트워크 상태에 따른 비대칭적 지터와 버퍼링에 대응할 수 없습니다.

3. 1프레임 단위 정밀 동기화의 맹점 (나이퀴스트 초안 비평)

• "약 16.7~33ms(1프레임) 안팎의 동기화가 가능하다"는 주장은 극단적으로 통제된 환경을 전제한 비약입니다.
• 나이퀴스트가 언급한 requestVideoFrameCallback()의 metadata.rtpTimestamp나 WebCodecs의 VideoFrame.metadata()는 크로스 브라우저 상호운용성(Interoperability) 테스트를 통과하지 못한 반쪽짜리 API입니다.
• 설령 Chromium 계열 브라우저에서 이를 지원하더라도, 브라우저 메인 스레드 부하, 가비지 컬렉션(GC) 발생, SCTP 재전송에 의한 지연이 개입하는 즉시 JavaScript 단에서의 매칭 타이밍은 무너집니다. 실무 환경에서 1프레임 수준의 정밀도는 결코 신뢰할 수 없는 수치입니다.

---

핵심 요약 정리

1. 트랙 그대로 전달: 불가능. (SDP 프로토콜 충돌로 거절됨)
2. 사실상 표준 경로: RTCDataChannel 분리 전송. (게이트웨이에서 XML 파싱 후 타임스탬프를 심어 데이터 채널로 송신)
3. 동기화 현실: 브라우저 엔진 및 API 지원의 파편화로 인해 수십~100ms 대의 이벤트 정렬(오버레이) 수준만 기대 가능. 프레임 단위의 엄격한 픽셀 동기화가 필수라면 Jetson 게이트웨이에서 OSD(On-Screen Display)를 통해 비디오에 데이터를 구워 넣는(Burn-in) 방식 외에 대안은 존재하지 않습니다.

약점 공략: 다수 의견에서 무너지는 지점

다수가 합의한 ①"트랙 그대로 불가"는 유지된다. 그러나 ②"그러므로 DataChannel이 사실상/규격상 표준"과 ③"타임스탬프를 실으면 조인된다"는 두 축은 검증되지 않은 전제 위에 서 있다. 조문 단위로 깬다.

---

1. "ONVIF WebRTC 규격에 명문화 → de jure" 승격은 근거 없이 이뤄졌다

리뷰 1은 닥터 다운타임의 전언 하나로 "de facto"를 "de jure"로 격상했다. 그런데 이 라운드까지 조문 번호도, 서브프로토콜 문자열도, 절 제목도 제시된 적이 없다. 표준 문서에 적힌 것만이 상호운용의 근거라면, 조문을 못 대는 상태의 "명문화"는 인용이 아니라 소문이다. 승격을 철회해야 한다.

더 결정적인 것은 적용 범위다. 질문자의 구조는 카메라 → RTSP → 자체 Jetson 게이트웨이 → 브라우저다. ONVIF WebRTC 규격은 ONVIF 디바이스/서비스가 종단으로 WebRTC를 말할 때의 규정이며, 여기서는 양 끝 어디에도 적용되지 않는다. 게이트웨이가 그 서브프로토콜 이름을 따라 쓰는 건 자유지만, 그것은 준수가 아니라 명명 모방이다. "규격에 있으니 정규 경로"라는 논증은 이 구성도에서 성립하지 않는다.

2. "원본 RTP 타임스탬프를 실어라"는 조언은 틀린 키를 실으라는 조언이다

리뷰 2·3이 채택한 페이로드 설계(원 메타 RTP TS / 대응 영상 RTP TS / camera_time)에는 구조적 결함이 있다.

• RFC 3550상 서로 다른 SSRC의 RTP 타임스탬프는 랜덤 오프셋을 가지며 직접 비교 불가다. 공통 시간축은 오직 RTCP SR(6.4.1)의 NTP↔RTP 대응쌍으로만 얻는다. 그런데 ONVIF 메타 스트림은 이벤트 발생 시에만 산발 송출되는 경우가 흔하고, 그러면 SR 자체가 희소해 환산 기준점이 없다.
• 더 중요한 것: 게이트웨이가 브라우저를 향해 새 RTP 세션을 열면 타임베이스도 새로 부여된다. 브라우저가 requestVideoFrameCallback으로 읽는 rtpTimestamp는 카메라의 값이 아니라 게이트웨이 출력값이다. 원본 RTP TS를 DataChannel로 보내봐야 브라우저에는 조인 상대가 없다. 실어야 할 것은 원본이 아니라 게이트웨이 출력 RTP TS이며, 이를 위해 게이트웨이는 입력→출력 타임스탬프 매핑 테이블을 유지해야 한다. 다수 초안 중 이 항을 말한 것은 하나도 없다. - 90kHz 클럭의 32비트 RTP TS는 약 13시간에 랩어라운드한다. 상시 관제 세션에서 조인 키가 역전된다.

랩 카운터를 함께 실지 않으면 조용히 깨진다.

3. 동기 논쟁의 진짜 누락: 아무도 "수신측 지연"을 말하지 않았다

"1프레임이냐 100ms냐"를 네 초안이 다퉜지만, 조인은 메타가 프레임보다 먼저 도착할 때만 성립한다. 늦게 도착한 메타에는 붙일 프레임이 이미 없다 — 조인 알고리즘 정밀도와 무관하다.

따라서 실제 표준 경로는 "DataChannel + 타임스탬프"가 아니라 "DataChannel + 타임스탬프 + 수신측 의도적 재생 지연 버퍼" 3항이다. 비디오를 의도적으로 수백 ms 늦춰 메타 도착을 앞지르게 만드는 설계가 없으면, 위 세 초안이 제시한 어떤 수치도 통계적 평균일 뿐 보장이 아니다. 정확도 수치를 다투기 전에 지연 예산을 먼저 잡는 것이 순서다.

4. "SEI 임베드는 상호운용 부족" — 리뷰 4의 이 일축은 리뷰 1의 사실 정정과 정면 충돌한다

리뷰 1이 이미 바로잡았다: 표준형 RTCRtpScriptTransform은 Safari·Firefox가 먼저 출하했고 Chrome이 비표준 API를 오래 끌었다. 그렇다면 "반쪽짜리 API라 1차 상용 경로 부적합"이라는 리뷰 4의 판정은 리뷰 1이 폐기한 근거를 되살려 쓴 것이다.

그리고 이 경로의 구조적 이점을 다수는 아예 평가하지 않았다: 메타가 비디오 프레임과 같은 RTP 패킷 안에 실리면 조인 키도, SR 환산도, 도착 순서 역전도 문제 자체가 소멸한다. 프레임 단위 정합이 확률이 아니라 자료구조로 보장된다. "동기가 어렵다"고 100줄을 쓴 뒤 이 경로를 한 줄로 기각한 것은 균형이 맞지 않는다.

5. BUNDLE 공유는 장점이 아니라 위험이다

리뷰 1은 "BUNDLE(RFC 9143)이라 SCTP와 SRTP가 같은 ICE 전송·5-tuple을 공유하니 경로 분기 우려는 틀렸다"고 정정했다. 정정 자체는 옳다. 그러나 결론이 뒤집힌다 — 같은 전송을 공유한다는 것은 혼잡을 공유한다는 뜻이다. 대역이 좁아지면 메타가 미디어와 경합하고, SCTP 순서보장 채널은 재전송 대기 중 뒤 메시지를 막는다(HOL). 즉 BUNDLE은 메타 지연의 해소 근거가 아니라 지연이 미디어 품질과 상관되어 동시에 나빠지는 근거다.

이 때문에 메타가 저빈도·이벤트성이라면 별도 WebSocket이 DataChannel보다 낫다. 혼잡 경합에서 분리되고, 재연결·서버 수평확장·다중 구독자 팬아웃이 전부 쉬워진다. "DataChannel이 유일한 정규 경로"라는 합의는 이 반례 하나로 조건부가 된다.

---

정리된 판정

최종 선택 기준은 "표준이냐"가 아니라 "메타의 성질"이다. 프레임마다 나오고 프레임 정합이 요구되면 SEI 인밴드 + Encoded Transform, 이벤트성 저빈도면 WebSocket, 그 중간이 DataChannel이다. DataChannel은 기본값이지 정답이 아니다.

최종 판정은 이렇게 고치는 게 맞다.

RTSP의 ONVIF XML 메타데이터 RTP 트랙을 WebRTC 브라우저 수신단에 트랙 그대로 전달하는 것은 불가다. 이유는 application이라는 SDP 이름 문제가 아니라, 브라우저 WebRTC API가 임의의 RTP application 메타 트랙을 MediaStreamTrack으로 노출하지 않기 때문이다. MediaStreamTrack.kind는 본질적으로 audio/video 모델이고, WebRTC의 m=application은 RTP 메타 트랙이 아니라 SCTP/DataChannel 경로다. 근거: W3C Media Capture MediaStreamTrack.kind, WebRTC 1.0, RFC 8831, RFC 8841.

w3.org[1]
w3.org[2]
rfc-editor.org[3]
rfc-editor.org[4]

따라서 Jetson 게이트웨이는 반드시 재포장해야 한다. “그대로 전달”은 안 되고, 선택지는 세 가지다.

1. 프레임 정합이 중요하면: 비디오 인밴드 임베드
2. H.264/H.265 SEI 등으로 메타를 해당 프레임 근처에 넣고, 브라우저에서 Encoded Transform/WebCodecs 계열로 꺼낸다.
3. 장점: 메타가 비디오 프레임과 같은 흐름에 묶이므로 조인·도착순서·SR 환산 문제가 크게 줄어든다.
4. 단점: 코덱 의존, 브라우저 API 차이, 인코더/패킷화 제어 필요. 구현비가 가장 높다.
5. 적합: “이 메타는 반드시 이 프레임에 붙어야 한다”는 프레임 단위 분석/증거/계측.

2. 일반적인 실시간 제품 기본값: DataChannel
3. ONVIF XML을 디페이로드한 뒤 XML 원문 또는 JSON으로 RTCDataChannel에 보낸다. - 단, “timestamp만 넣으면 된다”가 아니라 출력 비디오 타임베이스 기준의 조인 키를 넣어야 한다. - 원본 메타 RTP timestamp만 보내는 것은 부족하다. 게이트웨이가 WebRTC로 새 비디오 RTP 세션을 만들면 브라우저가 보는 RTP timestamp는 게이트웨이 출력값이기 때문이다. - 실어야 할 키: gateway output video RTP timestamp, wrap counter 또는 확장 timestamp, capture/NTP time, gateway receive time, frame id/PTS 중 최소 2개. - 근거: RTP timestamp는 SSRC별 독립 시간축이고 RTCP SR의 NTP↔RTP 대응으로 공통 시간축을 만든다.

rfc-editor.org[1]
rfc-editor.org[2]

3. 이벤트성·저빈도 메타면: WebSocket/HTTP side channel
4. DataChannel이 항상 우월한 것은 아니다. BUNDLE 환경에서는 SCTP와 SRTP가 같은 전송을 공유하므로 혼잡도 공유한다.
5. 메타가 초당 몇 건 이하 이벤트라면 WebSocket이 재연결, 팬아웃, 서버 확장, 로깅에서 더 싸고 안정적일 수 있다.
6. 단점: 미디어와 자동 동기화는 더 없으므로 timestamp와 수신측 버퍼가 필수다.
7. 근거: BUNDLE은 여러 m-line을 같은 5-tuple 위에 묶는다.

rfc-editor.org[3]

시간 정렬의 현실적 목표는 다음이 맞다.

• 게이트웨이 내부 입력 메타↔출력 비디오 매핑: 제대로 설계하면 수 ms 수준까지 가능.
• 브라우저 JS에서 영상 프레임과 조인: 실무 기준은 1프레임 단위. 30fps면 약 33ms, 60fps면 약 16.7ms.
• 화면 오버레이까지 포함한 체감 정합: 정상 조건 1프레임, 부하·혼잡·디코딩 큐를 고려하면 2프레임 예산.
• 보장형 정합: 수신측에서 비디오를 의도적으로 지연시키는 버퍼가 필요하다. 메타가 늦게 오면 이미 표시된 프레임에는 붙일 수 없다.
• 법적/계측급 “동일 프레임 보장”: 브라우저 WebRTC + side channel만으로 설계하면 안 되고, 게이트웨이 burn-in 또는 인밴드 임베드가 맞다.

브라우저 호환성 결론도 정리하면 이렇다.

• ONVIF XML RTP 트랙을 브라우저가 WebRTC 트랙으로 직접 받는 경로: 없다고 봐야 한다.
• DataChannel: 주요 브라우저에서 실용 가능.
• 정밀 동기 API: requestVideoFrameCallback, RTP timestamp 노출, Encoded Transform, WebCodecs 지원 차이가 있어 제품 기본 경로로는 보수적으로 잡아야 한다.
• SEI/Encoded Transform: 동기 구조는 가장 좋지만 구현비와 브라우저별 검증 비용이 크다.

최종 결론: “ONVIF XML 트랙 그대로 WebRTC 브라우저 전달”은 안 된다. 기본 상용 경로는 “비디오는 WebRTC video, 메타는 DataChannel 또는 WebSocket, 조인은 게이트웨이 출력 비디오 timestamp와 수신측 지연 버퍼로 수행”이다. 프레임 고정 정합이 핵심이면 SEI 인밴드가 더 옳다.

최종 수정안

결론 (단정)

RTSP ONVIF XML 메타 트랙을 WebRTC 미디어 트랙으로 “그대로” 전달하는 것은 불가능하다.
게이트웨이 역다중화·재포장 없는 직송 시나리오는 성립하지 않는다.

“되는 쪽”은 하나가 아니라 메타 성질에 따른 세 갈래다.

• 프레임 단위·프레임 정합 필수 → 인밴드(SEI 등) + RTCRtpScriptTransform
• 중간 빈도·브라우저 내 실시간 결합 → 영상 media + RTCDataChannel + 출력 RTP TS 키잉 + 수신 재생 지연 버퍼
• 이벤트성·저빈도·다중 구독 → 별도 WebSocket(또는 동등 시그널 채널)

이 토폴로지(카메라→RTSP→자체 Jetson→브라우저)에서 ONVIF WebRTC 디바이스 규격을 de jure 정규 경로로 승격하는 주장은 철회한다. 조문·서브프로토콜이 제시되지 않았고, 양 끝이 ONVIF WebRTC 종단이 아니므로 적용 범위 밖이다. DataChannel은 실무 기본값(de facto 후보)이지, 이 구성도에서 규격상 유일 정답이 아니다.

---

1. “트랙 그대로” — 원리적으로 불가

근거 정리: 게이트웨이는 보통 RTSP SDP를 브라우저에 그대로 오퍼하지 않으므로 “SDP port 0 거절” 시나리오는 실제 사고 경로의 핵심이 아니다.
더 단단한 근거는 MediaStreamTrack이 비미디어 트랙을 표현하지 못한다는 W3C 제약과, WebRTC가 브라우저로 실어 나르는 미디어 파이프가 A/V(+선택 데이터 채널)로 고정되어 있다는 점이다.
포스텔 초안의 SDP 단절 표는 “왜 브라우저 스택에 자리가 없는가”를 설명하는 보조 근거로 유지하되, 1차 근거는 kind·전송 스택 설계로 둔다.

→ 별도 변환 없이 트랙 릴레이 = 불가. 다른 경로가 필수.

---

2. 경로 선택 — “표준 하나”가 아니라 실패 모드별 선택

DataChannel을 “유일 정규”로 두지 않는 이유 (약점 공략 흡수)

1. de jure 근거 부재 — ONVIF WebRTC 조문 미제시 + 본 구성 적용 범위 밖.
2. BUNDLE(RFC 9143)으로 SCTP·SRTP가 같은 ICE/5-tuple을 공유하면 경로 분기는 줄지만, 혼잡은 공유된다. 메타 폭주 = 미디어 품질 동반 악화. 저빈도 이벤트면 WebSocket 분리가 더 안전한 실패 격리다.
3. 인밴드는 조인 키·도착 순서 역전 문제를 자료구조로 소멸시킨다. “동기 어렵다”고 쓰고 SEI를 한 줄 기각한 것은 균형 실패였다.
4. 다만 1차 상용 기본으로 올리지 않는 이유: 게이트웨이 재인코딩/트랜스코딩 경로에서 SEI 보존이 깨지기 쉽고, Transform 파이프라인은 브라우저·배포 정책 편차가 남는다. “구조적으로 동기 최강” ≠ “모든 Jetson→브라우저 관제에서 기본값”.

실무 선택 규칙 (단정)

• 박스/마스크가 그 프레임에 붙어야 하면 → A 우선.
• 관제 오버레이·알람(프레임~수십 ms)이고 단일 세션이면 → B.
• 메타가 초당 수 회 이하 이벤트이고 구독자가 많으면 → C.
• 사람 눈만 보면 되면 → D.

---

3. 동기 — 수정된 3항 계약 (조인만으로는 불성립)

잘못된 키 (기각)

• 카메라/원본 메타 RTP TS를 그대로 조인 키로 보내는 것.
• RFC 3550: 서로 다른 SSRC의 RTP TS는 랜덤 오프셋, 직접 비교 불가.
• 공통 축은 RTCP SR(NTP↔RTP). 메타가 산발이면 SR 희소 → 환산 기준 공백.
• 게이트웨이가 새 RTP 세션을 열면 브라우저 requestVideoFrameCallback의 rtpTimestamp는 출력 타임베이스. 원본 TS는 조인 상대가 없다.

올바른 키 (채택)
게이트웨이가 유지할 것:

1. 입력 영상·메타 → 공통 클럭(수신 시각 또는 SR 환산) 정렬
2. 출력 영상 RTP TS(게이트웨이 부여) 매핑 테이블
3. DataChannel/WS 페이로드에 out_rtp_ts + wrap 카운터(32bit 랩, ~13h@90kHz) + 이벤트 id/상태 버전
4. (선택) wall-clock/NTP는 로그·감사 축; 브라우저 프레임 조인 1차 키는 출력 RTP TS

세 번째 필수항: 수신측 의도적 재생 지연
메타가 프레임보다 늦게 오면 붙일 프레임이 이미 없다. 조인 알고리즘 정밀도와 무관.
→ DataChannel/WS + 타임스탬프 + 수신 재생 지연 버퍼가 한 세트.
지연 예산을 먼저 잡고(예: 목표 스큐 상한 + 네트워크 지터 여유), 그 안에서만 “1프레임대” 수치를 말한다.

합리적 가정과 기대치

• 가정: Jetson이 입력 정렬 후 출력 TS를 스탬프; 브라우저가 requestVideoFrameCallback(지원 시 WebCodecs)으로 표시 프레임 TS를 읽음; 의도적 playout delay 운용.
• 기대 (B 경로, 지연 예산 충족 시): 오버레이용 약 1프레임대(±16~33ms @60/30fps), 부하·지터 시 수십~100ms로 벌어짐.
• 비기대: 미디어엔진 A/V 립싱크급 자동 정렬, 픽셀 단위 프레임 락(인밴드 없이).
• A 경로: 같은 RTP 프레임에 실리면 프레임 정합은 구조적으로 보장(도착 역전·SR 조인 이슈 소멸). 대신 보존·호환 리스크를 예산에 넣는다.

실패 모드 (관제 사고 경로)

---

4. 브라우저 호환 병목

호환 전략의 중심:

• 기본 관제: B 또는 C + 출력 TS + playout delay
• 프레임 락: A
• 메타 RTP 직송·“트랙 그대로”는 후보에서 제외

---

5. 질문에 대한 직접 답

1. 그대로 실어 나를 자리? → 없다. 원리적으로 불가. 재포장 필수.
2. 실무 경로? → 위 A/B/C (성질별). OSD는 메타 API가 필요 없을 때만.
3. 동기 정확도? → 지연 예산 전제 하에 오버레이 1프레임~수십 ms; 자동 립싱크·픽셀 락(비인밴드) 비기대.
4. 브라우저 병목? → 직송 불가가 본질; 호환 이슈는 시각 API·Transform/SEI 보존·재연결 상태이지 DataChannel 존재 여부가 아님.

---

한 줄

“트랙 그대로” = 안 됨.
되는 쪽 = 메타 성질에 따른 A(인밴드)·B(DataChannel)·C(WebSocket)이며, B가 기본 후보일 뿐 de jure 유일 표준이 아니다.
동기는 출력 RTP TS + wrap + 수신 지연 버퍼의 앱 계약이다.
OSD는 표준 대체재가 아니다.

---

입장 변경 요약 (설득·설득됨)

1) 최종 수정안

이번 공략은 다섯 발 중 세 발이 명중했다. 명중한 건 그대로 받고, 빗나간 두 발은 되받는다.

---

수용 ①: "ONVIF WebRTC 규격 = de jure" 승격을 철회한다

내가 틀렸다. 전언 하나로 조문 격을 올린 것은 내 원칙("표준 문서에 적힌 것만이 상호운용의 근거") 위반이다. 조문 번호·절 제목·subprotocol 문자열을 이 라운드에서 아무도 제시하지 못했으므로 인용으로 취급할 수 없다. 게다가 지적대로 적용 범위도 다르다 — 질문자 구성은 카메라 → RTSP → 자체 Jetson 게이트웨이 → 브라우저이고, 여기서 브라우저 종단은 ONVIF 디바이스가 아니다. 게이트웨이가 그 명명을 따르는 것은 준수가 아니라 모방이다.

다만 결론은 근거를 갈아 끼우고 살아남는다. DataChannel이 기본값인 근거는 ONVIF가 아니라 IETF/W3C다. WebRTC에서 비미디어 임의 애플리케이션 데이터를 실을 수 있도록 규정된 유일한 자리가 SCTP 기반 Data Channel(RFC 8831 아키텍처, RFC 8832 DCEP, RFC 8841 SDP 매핑)이다. de jure는 ONVIF가 아니라 RFC 8831 쪽에서 나온다. 격은 유지되고 출처만 바뀐다.

수용 ②: 조인 키는 "원본 RTP TS"가 아니라 "게이트웨이 출력 RTP TS"다 — 내 오류였다

이건 이번 라운드 최고의 지적이고, 내 초안과 나이퀴스트 초안이 함께 틀렸다.

• RFC 3550 §5.1상 RTP 타임스탬프의 초기값은 랜덤이고, 서로 다른 SSRC 간 직접 비교는 §5.1/§6.4.1에 따라 RTCP SR의 NTP↔RTP 대응쌍 없이는 불가능하다. - 결정적으로, 게이트웨이가 브라우저를 향해 새 RTP 세션을 개시하면 타임베이스는 새로 부여된다. 브라우저의 requestVideoFrameCallback이 노출하는 rtpTimestamp는 게이트웨이 출력 패킷의 값이지 카메라 값이 아니다. 원본 TS를 아무리 정성껏 실어도 브라우저 쪽에 대응 상대가 없다. - 따라서 게이트웨이는 입력 TS → 출력 TS 매핑 테이블을 유지하고, DataChannel 페이로드에 out_rtp_ts(게이트웨이 출력 타임베이스)를 반드시 넣어야 한다. 원본 TS와 camera_time은 감사·로깅용 보조 필드로 강등한다. - 랩어라운드도 맞다. 90kHz·32비트는 2^32 / 90000 ≈ 47,721초 ≈ 13.3시간. 상시 관제에서 조용히 역전된다.

wrap_count(또는 64비트 확장 TS)를 함께 실어라. 이건 조인 키 설계의 필수항이지 튜닝이 아니다.

수용 ③: 동기의 세 번째 항은 "수신측 지연 예산"이다 — 단, 방향을 바로잡는다

"메타가 프레임보다 먼저 도착해야 조인이 성립한다"는 명제는 옳다. 누락도 인정한다. 하지만 기본 상황은 이미 유리한 쪽으로 기울어 있다. WebRTC 수신 비디오는 지터버퍼 + 디코드 + 렌더 파이프라인을 통과하므로 통상 수백 ms 지연되고, SCTP 메시지는 그보다 짧은 경로로 도착한다. 즉 평시엔 메타가 먼저 온다.

깨지는 건 두 경우다: (a) reliable/ordered 채널이 재전송 대기 중 HOL 블로킹될 때, (b) 지터버퍼가 좁게 수렴할 때. 그래서 처방은 "무조건 비디오를 수백 ms 늦춰라"가 아니라:

1. 메타 측에 슬라이딩 윈도우 버퍼를 두고 TS 키로 보관, 프레임 렌더 시점에 지연 조인
2. 매 프레임 오버레이 채널은 ordered:false, maxRetransmits:0 — HOL 원천 차단
3. late-metadata 비율을 계측해 임계 초과 시에만 명시적 재생 지연을 추가

지연 예산을 먼저 잡으라는 순서 지적은 옳다. 수치 논쟁보다 앞선다.

---

반박 ①: BUNDLE 공유는 동기에 관한 한 장점이 맞다

"같은 전송 = 같은 혼잡 = 위험"은 절반만 맞다. 혼잡 공유가 처리량에 불리한 건 사실이다. 그러나 지금 다투는 축은 시간 정렬이고, 여기서는 부호가 뒤집힌다.

• BUNDLE(RFC 9143) 하에서 SRTP와 SCTP/DTLS는 동일 ICE 전송·동일 5-tuple을 공유한다. 경로가 같으면 지연 변동이 상관(correlated) 된다 — 네트워크가 나빠지면 둘이 같이 늦는다. 상대 오프셋은 유지된다.
• 별도 WebSocket은 TCP이며 다른 경로·다른 프록시·다른 혼잡 제어를 탄다. 지연이 무상관이 되고, TCP 자체 HOL까지 있다. 손실 구간에서 WebSocket이 SCTP unordered/unreliable보다 나쁠 수 있다.
• 즉 WebSocket은 동기 정확도를 개선하지 않는다. 운영 편의(재연결·팬아웃·수평확장·PeerConnection 비의존)를 개선할 뿐이다.

절충 판정: 동기 허용오차가 초 단위인 저빈도 이벤트 메타 → WebSocket이 합리적. 프레임 정합이 요구되는 메타에 WebSocket을 쓰는 것은 설계 오류다. 조건부 반례로는 성립, "DataChannel 기본값" 기각 근거로는 불성립.

입장 변경: SEI 인밴드 — 기각에서 조건부 1순위로 올린다

여기선 공략 쪽이 이겼고, 나도 초안에서 "크로스브라우저 1차 경로 아님"이라 쓴 것을 수정한다. 결정적인 건 공략 쪽도 명시하지 않은 비대칭성이다:

• 송신측에 브라우저 API가 필요 없다. 송신자는 Jetson 게이트웨이(네이티브)다. H.264 unregistered user data SEI(payloadType 5, UUID 기반)를 비트스트림에 직접 삽입하면 끝이다. Encoded Transform이 필요한 쪽은 수신 브라우저 한 곳뿐이고, 표준형 RTCRtpScriptTransform은 Safari·Firefox가 먼저, Chrome이 뒤이어 출하해 3엔진에 존재한다.
• 그리고 구조적 이점이 압도적이다: 메타가 프레임과 같은 인코딩 프레임 안에 있으면 조인 키도, SR 환산도, 도착 역전도, 랩어라운드도, 지연 버퍼도 문제 자체가 소멸한다. 정합이 확률이 아니라 자료구조로 보장된다.

남는 비용은 정직하게: ① 수신측에서 NAL 파싱(emulation prevention byte 처리 포함)을 JS/WASM으로 직접 해야 함, ② XML이 미디어 혼잡 예산 안으로 들어와 다객체 분석 결과가 프레임당 KB 단위로 붙으면 비트레이트를 잠식, ③ 중간에 SFU 트랜스코딩이 끼면 SEI가 소실될 수 있음(E2E 패스스루 전제 필요).

---

최종 답 (Q1~Q4)

Q1 — 안 된다. 근거는 두 층, 그리고 조문의 무게는 API층에 있다.
지적대로 게이트웨이는 카메라 SDP를 그대로 오퍼하지 않으므로 "port 0 거절"은 가설적 시나리오다. 작동하는 근거는 W3C WebRTC 1.0의 MediaStreamTrack.kind가 "audio"|"video"로 한정되고 addTransceiver가 그 외 값에 TypeError를 던진다는 점이다. 전송층 근거(RFC 8841이 m=application의 proto를 UDP/DTLS/SCTP, fmt를 webrtc-datachannel로 고정)는 "설령 오퍼해도 자리가 없다"는 보강일 뿐이다. VND.ONVIF.METADATA/90000 RTP 스트림은 게이트웨이에서 디페이로드 후 재포장이 필수다.

Q2 — 단일 정답 없음. 메타의 성질로 갈린다. (이 점은 공략 쪽 프레임이 옳다)

DataChannel 페이로드 필수 필드: out_rtp_ts(게이트웨이 출력 타임베이스) + wrap_count — 이 둘이 조인 키. camera_time·원본 RTP TS는 감사용 보조. 채널 설정은 상태·이벤트성은 reliable/ordered, 매 프레임 오버레이는 ordered:false, maxRetransmits:0.

Q3 — 정확도.

• SEI 인밴드: 0프레임. 구조적 보장
• rtpTimestamp 조인 성립 시: ±1프레임(30fps ≈ 33ms)
• mediaTime 폴백: 수십~100ms대 ← 크로스브라우저 보장선
• 도착시각/벽시계 정렬: 100~300ms, 튜닝으로 제거 불가
• 단, 위 수치는 late-metadata 비율이 관리될 때만 유효하다. 지연 예산을 먼저 잡아라.

Q4 — 병목은 메타 코덱이 아니라 동기 API다. DataChannel은 전 브라우저 성숙. 걸리는 곳: ① rvfc의 rtpTimestamp/captureTime 등 WebRTC 부가 필드 구현 편차, ② Encoded Transform 표준형/비표준형 이원화 이력, ③ MediaStreamTrackProcessor 경로의 Chromium 한정성(1차 경로로 쓰지 말 것), ④ 대용량 XML 연속 전송 시 메시지 크기 관행 차이.

결론: "트랙 그대로"는 표준상 자리가 없다 — 이건 흔들리지 않는다. 그러나 "DataChannel이 정답"은 과했다. DataChannel은 기본값이고, 프레임 정합이 요구되면 SEI 인밴드가 상위 해답이며, 조인 키는 반드시 게이트웨이 출력 타임베이스 + 랩 카운터여야 한다.

Sources

• RFC 8834 (WebRTC의 RTP 사용) — rfc-editor.org[1]
• RFC 8831 (Data Channels 아키텍처) — rfc-editor.org[2] · RFC 8832 (DCEP) · RFC 8841 (SDP for SCTP/DTLS)
• RFC 8829 (JSEP) · RFC 9143 (BUNDLE) · RFC 3550 §5.1, §6.4.1
• W3C WebRTC 1.0 (MediaStreamTrack.kind) — w3.org[3] · webrtc-encoded-transform · mediacapture-extensions
• WICG video-rvfc — wicg.github.io[4]
• ONVIF Profiles & Specifications — onvif.org[5] *(Streaming Spec의 VND.ONVIF.METADATA 정의 근거로만 인용.

WebRTC Spec은 이번 라운드에서 조문 확인 불가하여 논거에서 제외)*

최종 수정안

RTSP의 ONVIF XML 메타데이터를 WebRTC로 송출하는 것에 대한 검증 결과는 다음과 같습니다. "표준에 있으니 된다"거나 "타임스탬프만 매칭하면 동기화된다"는 통념은 실제 브라우저 파이프라인과 프로토콜 단위의 제약으로 인해 성립하지 않습니다.

---

1. "트랙 그대로 전달"의 원리적 불가능성

• 불가능합니다. SDP 협상(port 0 거절) 이전에, W3C WebRTC 명세상 MediaStreamTrack.kind는 오직 audio와 video로만 제한됩니다. RTSP의 비미디어 XML 메타데이터 트랙을 WebRTC 미디어 트랙으로 우회 없이 "그대로" 전송하는 경로는 표준상 존재하지 않으며, 게이트웨이 단에서의 역다중화(Demuxing)가 강제됩니다.

2. RTCDataChannel 분리 송신의 구조적 한계와 de jure의 허상

• ONVIF WebRTC 규격 적용 불가: ONVIF WebRTC의 Metadata data channel subprotocol 규격은 단말(Device/Service) 간 직접 통신 규정으로, 카메라 → RTSP → 게이트웨이 → 브라우저 구조인 본 시스템 모델에는 적용 범위 밖입니다.
• BUNDLE(RFC 9143) 혼잡 공유 및 HOL 블로킹: SCTP(데이터)와 SRTP(미디어)가 동일한 5-tuple 전송로를 공유하므로, 대역폭 경합 발생 시 SCTP의 재전송 메커니즘이 동작하면서 미디어의 지연과 혼잡을 동반 유발합니다. 메타데이터가 비정기적 이벤트성인 경우, 웹소켓(WebSocket)을 이용해 경로를 물리적으로 분리하는 것이 결합도 완화 및 안정성 면에서 더 타당합니다.

3. RTP 타임스탬프 동기화의 맹점

• 직접 비교 불가: RFC 3550[1]에 따라 서로 다른 SSRC의 RTP 타임스탬프는 무작위 오프셋을 가져 단순 비교할 수 없습니다.
• 게이트웨이 타임베이스 변환 필수: 브라우저의 requestVideoFrameCallback 등이 읽는 RTP TS는 원본 카메라의 값이 아닌 게이트웨이가 재부여한 출력 세션의 TS입니다. 따라서 게이트웨이에서 입출력 타임스탬프 매핑 테이블을 유지하고, 90kHz 클럭의 32비트 랩어라운드(약 13시간 주기로 역전)에 대응할 랩 카운터를 데이터에 함께 실어야만 동기 조인이 동작합니다.
• 지연 예산(Buffer) 누락: 메타가 프레임보다 늦게 도착하면 정합 알고리즘과 무관하게 동기가 무너집니다. 비디오 재생을 의도적으로 수백 ms 지연시키는 수신측 버퍼 설계 없이는 통계적 동기를 보장할 수 없습니다.

4. 최선의 상호운용 대안: H.264/H.265 SEI 임베드 + RTCRtpScriptTransform

• 메타데이터를 영상 프레임 내부의 SEI(Supplemental Enhancement Information) 페이로드로 인밴드(In-band) 패킹하면 RTP 패킷 단위로 묶여 전송되므로, 수신 타이밍 역전 및 타임스탬프 매칭 문제 자체가 완벽하게 소멸합니다.
• RTCRtpScriptTransform은 Chromium, Safari, Firefox 등 주요 브라우저 엔진 전체에서 표준 API로 지원되므로 상호운용성 리스크가 가장 적으며, 프레임 단위의 정밀 동기화가 확실하게 담보되는 유일한 정규 경로입니다.

---

결론 요약 및 아키텍처 선택 기준

1. 프레임 단위의 엄격한 동기 필요: 비디오 SEI 임베드 + RTCRtpScriptTransform (최선) 또는 게이트웨이 OSD Burn-in (차선)
2. 지연에 덜 민감한 고용량 XML 데이터: RTCDataChannel 분리 송신 (단, 게이트웨이 측 RTP TS 매핑 테이블 및 수신측 재생 지연 버퍼 구현 필수)
3. 이벤트성/저빈도 데이터: 별도 WebSocket 세션 분리 (혼잡 경합 최소화)