위키백과

실시간 스트리밍 프로토콜

스트리밍 미디어 서버를 제어할 목적으로 개발된 네트워크 제어 프로토콜
(RTSP에서 넘어옴)

실시간 스트리밍 프로토콜(Real Time Streaming Protocol, RTSP)은 스트리밍 미디어 서버를 제어할 목적으로 엔터테인먼트, 통신 시스템에 사용하도록 설계된 네트워크 제어 프로토콜이다. 이 프로토콜은 종단점(end point)들 간에 미디어 세션을 확립하고 제어하기 위해 사용된다. 미디어 서버의 클라이언트들은 play, record, pause 등 VHS 스타일의 명령을 발행하여 서버→클라이언트(주문형 비디오/VOD) 또는 클라이언트→서버(녹음)의 실시간 미디어 스트리밍 제어를 용이하게 만들어준다.

스트리밍 데이터 전송 그 자체는 RTSP의 역할이 아니다. 대부분의 RTSP 서버들은 미디어 스트림 전달을 위해 RTCP와 결합한 실시간 전송 프로토콜(RTP)를 사용한다. 그러나 일부 벤더들은 사유 전송 프로토콜을 구현해놓고 있다. 예를 들어 리얼네트웍스의 RTSP 서버 소프트웨어는 리얼네트웍스의 사유 리얼 데이터 트랜스포트(RDT)를 사용하였다.

RTSP는 리얼네트웍스, 넷스케이프[1], 컬럼비아 대학교에 의해 개발되었으며 최초 초안은 1996년 IETF에 제출되었다.[2] IETF의 MMUSIC WG(Multiparty Multimedia Session Control Working Group)에 의해 표준화되었으며 1998년 "RFC 2326"으로 출판되었다.[3] RTSP 1.0을 대체하는 RTSP 2.0이 "RFC 7826"의 이름으로 2016년 출판되었으나 이 버전은 기본 버전 협상(negotiation) 매커니즘 외에는 하위 호환이 되지 않는다.

RTSP 명령어

편집

RTSP 규약은 HTTP 규약과 비교해 볼 때, 문법이나 동작이 비슷한 면이 있으나 RTSP는 멀티미디어 재생을 제어하는데 유용한 컨트롤 시퀀스를 정의한다는 점에서 차이가 있다. 그 밖의 차이점을 들자면, HTTP가 무상태형(stateless)인 반면에 RTSP는 상태형(stateful)이라는 점이다. 즉, 병행 세션을 추적하기 위해 식별자를 사용하게 되는데, HTTP처럼 RTSP는 TCP를 사용하여 단대단(end-to-end) 연결을 유지하는 반면 대부분의 RTSP 제어 메시지들은 클라이언트에서 서버로 전달되며 일부 명령들은 그 밖의 방향으로 전달된다.(예: 서버→클라이언트)

