실시간 스트리밍을 위한 RTSP 프로토콜

LTT·2024년 11월 27일

RTSP에 대해 처음 알아보는 만큼, 너무 헷갈리는 부분은 그렇구나 하며 넘어가기로 마음먹었다.

RTSP란 무엇인가


RTSP의 정의

실시간 스트리밍 프로토콜(Real Time Streaming Protocol, RTSP)은 스트리밍 미디어 서버를 제어할 목적으로 엔터테인먼트, 통신 시스템에 사용하도록 설계된 네트워크 제어 프로토콜이다.

RTSP가 필요한 이유

RTSP는 멀티미디어 콘텐츠를 스트리밍하면서 재생, 일시정지, 중지 등과 같은 제어 기능을 제공한다.

HTTP와 달리 양방향 통신을 통해 실시간 상호작용을 지원하며, 라이브 스트리밍, 보안 카메라, CCTV, 비디오 서버 등에 적합하며,

현재는 아무래도 범용성이 높은 hls프로토콜을 스트리밍에 많이 사용하는 것 같지만, 위에서 언급했듯 여전히 IP 카메라에서 사용하는 프로토콜이기에 무시할 수 없다.

기존의 라이브 스트리밍 프로토콜로 많이 쓰이던 것으로, RTMP(Real-Time Messaging Protocol)과 함께 많이 사용되었다.

스트리밍 프로토콜의 기본 개념

RTSP제어 프로토콜로, 실제 데이터를 전송하는 RTP(Real-time Transport Protocol)와 함께 작동한다.

주요 스트리밍 프로토콜과의 차이점은 다음과 같다.

  • RTMP : 비디오 플랫폼(Facebook, YouTube)과의 통합에 사용.
  • HLS : HTTP 기반이며, 주로 비디오 온디맨드(VOD)에서 사용.
  • HTTP : 다운로드에 최적화되어 있어 실시간 스트리밍에는 비효율적.

RTSP의 작동 원리


클라이언트-서버 통신 모델

RTSP는 클라이언트와 서버 간 통신을 통해 스트림 제어 명령을 주고받는다.

클라이언트는 서버에 명령을 보내고, 서버는 요청을 처리하며 멀티미디어 스트림을 제공하거나 상태를 업데이트한다.

주요 명령어

  • OPTIONS: 서버의 기능 확인
  • DESCRIBE: 스트리밍 콘텐츠의 메타데이터 요청
  • SETUP: 스트리밍을 위한 세션 파라메터 생성
  • PLAY: 스트림 재생 시작
  • PAUSE: 재생 중지(일시정지)
  • TEARDOWN: 스트림 종료

OPTIONS

OPTIONS 요청은 서버가 수락할 요청 타입(기능)을 반환한다.

C->S:  OPTIONS rtsp://example.com/media.mp4 RTSP/1.0
       CSeq: 1
       Require: implicit-play
       Proxy-Require: gzipped-messages

S->C:  RTSP/1.0 200 OK
       CSeq: 1
       Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE

DESCRIBE

DESCRIBE 요청에는 스트리밍할 컨텐츠의 메타데이터를 응답받는다. 이 응답들은 보통 SDP(Session Description Protocol)의 포맷으로 되어 있다고 한다.

C->S: DESCRIBE rtsp://example.com/media.mp4 RTSP/1.0
      CSeq: 2

S->C: RTSP/1.0 200 OK
      CSeq: 2
      Content-Base: rtsp://example.com/media.mp4
      Content-Type: application/sdp
      Content-Length: 460

      m=video 0 RTP/AVP 96
      a=control:streamid=0
      a=range:npt=0-7.741000
      a=length:npt=7.741000
      a=rtpmap:96 MP4V-ES/5544
      a=mimetype:string;"video/MP4V-ES"
      a=AvgBitRate:integer;304018
      a=StreamName:string;"hinted video track"
      m=audio 0 RTP/AVP 97
      a=control:streamid=1
      a=range:npt=0-7.712000
      a=length:npt=7.712000
      a=rtpmap:97 mpeg4-generic/32000/2
      a=mimetype:string;"audio/mpeg4-generic"
      a=AvgBitRate:integer;65790
      a=StreamName:string;"hinted audio track"

SETUP

SETUP 요청은 단일 미디어 스트림이 어떻게 전송되어야 하는지를 규정한다. 즉, 이 SETUP이 수행되어야, 다음에 오는 PLAY요청을 전달할 수 있다. 이 요청에는 연결을 위한 파라메터들을 세팅하는 요청이라고 이해했다.

C->S: SETUP rtsp://example.com/media.mp4/streamid=0 RTSP/1.0
      CSeq: 3
      Transport: RTP/AVP;unicast;client_port=8000-8001

S->C: RTSP/1.0 200 OK
      CSeq: 3
      Transport: RTP/AVP;unicast;client_port=8000-8001;server_port=9000-9001;ssrc=1234ABCD
      Session: 12345678

C->S: SETUP rtsp://example.com/media.mp4/streamid=1 RTSP/1.0
      CSeq: 3
      Transport: RTP/AVP;unicast;client_port=8002-8003
      Session: 12345678

S->C: RTSP/1.0 200 OK
      CSeq: 3
      Transport: RTP/AVP;unicast;client_port=8002-8003;server_port=9002-9003;ssrc=1234ABCD
      Session: 12345678

PLAY

PLAY 요청은 미디어 스트림을 재생하는 요청이다. 여러 번 보내면 재생 요청들을 쌓아두고 처리할 수도 있고, URL은 애그리게이트 URL(모든 미디어 스트림들을 재생) 또는 하나의 미디어 스트림 URL(해당 스트림에 한해서만 재생)로 구성이 가능하다.

