[2026] RTSP(Real Time Streaming Protocol) 완전 참조 — RFC 2326·7826·SDP·RTP·IP카메라·FFmpeg

RTSP(Real Time Streaming Protocol)는 미디어 서버(또는 IP 카메라/인코더)와 클라이언트(뷰어·NVR·릴레이 서버)가 세션을 설정하고(SETUP), 재생(PLAY)을 제어하기 위한 애플리케이션 계층 프로토콜입니다. 전송이 반드시 RTSP 자체에 실리는 것은 아니며(대부분 RTP/RTCP), 제어(RTSP)와 미디어(RTP)를 어떻게 묶을지가 이 프로토콜의 핵심입니다. 1.0은 IETF RFC 2326로, 2.0은 RFC 7826로 정리됩니다(문맥·보안·프레이밍이 강화).

이 글은 스펙(메서드·SDP·RTP) → 장비(ONVIF·URL·인증) → 구현(FFmpeg·GStreamer) → 배포(방화벽·NAT·QoS) → 운영(버퍼·GOP·다중 스트림) 순으로, CCTV/방송/클라우드 인제스트가 만나는 지점의 체크리스트를 겨냥합니다. 단, 제조사/펌웨어별 경로·코덱·기본 포트는 달라질 수 있으므로, 여기의 URL 예는 검증용 템플릿으로만 보시기 바랍니다.

---

1. 프로토콜 스펙: RFC 2326과 RFC 7826

1.1 RTSP 1.0(2326)과 2.0(7826)의 차이(실무 시야)

• 문자열 기반(1.0) vs 정교한 프레이밍(2.0): 2.0은 파이프라이닝·상호운용(프록시) 시나리오를 더 엄밀히 다루며, 전송/보안(예: URI 스킴, TLS 측면) 쪽 요구를 정비합니다(세부는 RFC 7826의 전반부를 권장).
• 하위호환/공존: 여전히 많은 IP 카메라/업체 미디어 서버는 1.0 유사 텍스트 RTSP를 사용합니다. 클라이언트는 “OPTIONS 응답/서버 헤더/동작(파이프라이닝 지원)“으로 실제 지원을 확인하는 편이 안전합니다.
• 식별/제어 토큰: 2.0은 세션/요청/리소스 모델을 더 명시합니다. NVR/릴레이를 자체 제작할 때 세션 Session 헤더와 리소스 URL을 일관되게 취급해야 합니다.

운영 메모: “스펙은 2.0인데 장비는 1.0”이 흔합니다. 장비 매트릭스(펌웨어/모델) 를 먼저 얻는 것이 비용이 가장 낮습니다.

1.2 RTSP 메서드(핵심 6+α)

§12 RFC 2326 / §16 RFC 7826 흐름에 맞춰 대표 메서드를 이해합니다.

메서드	역할(요지)	실무에서 자주 보는 이유
OPTIONS	지원 메서드·기능 탐색	클라/라이브러리가 사전 능력 확인
DESCRIBE	Content-Type: application/sdp로 세션 설명(SDP) 획득	코덱/포트/제어 URL이 여기에
SETUP	전송 모드(UDP/TCP)와 세션 생성/연결	Session 헤더로 이후 상태 유지
PLAY	재생 시작(범위·스케일)	NVR/뷰어 시작
PAUSE	일시정지(가능한 경우)	일부 카메라는 미지원/무시
TEARDOWN	세션 종료	누수(세션/소켓/디코더) 방지
(기타) ANNOUNCE, RECORD, SET_PARAMETER…	송신/기록/메타/Keep-alive	라이브 송신 서버/카메라 구현에 따라 등장

• CSeq: 요청-응답 쌍 상관관계를 맞추는 번호(디버그 시 클라·서버 로그를 맞출 때 핵심).
• 응답 코드: 2xx/4xx/5xx는 HTTP와 유사한 운영감이 있습니다(인증/리다이렉트·세션만료).

1.3 SDP(Session Description Protocol)

DESCRIBE 응답 본문은 SDP(RFC 8866 등)로 오는 것이 대표적입니다. 최소로는 미디어行(m=), RTP/AVP/프로필, RTPmap, a=control(RTSP Content-Base·상대 URL)을 같이 읽어야 실제로 어디로 RTP가 뜨는지가 결정됩니다.