아래에 제시된 것들은 기본적인 RTSP 요청들이다. OPTIONS 요청과 같은 일부 일반 HTTP 요청 또한 사용할 수 있다. 기본 전송 계층 포트 번호는 554번이며[3] TCP와 UDP에 둘 다 사용되며 후자의 경우 전송 요청에 사용되는 일은 드문 편이다.

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 요청에는 RTSP URL (rtsp://...) 및 관리 가능한 응답 데이터의 유형이 포함된다. 이 응답은 보통 세션 기술 프로토콜(SDP) 포맷으로 되어 있으며 프레젠테이션 설명이 포함된다. 그 중에 애그리게이트(aggregate) URL로 제어되는 미디어 스트림들이 나열된다. 일반적인 경우 오디오 스트림과 비디오 스트림을 위한 각각의 하나의 미디어 스트림이 존재한다. 미디어 스트림 URL은 SDP 컨트롤 필드로부터 직접 취득되거나 SDP 컨트롤 필드를 애그리게이트 URL 뒤에 추가하는 방식으로 취득된다.
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 요청은 단일 미디어 스트림이 어떻게 전송되어야 하는지를 규정한다. 이 요청이 수행된 뒤에야 (다음에 언급되는) PLAY 요청을 전달할 수 있다. 이 요청에는 미디어 스트림 URL과 전송 지시자를 포함한다. 이 지시자에는 보통 RTP 데이터(오디오 또는 비디오), 그리고 RTCP 데이터(메타 정보)를 위한 데이터를 수신하기 위한 로컬 포트가 포함되어 있다. 서버 응답은 보통 정해진 변수를 확인하는 일을 하며, 서버가 선정한 포트 등 존재하지 않는 부분에 내용을 채운다. 각 미디어 스트림은 SETUP을 이용하여 구성을 마쳐야 애그리게이트 플레이 요청 전송을 수행할 수 있다.
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 요청은 1개 또는 모든 미디어 스트림을 재생한다. 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 요청과 함께 나중에 이어서 재생할 수 있다. 이 요청에는 애그리게이트 URL 또는 미디어 스트림 URL이 포함된다. PAUSE 요청에 range(범위) 변수를 사용하여 일시 중지의 시점을 지정할 수 있다. 해당 범위 변수를 제외할 경우 즉시 무기한으로 일시 중지된다.
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
RECORD
이 메소드는 프레젠테이션 설명에 따라 일련의 미디어 데이터를 녹화한다. 타임스탬프는 시작 시간/종료 시간(UTC)을 반영한다. 시간 범위를 지정하지 않으면 프레젠테이션 설명에 지정된 시작 또는 종료 시간을 사용하게 된다. 세션이 이미 시작된 경우 녹화는 즉시 시작된다. 서버는 요청 URI 또는 기타 URI를 통해 녹화된 데이터의 저장 여부를 결정한다. 서버가 요청 URI를 사용하지 않는 경우 응답은 201 처리되며 요청 상태를 기술하고 새로운 자원을 참조하는 엔티티, 그리고 Location 헤더를 포함하게 된다.
C->S: RECORD rtsp://example.com/media.mp4 RTSP/1.0
      CSeq: 6
      Session: 12345678

S->C: RTSP/1.0 200 OK
      CSeq: 6
      Session: 12345678
ANNOUNCE
ANNOUNCE 메소드는 2가지 목적이 있다:
클라이언트→서버 전송의 경우 ANNOUNCE는 서버에 대한 요청 URL에 의해 식별되는 프레젠테이션 또는 미디어 오브젝트의 설명을 게시한다. 서버→클라이언트 전송의 경우 ANNOUNCE는 실시간으로 세션 설명을 업데이트한다. 새로운 미디어 스트림이 프레젠테이션으로 추가되는 경우(예: 실시간 프레젠테이션) 컴퍼넌트를 추가로 보내지 않고 프레젠테이션 설명 전체를 다시 보낸다.
C->S: ANNOUNCE rtsp://example.com/media.mp4 RTSP/1.0
      CSeq: 7
      Date: 23 Jan 1997 15:35:06 GMT
      Session: 12345678
      Content-Type: application/sdp
      Content-Length: 332

      v=0
      o=mhandley 2890844526 2890845468 IN IP4 126.16.64.4
      s=SDP Seminar
      i=A Seminar on the session description protocol
      u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps
      e=mjh@isi.edu (Mark Handley)
      c=IN IP4 224.2.17.12/127
      t=2873397496 2873404696
      a=recvonly
      m=audio 3456 RTP/AVP 0
      m=video 2232 RTP/AVP 31

S->C: RTSP/1.0 200 OK
      CSeq: 7
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
GET_PARAMETER
GET_PARAMETER 요청은 URI에 지정된 프레젠테이션 또는 스트림의 변수값을 가져온다. 응답 내용은 구현체에 남는다. 클라이언트나 서버가 살아있는지(ping) 테스트하기 위해 엔티티 본문 없이 GET_PARAMETER을 사용할 수 있다.
S->C: GET_PARAMETER rtsp://example.com/media.mp4 RTSP/1.0
      CSeq: 9
      Content-Type: text/parameters
      Session: 12345678
      Content-Length: 15

      packets_received
      jitter

C->S: RTSP/1.0 200 OK
      CSeq: 9
      Content-Length: 46
      Content-Type: text/parameters

      packets_received: 10
      jitter: 0.3838
SET_PARAMETER
이 메소드는 URI에 지정된 프레젠테이션 또는 스트림의 변수값의 설정을 요청한다.
C->S: SET_PARAMETER rtsp://example.com/media.mp4 RTSP/1.0
      CSeq: 10
      Content-length: 20
      Content-type: text/parameters

      barparam: barstuff

S->C: RTSP/1.0 451 Invalid Parameter
      CSeq: 10
      Content-length: 10
      Content-type: text/parameters

      barparam
REDIRECT
REDIRECT 요청은 다른 서버 위치로 연결해야 한다고 클라이언트에 알릴 것을 요청한다. 클라이언트가 해당 URL에 대해 요청을 발행하는 것을 지시하는 필수 헤더 Location이 포함된다. 리다이렉션 발생 시 지시하는 Range 변수를 포함할 수 있다. 클라이언트가 이 URI의 미디어 송수신을 계속하려면 클라이언트는 현재 세션에 대해 TEARDOWN 요청을 발행하고 지정된 호스트의 새로운 세션에 대해 SETUP을 발행해야 한다.
S->C: REDIRECT rtsp://example.com/media.mp4 RTSP/1.0
      CSeq: 11
      Location: rtsp://bigserver.com:8001
      Range: clock=19960213T143205Z-
임베디드(인터리빙) 바이너리 데이터
특정 방화벽 설계나 기타 환경 문제로 인해 서버가 RTSP 스트림을 인터리빙하고 데이터를 스트리밍하는 일이 생길 수 있다. 이러한 인터리빙은 클라이언트와 서버 조작을 복잡하게 만들고 추가적인 부하를 발생시키기 때문에 삼가는 것이 좋다. 인터리빙된 바이너리 데이터는 RTSP가 TCP를 통해 전달되는 경우에 한해서만 사용하는 것이 좋다.
C->S: SETUP rtsp://example.com/media.mp4 RTSP/1.0
      CSeq: 3
      Transport: RTP/AVP/TCP;interleaved=0-1

S->C: RTSP/1.0 200 OK
      CSeq: 3
      Date: 05 Jun 1997 18:57:18 GMT
      Transport: RTP/AVP/TCP;interleaved=0-1
      Session: 12345678

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

S->C: RTSP/1.0 200 OK
      CSeq: 4
      Session: 12345678
      Date: 05 Jun 1997 18:59:15 GMT
      RTP-Info: url=rtsp://example.com/media.mp4;seq=232433;rtptime=972948234

S->C: $\000{2 byte length}{"length" bytes data, w/RTP header}
S->C: $\000{2 byte length}{"length" bytes data, w/RTP header}
S->C: $\001{2 byte length}{"length" bytes  RTCP packet}

속도 적응

편집

RTP, RTCP를 사용하는 RTSP는 속도 적응(순응) 구현체를 허용한다.[4]

구현체

편집

서버

편집

IP 카메라로 불리는 수많은 CCTV / 감시 카메라들(특히 ONVIF 프로파일 G, S, T를 제공하는 카메라들)은 RTSP 스트리밍을 지원한다.

클라이언트

편집

같이 보기

편집

각주

편집
  1. ↑ InfoWorld Media Group, Inc. (1998년 3월 2일). 《InfoWorld》. InfoWorld Media Group, Inc. 18쪽. ISSN 0199-6649. 
  2. ↑ Rafael Osso (1999). 《Handbook of Emerging Communications Technologies: The Next Decade》. CRC Press. 42쪽. ISBN 978-1-4200-4962-6. 
  3. ↑ 가 나 RFC 2326, Real Time Streaming Protocol (RTSP), IETF, 1998
  4. ↑ Santos, Hugo; Cruz, Rui Santos; Nunes, Mário Serafim (2010), 〈Rate Adaptation Techniques for WebTV〉, 《Rate Adaption Techniques for WebTV》, Lecture Notes of the Institute for Computer Sciences, Social Informatics and Telecommunications Engineering 40, 161–168쪽, doi:10.1007/978-3-642-12630-7_19, ISBN 978-3-642-12629-1 
  5. ↑ erlyvideo website
  6. ↑ cURL — Changes
  7. ↑ “FFmpeg Documentation”. The FFmpeg project. 2012년 9월 11일. Section 20.19. 2012년 9월 11일에 확인함. 

외부 링크

편집
  • RTSP.org RTSP 정보 집체 사이트
  • RFC 2326, Real Time Streaming Protocol (RTSP).
  • RFC 3550, RTP: A Transport Protocol for Real-Time Applications.
원본 주소 "https://ko.wiki.x.io/w/index.php?title=실시간_스트리밍_프로토콜&oldid=32002614"