'''실시간 스트리밍 프로토콜'''(, '''RTSP''')은 스트리밍 미디어 서버를 제어할 목적으로 엔터테인먼트, 통신 시스템에 사용하도록 설계된 네트워크 제어 프로토콜이다. 프로토콜은 종단점(end point)들 간에 미디어 세션을 확립하고 제어하기 위해 사용된다. 미디어 서버의 클라이언트들은 play, record, pause VHS 스타일의 명령을 발행하여 서버→클라이언트(주문형 비디오/VOD) 또는 클라이언트→서버(녹음)의 실시간 미디어 스트리밍 제어를 용이하게 만들어준다. 스트리밍 데이터 전송 자체는 RTSP의 역할이 아니다. 대부분의 RTSP 서버들은 미디어 스트림 전달을 위해 RTCP와 결합한 실시간 전송 프로토콜(RTP)를 사용한다. 그러나 일부 벤더들은 사유 전송 프로토콜을 구현해놓고 있다. 예를 들어 리얼네트웍스의 RTSP 서버 소프트웨어는 리얼네트웍스의 사유 리얼 데이터 트랜스포트(RDT)를 사용하였다. RTSP는 리얼네트웍스, 넷스케이프, 컬럼비아 대학교에 의해 개발되었으며 최초 초안은 1996년 IETF에 제출되었다. IETF의 MMUSIC WG(Multiparty Multimedia Session Control Working Group)에 의해 표준화되었으며 1998년 "RFC 2326"으로 출판되었다. RTSP 1.0을 대체하는 RTSP 2.0이 "RFC 7826"의 이름으로 2016년 출판되었으나 버전은 기본 버전 협상(negotiation) 매커니즘 외에는 하위 호환이 되지 않는다. == RTSP 명령어 == RTSP 규약은 HTTP 규약과 비교해 때, 문법이나 동작이 비슷한 면이 있으나 RTSP는 멀티미디어 재생을 제어하는데 유용한 컨트롤 시퀀스를 정의한다는 점에서 차이가 있다. 밖의 차이점을 들자면, HTTP가 반면에 RTSP는 점이다. 즉, 병행 세션을 추적하기 위해 식별자를 사용하게 되는데, HTTP처럼 RTSP는 TCP를 사용하여 단대단(end-to-end) 연결을 유지하는 반면 대부분의 RTSP 제어 메시지들은 클라이언트에서 서버로 전달되며 일부 명령들은 밖의 방향으로 전달된다.(예: 서버→클라이언트) 아래에 제시된 것들은 기본적인 RTSP 요청들이다. OPTIONS 요청과 같은 일부 일반 HTTP 요청 또한 사용할 있다. 기본 전송 계층 포트 번호는 554번이며 TCP와 UDP에 사용되며 후자의 경우 전송 요청에 사용되는 일은 드문 편이다. OPTIONS OPTIONS 요청은 서버가 수락할 요청 타입을 반환한다. C->S: OPTIONS RTSP/1.0 CSeq: Require: implicit-play Proxy-Require: S->C: RTSP/1.0 200 OK CSeq: Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE DESCRIBE DESCRIBE 요청에는 RTSP URL 관리 가능한 응답 데이터의 유형이 포함된다. 응답은 보통 세션 기술 프로토콜(SDP) 포맷으로 되어 있으며 프레젠테이션 설명이 포함된다. 중에 URL로 제어되는 미디어 스트림들이 나열된다. 일반적인 경우 오디오 스트림과 비디오 스트림을 위한 각각의 하나의 미디어 스트림이 존재한다. 미디어 스트림 URL은 SDP 컨트롤 필드로부터 직접 취득되거나 SDP 컨트롤 필드를 애그리게이트 URL 뒤에 추가하는 방식으로 취득된다. C->S: DESCRIBE RTSP/1.0 CSeq: S->C: RTSP/1.0 200 OK CSeq: Content-Base: Content-Type: application/sdp Content-Length: 460 m=video RTP/AVP 96 a=rtpmap:96 MP4V-ES/5544 video track" m=audio RTP/AVP 97 a=rtpmap:97 audio track" SETUP SETUP 요청은 단일 미디어 스트림이 어떻게 전송되어야 하는지를 규정한다. 요청이 수행된 뒤에야 (다음에 언급되는) PLAY 요청을 전달할 있다. 요청에는 미디어 스트림 URL과 전송 지시자를 포함한다. 지시자에는 보통 RTP 데이터(오디오 또는 비디오), 그리고 RTCP 데이터(메타 정보)를 위한 데이터를 수신하기 위한 로컬 포트가 포함되어 있다. 서버 응답은 보통 정해진 변수를 확인하는 일을 하며, 서버가 선정한 포트 존재하지 않는 부분에 내용을 채운다. 미디어 스트림은 SETUP을 이용하여 구성을 마쳐야 애그리게이트 플레이 요청 전송을 수행할 있다. C->S: SETUP RTSP/1.0 CSeq: Transport: S->C: RTSP/1.0 200 OK CSeq: Transport: Session: 12345678 C->S: SETUP RTSP/1.0 CSeq: Transport: Session: 12345678 S->C: RTSP/1.0 200 OK CSeq: Transport: Session: 12345678 PLAY PLAY 요청은 1개 또는 모든 미디어 스트림을 재생한다. PLAY 요청을 여러 보내면 재생 요청들을 복수로 쌓아두고 처리할 있다. URL은 애그리게이트 URL(모든 미디어 스트림들을 재생) 또는 하나의 미디어 스트림 URL(해당 스트림에 한해서만 재생)로 구성이 가능하다. 재생 범위를 지정할 있다. 범위를 지정하지 않으면 스트림은 처음부터 끝까지 재생되며 스트림이 일시 중지된 상황이라면 일시 중지된 지점부터 이어서 재생된다. C->S: PLAY RTSP/1.0 CSeq: Range: npt=5-20 Session: 12345678 S->C: RTSP/1.0 200 OK CSeq: Session: 12345678 RTP-Info: PAUSE PAUSE 요청은 1개 또는 모든 미디어 스트림을 일시적으로 중지한다. 그러므로 PLAY 요청과 함께 나중에 이어서 재생할 있다. 요청에는 애그리게이트 URL 또는 미디어 스트림 URL이 포함된다. PAUSE 요청에 range(범위) 변수를 사용하여 일시 중지의 시점을 지정할 있다. 해당 범위 변수를 제외할 경우 즉시 무기한으로 일시 중지된다. C->S: PAUSE RTSP/1.0 CSeq: Session: 12345678 S->C: RTSP/1.0 200 OK CSeq: Session: 12345678 RECORD 메소드는 프레젠테이션 설명에 따라 일련의 미디어 데이터를 녹화한다. 타임스탬프는 시작 시간/종료 시간(UTC)을 반영한다. 시간 범위를 지정하지 않으면 프레젠테이션 설명에 지정된 시작 또는 종료 시간을 사용하게 된다. 세션이 이미 시작된 경우 녹화는 즉시 시작된다. 서버는 요청 URI 또는 기타 URI를 통해 녹화된 데이터의 저장 여부를 결정한다. 서버가 요청 URI를 사용하지 않는 경우 응답은 201 처리되며 요청 상태를 기술하고 새로운 자원을 참조하는 엔티티, 그리고 Location 헤더를 포함하게 된다. C->S: RECORD RTSP/1.0 CSeq: Session: 12345678 S->C: RTSP/1.0 200 OK CSeq: Session: 12345678 ANNOUNCE ANNOUNCE 메소드는 2가지 목적이 있다: 클라이언트→서버 전송의 경우 ANNOUNCE는 서버에 대한 요청 URL에 의해 식별되는 프레젠테이션 또는 미디어 오브젝트의 설명을 게시한다. 서버→클라이언트 전송의 경우 ANNOUNCE는 실시간으로 세션 설명을 업데이트한다. 새로운 미디어 스트림이 프레젠테이션으로 추가되는 경우(예: 실시간 프레젠테이션) 컴퍼넌트를 추가로 보내지 않고 프레젠테이션 설명 전체를 다시 보낸다. C->S: ANNOUNCE RTSP/1.0 CSeq: 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 e=mjh@isi.edu (Mark Handley) c=IN IP4 224.2.17.12/127 t=2873397496 2873404696 a=recvonly m=audio 3456 RTP/AVP m=video 2232 RTP/AVP 31 S->C: RTSP/1.0 200 OK CSeq: TEARDOWN TEARDOWN 요청은 세션 종료를 위해 사용된다. 모든 미디어 스트림을 정지시키고 서버 상의 모든 세션 관련 데이터의 할당을 해제한다. C->S: TEARDOWN RTSP/1.0 CSeq: Session: 12345678 S->C: RTSP/1.0 200 OK CSeq: GET_PARAMETER GET_PARAMETER 요청은 URI에 지정된 프레젠테이션 또는 스트림의 변수값을 가져온다. 응답 내용은 구현체에 남는다. 클라이언트나 서버가 살아있는지(ping) 테스트하기 위해 엔티티 본문 없이 GET_PARAMETER을 사용할 있다. S->C: GET_PARAMETER RTSP/1.0 CSeq: Content-Type: text/parameters Session: 12345678 Content-Length: 15 jitter C->S: RTSP/1.0 200 OK CSeq: Content-Length: 46 Content-Type: text/parameters 10 jitter: 0.3838 SET_PARAMETER 메소드는 URI에 지정된 프레젠테이션 또는 스트림의 변수값의 설정을 요청한다. C->S: SET_PARAMETER 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/1.0 CSeq: 11 Location: Range: 임베디드(인터리빙) 바이너리 데이터 특정 방화벽 설계나 기타 환경 문제로 인해 서버가 RTSP 스트림을 인터리빙하고 데이터를 스트리밍하는 일이 생길 있다. 이러한 인터리빙은 클라이언트와 서버 조작을 복잡하게 만들고 추가적인 부하를 발생시키기 때문에 삼가는 것이 좋다. 인터리빙된 바이너리 데이터는 RTSP가 TCP를 통해 전달되는 경우에 한해서만 사용하는 것이 좋다. C->S: SETUP RTSP/1.0 CSeq: Transport: S->C: RTSP/1.0 200 OK CSeq: Date: 05 Jun 1997 18:57:18 GMT Transport: Session: 12345678 C->S: PLAY RTSP/1.0 CSeq: Session: 12345678 S->C: RTSP/1.0 200 OK CSeq: Session: 12345678 Date: 05 Jun 1997 18:59:15 GMT RTP-Info: S->C: $\000{2 byte bytes data, w/RTP header} S->C: $\000{2 byte bytes data, w/RTP header} S->C: $\001{2 byte bytes RTCP packet} == 속도 적응 == RTP, RTCP를 사용하는 RTSP는 속도 적응(순응) 구현체를 허용한다. == 구현체 == === 서버 === 다윈 스트리밍 서버(Darwin Streaming Server): 오픈 소스 버전의 퀵타임 스트리밍 서버 (애플이 관리) Erlyvideo: RTSP 클라이언트가 있으며 다른 프로토콜로 비디오를 재스트리밍할 있다. Feng: rfc 준수에 초점을 스트리밍 서버. GStreamer 기반 RTSP 서버 클라이언트. Helix DNA Server: 리얼네트웍스의 스트리밍 서버. 오픈 소스 사유 버전이 모두 존재한다. Helix Universal Server: RTSP, RTMP, iOS, 실버라이트, HTTP 스트리밍 미디어 클라이언트를 위한 리얼네트웍스의 상용 스트리밍 서버. LEAD 테크놀로지스의 LEADTOOLS 미디어 스트리밍 서버 SDK: RTSP/RTP, RTSP/RTP (MPEG-2 Transport), RTSP/RTP over HTTP 지원. LIVE555 라이브미디어 openRTSP: VLC와 엠플레이어 알려진 클라이언트에 사용되는 오픈 소스 C++ 서버 클라이언트 라이브러리. Managed Media Aggregation .NET C# RFC 준수 RTSP 구현체. 님블 스트리머(Nimble Streamer): TCP 인터리빙 재생 출력과 함께 RTSP pull announce 입력 지원. pvServer: 과거 이름은 PacketVideo Streaming Server. 알카텔-루센트의 스트리밍 서버 제품. 퀵타임 스트리밍 서버(QuickTime Streaming Server): OS 서버에 기본 포함되는 애플의 클로즈드 소스 스트리밍 서버. SharpRTSP: RTSP 클라이언트, RTSP 서버를 빌드하고 RTP 데이터 스트림을 관리하기 위한 오픈 소스 C# RTSP 라이브러리. TV 서버(TV Server): RTSP/RTP, HTTP, HTTPS (HLS, MSS, MPEG-DASH)용 멀티 포맷 스트리밍 서버. Edgeware의 스트리밍 서버 제품. (소프트웨어, 하드웨어 버전) ViaMotion: Anevia의 주문형 비디오(VOD)용 내장 RTSP 서버 VideoLAN: 오픈 소스 미디어 플레이어 스트리밍 서버 VX30: Maui X-Stream의 스트리밍 비디오 서버 임베디드 자바 클라이언트. 윈도우 미디어 서비스(Windows Media Services): 윈도우 미디어 확장 기능과 함께 수정된 RTSP를 사용하는, 과거에 윈도우 서버에 포함된 마이크로소프트의 스트리밍 서버 Wowza Streaming Engine: RTSP/RTP, RTMP, MPEG-TS, ICY, HTTP (HTTP 라이브 스트리밍, HTTP 동적 스트리밍, 스무스 스트리밍, MPEG-DASH), WebRTC용 멀티 포맷 스트리밍 서버 제논 스트리밍 서버(Xenon Streaming Server): Vidiator 테크놀로지(미국)의 모바일 스트리밍 서버 유튜브: 데스크톱에서 모바일 HTTPS 버전을 통해 사이트를 사용 가능한 스트리밍 옵션 IP 카메라로 불리는 수많은 CCTV 감시 카메라들(특히 ONVIF 프로파일 G, S, T를 제공하는 카메라들)은 RTSP 스트리밍을 지원한다. === 클라이언트 === 아스트라(Astra) CURL (버전 7.20.0—2010년 2월 9일자부터) FFmpeg GStreamer 제트오디오 LIVE555 라이브미디어 openRTSP: VLC와 엠플레이어 알려진 클라이언트에 사용되는 오픈 소스 C++ 서버 클라이언트 라이브러리. 미디어 플레이어 클래식 엠플레이어 MythTV (Freebox를 통해) Managed Media Aggregation .NET C# RFC 준수 RTSP 구현체. omxplayer 퀵타임 리얼플레이어 SeeStreamSharp: ISO 베이스 미디어 파일 포맷에 대한 미디어 스트림 녹화를 구현하는 RTSP 클라이언트. (오픈 소스, .NET 기반, 태스크 기반의 비동기 메소드 호출) SharpRTSP: 오픈 소스 C# RTSP 스트리밍 클라이언트, 서버 스카이프 스포티파이 VLC 미디어 플레이어 윈앰프 윈도우 미디어 플레이어 xine == 같이 보기 == 실시간 전송 프로토콜 (RTP) 퓨전 RTSP: 임베디드 시스템용 솔루션 == 각주 == == 외부 링크 == RTSP.org RTSP 정보 집체 사이트 RFC 2326, Real Time Streaming Protocol (RTSP). RFC 3550, RTP: Transport Protocol for Real-Time Applications. 분류:응용 계층 프로토콜