• m=video / m=audio: 포트(또는 0)와 프로토콜(예: RTP/AVP).
• a=rtpmap:96 H264/90000: 동적 페이로드 타입(PT) ↔ 코덱 연결(타임스탬프 클럭도 표시).
• a=fmtp: SPS/PPS(예: H.264) 등 Codec-specific 메타(디코딩/파싱에 직접 영향).
• a=control:trackID=0 등: SETUP/PLAY가 붙는 RTSP “미디어 리소스 URL” 힌트(구현·벤더에 따라 Content-Base 합쳐 해석).

1.4 RTP/RTCP와의 관계

• RTP(Real-time Transport): 페이로드(비디오/오디오) 타임스탬핑/시퀀싱/재정렬의 주역.
• RTCP(RTP Control): SR/RR(송·수신 보고), SSRC 기준 세션 품질 지표 제공. A/V 립싱크·통계에 유용(경로/코덱이 갖춰졌다면).
• RTSP는 ‘제어’이지 반드시 ‘미디어’가 실리는 곳은 아님: SETUP에서 합의한 ‘전달’이 RTP/RTCP(혹은 interleaved로 동일 TCP에 실림).

1.5 UDP vs TCP(및 RTP+RTCP 포트)

• RTP(UDP): 지연이 낮을 수 있으나 패킷 손실·도착 간격(지터) 그대로 체감됩니다. 방화벽/카망/이중 NAT에 취약.
• RTSP over TCP + Interleaved(아래): 관리/안정에 유리한 경우가 많고, 대역/CPU·지연/지터 트레이드오프를 평가해야 합니다.
• RTCP 포트는 RFC 3550 관례에 따라 RTP+1이 일반적(구현체가 SETUP·SDP로 명시).

1.6 Interleaved 모드(프레이밍)

RTP(및 RTCP)를 RTSP와 동일한 TCP 연결로 실을 때, 바이트 스트림에 프레이밍이 필요합니다. 1.0에서는 §10.12 RFC 2326 Interleaved 개념이 설명됩니다(페이로드 앞 $$ 1채널 id + 길이).

• 효과: 방화벽 UDP hole이 어려운 환경에서 “한 TCP만 열기” 용이.
• 한계/주의: TCP 혼잡 제어/재전송으로 지연 변동(지터), HOL(Head-of-line) 특성(혼잡 시 체감) 이슈. GOP·서버/클라이언트 소켓 버퍼와 팀.

FFmpeg(개념 예시): rtsp://… pull 시, UDP가 어려우면 TCP를 지정(환경/버전에 따름).

# 예: TCP로 RTSP(RTP) 수신(환경/빌드·장비에 따라 옵션명은 변형될 수 있음)
ffplay -rtsp_transport tcp "rtsp://user:pass@192.0.2.10:554/Streaming/Channels/101"

위 예는 뷰어(재생) 단계에서 “UDP AVP가 터질 때” 우회책을 빠르게 시험하는 데 쓰입니다. 운영에서는 장비/중계 서버/ISP에 맞춰 최적 전송/버퍼를 고정 측정하십시오.

---

2. IP 카메라 / CCTV

2.1 ONVIF 프로파일(개요)

ONVIF는 IP 영상·보안 상호운용을 위한 프로파일(기능군)을 둡니다(세부·버전은 프로필/년도로 변동).

• Profile S(스트리밍): H.264 스트리밍·RTSP·오디오·메타(구현/버전에 따름) — CCTV/시청이 가장 흔히 겹치는 층.
• Profile T(고급): H.265 등 최신 코덱/고급 기능(장비/펌웨어·클라이언트 동시 지원 필수).
• (참고) Profile G(기록), Profile M(메타), Profile A(액세스) 등: NVR/알람/VMS/출입와 조직 표준에 연결.

실전: “ONVIF supported”가 VMS에서만 뜨고, RTSP URL은 은닉/비표준인 경우가 있습니다. 장비의 RTSP/미디어 문서를 병기하십시오.

2.2 RTSP URL 구조(검증 필수)

일반적 형식은 rtsp://[user[:pass]@]host[:port]/path[?query] 정도로 이해하되, 경로/스킴(포트)은 제조사·모델·펌웨어에 강하게 의존합니다(여기 템플릿은 예시).