C->S: PLAY rtsp://example.com/media.mp4 RTSP/1.0
      CSeq: 4
      Range: npt=5-20
      Session: 12345678

S->C: RTSP/1.0 200 OK
      CSeq: 4
      Session: 12345678
      RTP-Info: url=rtsp://example.com/media.mp4/streamid=0;seq=9810092;rtptime=3450012

PAUSE

PAUSE 요청은 1개 또는 모든 미디어 스트림을 일시중지한다. 그러므로 PLAY 요청과 함께 나중에 이어서 재생할 수 있다.

C->S: PAUSE rtsp://example.com/media.mp4 RTSP/1.0
      CSeq: 5
      Session: 12345678

S->C: RTSP/1.0 200 OK
      CSeq: 5
      Session: 12345678

TEARDOWN

TEARDOWN 요청은 세션 종료를 위해 사용된다.

C->S: TEARDOWN rtsp://example.com/media.mp4 RTSP/1.0
      CSeq: 8
      Session: 12345678

S->C: RTSP/1.0 200 OK
      CSeq: 8

이외의 요청은 아래에서 확인 바란다

https://ko.wikipedia.org/wiki/%EC%8B%A4%EC%8B%9C%EA%B0%84_%EC%8A%A4%ED%8A%B8%EB%A6%AC%EB%B0%8D_%ED%94%84%EB%A1%9C%ED%86%A0%EC%BD%9C

세션 개념과 상태 유지

RTSP는 세션 기반 프로토콜이다.

클라이언트는 SETUP 명령으로 세션을 시작하고, 이 세션을 통해 스트리밍 상태를 관리하기 때문에, 세션 ID를 통해 클라이언트와 서버가 서로를 식별하고 상태를 동기화한다.

RTSP의 특징


RTSP의 이점

  • 실시간 스트리밍 지원: 지연 시간이 적어 라이브 스트리밍에 적합.
  • 유연한 제어: 스트림의 재생, 정지, 탐색 제어 가능.
  • 다중 클라이언트 지원: 한 서버에서 여러 클라이언트에 스트림 제공 가능.

RTSP와 RTP/RTCP의 연계

RTSP는 제어 명령을 처리하며, 실제 데이터는 RTP를 통해 전송됩니다.

  • RTP(Real-time Transport Protocol): 미디어 데이터를 전송.
    • RTP 는 실시간 데이터 전송에 적합한 프로토콜로, 오디오와 비디오 데이터를 IP 네트워크를 통해 전송할 때 사용된다.
    • RTPUDP를 사용하므로 실시간성이 중요한 경우에 적합하다.
  • RTCP(Real-time Transport Control Protocol): 품질 관리(QoS, Quality of Service) 및 피드백 제공.
    • RTCPRTP 세션에 대한 통계 정보와 피드백을 주고받으며, 네트워크 상태와 전송 품질을 모니터링하고 개선하는 데 도움을 준다.

RTSP 스트리밍의 구성 요소


클라이언트와 서버 역할

  • 서버: 멀티미디어 데이터를 저장하고 스트림으로 제공.
  • 클라이언트: 스트림을 수신하고 사용자 입력 처리.

미디어 콘텐츠 전달 과정

  1. 클라이언트가 서버에 DESCRIBE 요청을 보냄.
  2. 서버는 스트림 메타데이터(SDP) 응답.
  3. 클라이언트가 SETUP으로 스트림을 준비.
  4. PLAY 명령으로 스트리밍 시작.

네트워크 및 RTP 전송 방법

RTP over UDP

  • UDP를 통한 RTP는 UDP를 저수준 전송 프로토콜로 사용한다.
  • UDP는 전송된 패킷이 올바르게 도착한다고 보장하지 않는다.
  • UDP의 가장 큰 단점은 방화벽과 라우터 제한으로 인해 인터넷과 같은 이기종 네트워크를 통해 전송하는 것이 종종 불가능하다는 사실이다.
  • RTP over UDP로 패킷 전달 시 UDP는 항상 최소 2개의 채널을 설정.

RTP over TCP

  • RTP는 TCP를 통해서도 전송될 수 있다.
  • RTSP SETUP 요청에서 클라이언트에 의해 TCP 방식으로 선택되면 스트리머는 RTSP 통신을 위해 이미 설정된 TCP 연결을 통해 RTP 패킷을 보낸다.
  • TCP 전송은 UDP와 비교하여 프로토콜에 약간의 오버헤드가 있다.
  • TCP는 신뢰할 수 있는 전송 프로토콜이며, 데이터가 클라이언트에 도착하도록 보장한다.
  • TCP는 RTSP(제어)와 RTP(미디어) 모두 하나의 채널만 사용한다.

멋대로 내리는 결론


아직 RTSP에 대해 제대로 알아보지 못한 것 같다. 직접 RTSP를 사용한 스트림 환경을 만들어보고 싶기도 하고, 이를 활용한 데이터 처리에 대해 공부해보고 싶다.

HLS에 비해 호환성 측면에서 부족한 감이 있지만, CCTV같은 IP카메라를 사용하는 분야에서는 확실히 RTSP가 더 효과적인 처리를 할 수 있겠다는 판단이 된다.

참고 링크


등등… 많지만 이것저것 뒤져보느라 다 기록하지 못했다.

profile
개발자에서 엔지니어로, 엔지니어에서 리더로

0개의 댓글