# 예시(기종별로 다름) — **실제 본인 장비**와 일치하는지 캡처로 검증
rtsp://admin:****@198.51.100.5:554/cam/realmonitor?channel=1&subtype=0
rtsp://user:****@198.51.100.5:8554/h264?channel=0&stream=0.sdp
rtsp://192.0.2.10:554/Streaming/Channels/101

• subtype/quality: 메인(고화질)·서브(저화질) 멀티 스트림 토글에 자주 쓰입니다(업체·모델별 키 이름 상이).
• .sdp가 붙는 경우: 실제 MIME·장비 페이크 확장일 수 있어 WGET/curl/players로 DESCRIBE 본문을 확인이 안전.
• 포트 554(기본) vs 커스텀: 554가 막히면 8554 등 대체를 쓰는 장비·중계가 있습니다.

2.3 인증: Digest(과 Basic)

카메라는 RTSP/HTTP 모두 RFC 7616 HTTP Digest를 흔히 씁니다(레거시는 Basic).

• 초기 401/407 + WWW-Authenticate → 응답 Authorization: DESCRIBE~PLAY 전 구간에서 반복(구현/프록시/재처리). 누락 시 세션/인증 루프에 빠질 수 있음.
• 크리덱 관리: 펌웨어에서 권한·비번 정책(회전/잠금)·VLAN/ACL·RTSP HTTPS(TLS) 중계(프록시) 를 병행(평문 다이제스트/베이직은 경로·노출에 취약).

2.4 PTZ 제어(ONVIF PTZ vs RTSP)

• ONVIF PTZ(HTTP/SOAP 등) 는 RTSP가 아닌 별도 서비스로 동작하는 구성이 흔합니다(프로필/장비/버전 기준). VMS(예: iSpy, Milestone, Blue Iris 등) 는 ONVIF PTZ+프로필/토큰에 맞춥니다.
• “RTSP URL에 쿼리로 PTZ” 스타일은 벤더/모델 한정이 많고, 표준이라기보다 기기 전용에 가깝습니다. 문서·캡처로 명령 체인을 고정하십시오.

2.5 멀티캐스트(멀티캐스트)

일부 NVR/방송/캠퍼스망은 RTP의 멀티캐스트를 씁니다. SETUP·SDP c=IN IP4 멀티캐스트 그룹·IGMP 스누핑/라우팅/ACL·PIM·VLAN/Querier가 필수 점검입니다(UDP 멀티캐스트는 “켜는 것만으로는 안 뜸”).

• CCTV/사내망: 스위치 IGMP·MVR(Multicast VLAN) 정책, PIM-SSM·RPF·BFD(규모에 따라)까지.
• 클라우드/인터넷: 멀티캐스트 end-to-end는 현실적으로 어려운 경우가 많고, Unicast+중계(미디어 서버/클라우드 인제스트) 가 일반론.

---

3. 실전 구현(FFmpeg·GStreamer·파이프라인)

3.1 FFmpeg로 RTSP 소스 받기(개념)

• RTSP(클라이언트) 소스는 rtsp:// demuxer가 담당(라이브러리 버전/빌드에 따라 옵션이 약간 다름).
• TCP 선호(연결/방화벽): 앞서 언급한 -rtsp_transport tcp 계열(구현/문서 ffmpeg-all).
• 오디오/비디오 모두 map·copy·re-mux 시 시간기준이 달라 아주 드문 음·영상 어긋남이 있을 수 있으니(특히 B-frame·VFR) VFR 전처리/비디오만·-vsync/aresample을 고려(환경·코덱에 따라).

# 예: RTSP → 파일(코덱 copy, 컨테이너만 변경). 실서비스는 세그먼트·킬스위치·로그·모니터링이 추가됩니다
ffmpeg -hide_banner -rtsp_transport tcp -i "rtsp://user:pass@198.51.100.5:554/stream" \
  -c copy -f mpegts "C:\\recordings\\out.ts"

3.2 RTSP 출력(푸시): RTMP / HLS로 릴레이(개념)

• RTSP → RTMP(재인코딩/복사): Nginx-RTMP·mediamtx(구 rtsp-simple-server)·SRS 등 중계(미디어 서버) 는 ffmpeg로 끼워 넣는 패턴이 흔합니다(부하/라이선스/동시 세션 주의).
• RTSP → HLS(세그먼트): 세그먼트 길이·EXT-X-* 태그·킬러(프로세스)·누락 세그 예외·썸네일/DRM·캐시 정책을 함께(상세: 본 블로그 HLS 완전 참조).

# 예(개략): RTSP → HLS(세그먼트). 운영 시 경로/세그/코덱/키프레임/재접속을 튜닝
ffmpeg -rtsp_transport tcp -i "rtsp://192.0.2.10:554/live" -c copy -f hls -hls_time 2 -hls_list_size 5 out.m3u8

• GOP/키프레임: HLS/라이브는 GOP(키프레임 주기) 를 세그와 맞추는 편이 안정(세그=2s면 2s GOP 등) — 아래 5절.

3.3 GStreamer: rtspsrc·(서버) rtsp-server

• rtspsrc location=rtsp://… protocols=tcp|udp+tcp 등으로 RTP depay 이후 decodebin/h264parse…
• gst-rtsp-server로 온프렘/엣지의 RTSP publishing(카메라→인코더/오버레이)도 가능(보안/인증/전송/세션정책 직접 구현이 필요).

# 예(개략, 환경에 따라 plug-in/버전이 다름)
gst-launch-1.0 rtspsrc location=rtsp://192.0.2.10:554/live latency=200 protocols=tcp ! rtph264depay ! h264parse ! decodebin ! autovideosink

• latency/buffer: rtspsrc 밀리초 계열 튜닝은 지터/손실에 큰 영향(아래 4·5절).

3.4 “라이브 스트리밍 파이프라인”(권장 아키텍처)

• 엣지(캠/NVR): RTSP unicast(내부망).
• 미디어 서버(필수에 가깝다면): 세션·리밸런싱·TLS 종단·HLS/LL-HLS/RTMP 인제스트·권한·썸넬·녹·오토스케일을 단일 FFMpeg 프로세스에 몰아넣지 않기(가용성/재시도/감독/메트릭).
• 클라우드/CDN(배포): HLS/LL-HLS(웹)와 WebRTC(저지연) 역할을 분리 — RTSP는 “내부/백홀/장비” 쪽, 인터넷 배포는 HLS(·WebRTC)로 이어짐(개념은 RTMP 글의 ingest-배포 시나리오와 닮습니다).

[ IP Cam (RTSP) ] --(내부망/방화벽)--> [ Media Server / NVR ]
       |                                 |
       |                                 +--> HLS / LL-HLS (CDN) --> Web/Apps
       |                                 +--> RTMP ingest --> Cloud Transcoder
       +--(옵션) NDI/SDI/HDMI(현장) ------> [ 생방 스위처 ]

3.5 24/7 DVR 녹화(요건·패턴)

• 파일롤(세그/일) , S.M.A.R.T., ZFS/RAID, 온라인/오프라인 휴지, 필요 시 암호/키관리(법규), 클락/타임 동기(녹화/법적/포렌식).
• “계속 open 한 TS/MP4” vs 세그(분할): 전원/IO 오류/복구 측면에서 세그+매니페스트·Rollover가 유리한 경우가 많습니다.
• 24/7은 실패의 연속이므로: FFmpeg/미디어 서버 재접속, 최대 캡(파일/디스크), 헬스체크(키프레임/비트/프레임 드롭), 알람(웹훅/Slack/메트릭).

# 예: 10분마다 MP4 roll (copy·운영에선 로그/재시도/권한/경로/디스크사전 점검)
ffmpeg -rtsp_transport tcp -i "rtsp://192.0.2.10:554/main" -c copy -f segment -segment_time 600 -reset_timestamps 1 "C:\\dvr\\seg_%04d.mp4"

---

4. 고급 주제: NAT·방화벽·QoS·손실·지터

4.1 NAT Traversal(현실)

• RTSP+RTP(UDP): SETUP에서 외부로 매핑된 포트·RTP/RTCP 쌍이 실제 NAT에서 열려 있어야 합니다(대칭 NAT·CGNAT에서 쉽지 않음).
• STUN/ICE(일반 WebRTC) 는 RTSP 1.0/카망과 1:1로 같이 쓰인다고 가정할 수 없습니다. 실전은 (a) TCP interleaved로 우회, (b) 사내/현장에서 Unicast+미디어 서버, (c) SRT/RTMP(s)/HLS+TLS·TURN(웹RTC) 별 루트.
• 포트 포워딩(초기 SOHO): 554+UDP RTP 범위를 카메라/NVR에 정확히(장비/펌웨어/동적포트) — 최소노출·TLS 중계/리버스 터널·ZTA가 바람직.

4.2 방화벽 이슈(체크리스트)

• RTSP(554/tcp), (UDP RTP는 다이내믹/장비), 관리(HTTP/ONVIF/HTTPS), NTP(시간), (옵션) SNMP/SSH.
• SSL 인스펙션/ALG: RTSP/RTSPoHTTP 끼어 인증/세션이 깨질 수 있음 — 예외/프로필 필요.
• mDNS/Bonjour·ONVIF Discovery(멀티캐스트): L3/무선/게스트 분리 시 검색만 안 됨(직접 IP로 OK).

4.3 QoS(서비스 품질)

• L2(802.1Q CoS) / L3(DSCP): EF/AF4x/CS4 등 마킹·우선·쉐이핑·쿼(큐). CCTV 망이 대량/상시이므로 VLAN 분리+대역캡+폴리싱이 마킹만큼이나 중요.
• “QoS=마킹” 아님: 엔드투엔드 병목(Wi‑Fi·VPN·xDSL 업링크·해외회선) 측정이 선행.
• UDP RTP: 손실은 애플리케이션(버퍼/PLC) 쪽 복구; 대역/혼잡은 쉐이퍼+코덱+프레임 제어(5절).

4.4 패킷 손실·아티팩트(체감)

• H.26x: I-frame 손실은 큰 깨짐/프리즈로 이어질 수 있음(IDR 주기/오류 은닉·FIR/PLI 등은 주로 WebRTC/부호화 쪽에서 논의 — RTSP 경로 전부가 지원한다고 볼 수 없음).
• 대응(실용): (1) TCP interleaved/재접속, (2) GOP/비트/해상 재조정, (3) 유선/스위치/전원, (4) NVR/라이브러리의 지터/디코더 설정.

4.5 Jitter Buffer(지터 버퍼)

• 수신(플레이어/디코더): 도착 간격을 흡수하는 큐(길이↑ → 지연↑, 안정↑ / 길이↓ → 반대).
• 라이브/보안/저지연의 충돌을 수치(목표 p95 지연, 얼리 드롭/프레임 스킵 허용 정책)로 합의.
• FFmpeg/플레이어/카메라는 각각 자체 버퍼가 중첩 — 끝단 단일 값이 아님(측정·로그·메트릭이 필요).

---

5. 최적화: 버퍼·GOP·대역·다중 스트림

5.1 버퍼(소켓/응용/라이브러리) 튜닝(원칙)

• “크게” = 항상 좋다는 아님(기억·지연). p95/손실/CPU·I/O·N개 세션을 동시에.
• RTSP TCP: 소켓 송/수신 버퍼(Recv/Snd) (OS)와 FFmpeg/미디어 서버 내부 큐(버전별 옵션).
• 라이브: -fflags +genpts 등 타임스탬프 보정은 VFR/불완전 TS에 유용(부작용도 있음 — 스펙/장비 케스 케이스 검증).

# 예(개략, 버전/환경 확인 필수)
ffmpeg -hide_banner -fflags +genpts -rtsp_transport tcp -i "rtsp://198.51.100.5:554/..." -c copy -f mpegts "out.ts"

5.2 GOP(키프레임 간격) / IDR(개념)

• GOP(짧게): 채널 전환/탐색/손실 복구는 나아질 수 있으나(IDR 자주) 인코딩 효율/대역은 불리(상대). 2초(라이브/HLS), 1초(저지연) 처럼 목표를 수치로.
• B-frame: 지연/비효율(라이브/저지연) 혼잡 이슈 — B=0(또는 낮은 계층) 프로필을 쓰는 방송/보안 옵션이 흔합니다.

5.3 대역폭 제어(캡/아답티브/정책)

• Constant/Peak 비트(카메라/VBR/CBR): VBR+저비트+저화질 대역은 쉽게 튀어 초과; VLAN QoS+캡+라우터/스위치 폴리싱 병행.
• 뷰/녹/분석(분리): 저화질 서브스트림(ONVIF/제조 옵션) + AI 분석 + HD 메인 역할 분리(CPU/GPU·디스크·업링크).
• 인터넷 uplink(비대칭): 업스트림 캡·2-pass 없는 라이브에서 CMAF/LL-HLS+ABR(배포) 쪽과 팀 — RTSP 내부에서 끝나지 않음.

5.4 다중 스트림(메인/서브/3번째) 관리

• NVR/웹/모바일/분석/디스플레이는 필요 화질이 다릅니다. 동일 4K@60을 모두에 쓰면 낭비+불안정입니다.
• 권한/경로/포트/계정을 스트림별/역할별로 분리(누설/브루트/오남용).
• 세션/CPU 측면만 동시 100채널+ 병은 GOP·코덱보다 세션/프록시/디코딩(하드웨어)·I/O가 먼저 터집니다(프로파일/메트릭으로 사전 측정).

---

6. 트러블슈팅(빈번) — “왜 흰 화면/녹음/늦음/끊김인가”

• 흰/검/깨짐(디코딩): SPS/PPS(또는 VPS/SPS) 주입/프리롤 I-frame 누락(특히 copy→TS), B-frame, VFR/타임스탬프 요인.
• TEARDOWN 누락/세션 누수: 서버(카망) 동접/포트/CPU 고갈 — 뷰어/릴레이 종료 시 정리.
• 끊김(10~30s 주기): 키프레임/세그/방화벽/idle/ISP CGNAT/재협상·NTP/드리프트·PSU/전력.
• 지연(수 초~수십 초): GOP+버퍼(HLS+플레이어+중계) 중첩 — 끝단 p95를 하나씩 줄이는 것이 정석.

---

7. 핵심 정리

• RFC 2326 / RFC 7826 — RTSP=제어(메서드+세션), RFC 3550/3551 — RTP/RTCP=미디어(타임+통계), RFC 8866 — SDP=디코딩/포트/제어 URL의 설계도가 한 세트로 움직입니다.
• IP 카메라/ONVIF/RTSP URL 은 표면적으로 표준이나 기종 의존이 강하므로 문서+캡처로 고정하십시오.
• FFmpeg/미디어 서버는 도구이고, 멀티 세션/재시도/권한/감독/스토리지/법규는 애플리케이션입니다.
• 성능(버퍼·GOP·대역)은 단일 “마법의 숫자”가 아닙니다. p95·드롭·I/O를 같이 봅니다.

배포: Cloudflare Pages에 반영하려면 저장소에 커밋·푸시한 뒤 npm run deploy를 실행하십시오(팀 규정에 맞는 파이프라인이 있다면 그 절차를 따릅니다).

참고(표준·문서)

• RFC 2326 — RTSP 1.0
• RFC 7826 — RTSP 2.0
• RFC 3550 — RTP/RTCP
• RFC 8866 — SDP
• ONVIF — profiles — 제품/도구/프로필(버전) 확인

---

자주 함께 읽는 글(내부)

• HLS(배포·LL-HLS): video-streaming-hls-complete-reference
• RTMP(인제스트·미디어 서버): video-streaming-rtmp-complete-reference
• DASH(표준 ABR·배포): video-streaming-dash-complete-reference

---

FAQ(보강)

• Q. SETUP이 여러 개인가요?
  A. 오디오/비디오 트랙, 멀티캐스트/유니캐스트, TCP/UDP 조합에 따라 미디어 단위SETUP가 나뉠 수 있습니다(클라이언트/서버/펌웨어 구현). Session 공유/분리를 로그로 보면 단서가 잡힙니다.
• Q. PTZ ONVIF 토큰을 어떻게 얻죠?
  A. GetCapabilities → GetProfiles → GetConfiguration(PTZ) … 등 ONVIF 서비스 경로(프로필/장비)로 ProfileToken을 취득합니다(도구/라이브러리가 요약해주기도 함). RTSP URL과 혼동하지 마십시오.