```text
Network Working Group H. Schulzrinne
Request for Comments: 2326 Columbia U.
Category: Standards Track A. Rao
Netscape
R. Lanphier
RealNetworks
April 1998
Real Time Streaming Protocol (RTSP)
```
---
# **Status of this Memo**
이 문서는 인터넷 커뮤니티를 위한 인터넷 표준 추적 프로토콜을 지정하고 개선을 위한 토론 및 제안을 요청합니다. 이 프로토콜의 표준화 상태 및 상태에 대해서는 "Internet Official Protocol Standards"\(STD 1\) 최신판을 참조하십시오. 이 메모의 배포는 무제한입니다.
---
# **Copyright Notice**
Copyright \(C\) The Internet Society \(1998\). 판권 소유.
---
# **Abstract**
실시간 스트리밍 프로토콜\(RTSP\)은 실시간 속성을 사용하여 데이터 전달을 제어하기 위한 애플리케이션 수준 프로토콜입니다. RTSP는 오디오 및 비디오와 같은 실시간 데이터의 제어된 온디맨드 전달을 가능하게 하는 확장 가능한 프레임워크를 제공합니다. 데이터 소스에는 실시간 데이터 피드와 저장된 클립이 모두 포함될 수 있습니다. 이 프로토콜은 여러 데이터 전달 세션을 제어하고 UDP, 멀티캐스트 UDP 및 TCP와 같은 전달 채널을 선택하는 수단을 제공하고 RTP\(RFC 1889\)를 기반으로 전달 메커니즘을 선택하는 수단을 제공하기 위한 것입니다.
---
# **Table of Contents**
```text
* 1 Introduction ................................................. 5
+ 1.1 Purpose ............................................... 5
+ 1.2 Requirements .......................................... 6
+ 1.3 Terminology ........................................... 6
+ 1.4 Protocol Properties ................................... 9
+ 1.5 Extending RTSP ........................................ 11
+ 1.6 Overall Operation ..................................... 11
+ 1.7 RTSP States ........................................... 12
+ 1.8 Relationship with Other Protocols ..................... 13
* 2 Notational Conventions ....................................... 14
* 3 Protocol Parameters .......................................... 14
+ 3.1 RTSP Version .......................................... 14
+ 3.2 RTSP URL .............................................. 14
+ 3.3 Conference Identifiers ................................ 16
+ 3.4 Session Identifiers ................................... 16
+ 3.5 SMPTE Relative Timestamps ............................. 16
+ 3.6 Normal Play Time ...................................... 17
+ 3.7 Absolute Time ......................................... 18
+ 3.8 Option Tags ........................................... 18
o 3.8.1 Registering New Option Tags with IANA .......... 18
* 4 RTSP Message ................................................. 19
+ 4.1 Message Types ......................................... 19
+ 4.2 Message Headers ....................................... 19
+ 4.3 Message Body .......................................... 19
+ 4.4 Message Length ........................................ 20
* 5 General Header Fields ........................................ 20
* 6 Request ...................................................... 20
+ 6.1 Request Line .......................................... 21
+ 6.2 Request Header Fields ................................. 21
* 7 Response ..................................................... 22
+ 7.1 Status-Line ........................................... 22
o 7.1.1 Status Code and Reason Phrase .................. 22
o 7.1.2 Response Header Fields ......................... 26
* 8 Entity ....................................................... 27
+ 8.1 Entity Header Fields .................................. 27
+ 8.2 Entity Body ........................................... 28
* 9 Connections .................................................. 28
+ 9.1 Pipelining ............................................ 28
+ 9.2 Reliability and Acknowledgements ...................... 28
* 10 Method Definitions .......................................... 29
+ 10.1 OPTIONS .............................................. 30
+ 10.2 DESCRIBE ............................................. 31
+ 10.3 ANNOUNCE ............................................. 32
+ 10.4 SETUP ................................................ 33
+ 10.5 PLAY ................................................. 34
+ 10.6 PAUSE ................................................ 36
+ 10.7 TEARDOWN ............................................. 37
+ 10.8 GET_PARAMETER ........................................ 37
+ 10.9 SET_PARAMETER ........................................ 38
+ 10.10 REDIRECT ............................................ 39
+ 10.11 RECORD .............................................. 39
+ 10.12 Embedded (Interleaved) Binary Data .................. 40
* 11 Status Code Definitions ..................................... 41
+ 11.1 Success 2xx .......................................... 41
o 11.1.1 250 Low on Storage Space ...................... 41
+ 11.2 Redirection 3xx ...................................... 41
+ 11.3 Client Error 4xx ..................................... 42
o 11.3.1 405 Method Not Allowed ........................ 42
o 11.3.2 451 Parameter Not Understood .................. 42
o 11.3.3 452 Conference Not Found ...................... 42
o 11.3.4 453 Not Enough Bandwidth ...................... 42
o 11.3.5 454 Session Not Found ......................... 42
o 11.3.6 455 Method Not Valid in This State ............ 42
o 11.3.7 456 Header Field Not Valid for Resource ....... 42
o 11.3.8 457 Invalid Range ............................. 43
o 11.3.9 458 Parameter Is Read-Only .................... 43
o 11.3.10 459 Aggregate Operation Not Allowed .......... 43
o 11.3.11 460 Only Aggregate Operation Allowed ......... 43
o 11.3.12 461 Unsupported Transport .................... 43
o 11.3.13 462 Destination Unreachable .................. 43
o 11.3.14 551 Option not supported ..................... 43
* 12 Header Field Definitions .................................... 44
+ 12.1 Accept ............................................... 46
+ 12.2 Accept-Encoding ...................................... 46
+ 12.3 Accept-Language ...................................... 46
+ 12.4 Allow ................................................ 46
+ 12.5 Authorization ........................................ 46
+ 12.6 Bandwidth ............................................ 46
+ 12.7 Blocksize ............................................ 47
+ 12.8 Cache-Control ........................................ 47
+ 12.9 Conference ........................................... 49
+ 12.10 Connection .......................................... 49
+ 12.11 Content-Base ........................................ 49
+ 12.12 Content-Encoding .................................... 49
+ 12.13 Content-Language .................................... 50
+ 12.14 Content-Length ...................................... 50
+ 12.15 Content-Location .................................... 50
+ 12.16 Content-Type ........................................ 50
+ 12.17 CSeq ................................................ 50
+ 12.18 Date ................................................ 50
+ 12.19 Expires ............................................. 50
+ 12.20 From ................................................ 51
+ 12.21 Host ................................................ 51
+ 12.22 If-Match ............................................ 51
+ 12.23 If-Modified-Since ................................... 52
+ 12.24 Last-Modified........................................ 52
+ 12.25 Location ............................................ 52
+ 12.26 Proxy-Authenticate .................................. 52
+ 12.27 Proxy-Require ....................................... 52
+ 12.28 Public .............................................. 53
+ 12.29 Range ............................................... 53
+ 12.30 Referer ............................................. 54
+ 12.31 Retry-After ......................................... 54
+ 12.32 Require ............................................. 54
+ 12.33 RTP-Info ............................................ 55
+ 12.34 Scale ............................................... 56
+ 12.35 Speed ............................................... 57
+ 12.36 Server .............................................. 57
+ 12.37 Session ............................................. 57
+ 12.38 Timestamp ........................................... 58
+ 12.39 Transport ........................................... 58
+ 12.40 Unsupported ......................................... 62
+ 12.41 User-Agent .......................................... 62
+ 12.42 Vary ................................................ 62
+ 12.43 Via ................................................. 62
+ 12.44 WWW-Authenticate .................................... 62
* 13 Caching ..................................................... 62
* 14 Examples .................................................... 63
+ 14.1 Media on Demand (Unicast) ............................ 63
+ 14.2 Streaming of a Container file ........................ 65
+ 14.3 Single Stream Container Files ........................ 67
+ 14.4 Live Media Presentation Using Multicast .............. 69
+ 14.5 Playing media into an existing session ............... 70
+ 14.6 Recording ............................................ 71
* 15 Syntax ...................................................... 72
+ 15.1 Base Syntax .......................................... 72
* 16 Security Considerations ..................................... 73
* A RTSP Protocol State Machines ................................. 76
+ A.1 Client State Machine .................................. 76
+ A.2 Server State Machine .................................. 77
* B Interaction with RTP ......................................... 79
* C Use of SDP for RTSP Session Descriptions ..................... 80
+ C.1 Definitions ........................................... 80
o C.1.1 Control URL .................................... 80
o C.1.2 Media streams .................................. 81
o C.1.3 Payload type(s) ................................ 81
o C.1.4 Format-specific parameters ..................... 81
o C.1.5 Range of presentation .......................... 82
o C.1.6 Time of availability ........................... 82
o C.1.7 Connection Information ......................... 82
o C.1.8 Entity Tag ..................................... 82
+ C.2 Aggregate Control Not Available ....................... 83
+ C.3 Aggregate Control Available ........................... 83
* D Minimal RTSP implementation .................................. 85
+ D.1 Client ................................................ 85
o D.1.1 Basic Playback ................................. 86
o D.1.2 Authentication-enabled ......................... 86
+ D.2 Server ................................................ 86
o D.2.1 Basic Playback ................................. 87
o D.2.2 Authentication-enabled ......................... 87
* E Authors' Addresses ........................................... 88
* F Acknowledgements ............................................. 89
* References ..................................................... 90
* Full Copyright Statement ....................................... 92
```
---
# **1 Introduction**
---
## **1.1 Purpose**
RTSP\(실시간 스트리밍 프로토콜\)는 오디오 및 비디오와 같은 연속 미디어의 단일 또는 여러 시간 동기화 스트림을 설정하고 제어합니다. 연속 미디어 스트림과 제어 스트림의 인터리빙이 가능하더라도 일반적으로 연속 스트림 자체를 전달하지는 않습니다\(섹션 10.12 참조\). 즉, RTSP는 멀티미디어 서버에 대한 "네트워크 원격 제어" 역할을 합니다.
제어할 스트림 세트는 프레젠테이션 설명에 의해 정의됩니다. 본 각서는 프레젠테이션 설명의 형식을 정의하지 않습니다.
RTSP 연결이라는 개념은 없습니다. 대신 서버는 식별자로 레이블이 지정된 세션을 유지합니다. RTSP 세션은 TCP 연결과 같은 전송 수준 연결에 전혀 연결되지 않습니다. RTSP 세션 중에 RTSP 클라이언트는 RTSP 요청을 발행하기 위해 서버에 대한 신뢰할 수 있는 많은 전송 연결을 열고 닫을 수 있습니다. 또는 UDP와 같은 비연결 전송 프로토콜을 사용할 수도 있습니다.
RTSP에 의해 제어되는 스트림은 RTP\[1\]를 사용할 수 있지만 RTSP의 작동은 연속 미디어를 전달하는 데 사용되는 전송 메커니즘에 의존하지 않습니다. 이 프로토콜은 의도적으로 구문과 동작이 HTTP/1.1\[2\]과 유사하므로 대부분의 경우 HTTP에 대한 확장 메커니즘을 RTSP에도 추가할 수 있습니다. 그러나 RTSP는 HTTP와 여러 가지 중요한 측면에서 다릅니다.
\* RTSP는 여러 가지 새로운 방법을 도입하고 다른 프로토콜 식별자를 갖습니다. \* RTSP 서버는 HTTP의 상태 비저장 특성과 달리 거의 모든 경우에 기본적으로 상태를 유지해야 합니다. \* RTSP 서버와 클라이언트 모두 요청을 발행할 수 있습니다. \* 데이터는 다른 프로토콜에 의해 대역 외로 전달됩니다. \(예외가 있습니다.\) \* RTSP는 현재 HTML 국제화 노력에 맞춰 ISO 8859-1이 아닌 ISO 10646\(UTF-8\)을 사용하도록 정의됩니다\[3\]. \* 요청-URI에는 항상 절대 URI가 포함됩니다. 과거의 실수에 대한 이전 버전과의 호환성으로 인해 HTTP/1.1 \[2\]은 요청에 절대 경로만 전달하고 호스트 이름을 별도의 헤더 필드에 넣습니다.
이렇게 하면 하나의 IP 주소를 가진 단일 호스트가 여러 문서 트리를 호스팅하는 "가상 호스팅"이 더 쉬워집니다.
프로토콜은 다음 작업을 지원합니다.
미디어 서버에서 미디어 검색:
- 클라이언트는 HTTP나 다른 방법을 통해 프레젠테이션 설명을 요청할 수 있습니다. 프레젠테이션이 멀티캐스트되는 경우 프레젠테이션 설명에는 연속 미디어에 사용할 멀티캐스트 주소와 포트가 포함됩니다. 프리젠테이션이 유니캐스트를 통해 클라이언트에게만 전송되는 경우 클라이언트는 보안상의 이유로 대상을 제공합니다.
```text
Invitation of a media server to a conference:
A media server can be "invited" to join an existing
conference, either to play back media into the presentation or
to record all or a subset of the media in a presentation. This
mode is useful for distributed teaching applications. Several
parties in the conference may take turns "pushing the remote
control buttons."
```
기존 프리젠테이션에 미디어 추가:
- 특히 라이브 프리젠테이션의 경우 서버가 클라이언트에게 추가 미디어를 사용할 수 있음을 알려줄 수 있으면 유용합니다.
RTSP 요청은 HTTP/1.1 \[2\]에서와 같이 프록시, 터널 및 캐시에 의해 처리될 수 있습니다.
---
## **1.2 Requirements**
이 문서의 핵심 단어 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" 및 "OPTIONAL"은 다음과 같습니다. RFC 2119 \[4\]에 설명된 대로 해석됩니다.\(MUST NOT\)
---
## **1.3 Terminology**
일부 용어는 HTTP/1.1 \[2\]에서 채택되었습니다. 여기에 나열되지 않은 용어는 HTTP/1.1에 정의되어 있습니다.
집계 제어:
- 서버가 단일 타임라인을 사용하여 여러 스트림을 제어합니다. 오디오/비디오 피드의 경우 이는 클라이언트가 오디오 및 비디오 피드를 모두 제어하기 위해 단일 재생 또는 일시 중지 메시지를 발행할 수 있음을 의미합니다.
회의:
- 다자간 멀티미디어 프리젠테이션. 여기서 "다중"은 1보다 크거나 같음을 의미합니다.
고객:
- 클라이언트는 미디어 서버에 지속적인 미디어 데이터를 요청합니다.
연결:
- 통신을 목적으로 두 프로그램 사이에 설정된 전송 계층 가상 회선입니다.
컨테이너 파일:
- 함께 재생될 때 프리젠테이션을 구성하는 경우가 많은 여러 미디어 스트림을 포함할 수 있는 파일입니다. RTSP 서버는 이러한 파일에 대한 종합적인 제어를 제공할 수 있지만 컨테이너 파일의 개념은 프로토콜에 포함되어 있지 않습니다.
연속 미디어:
- 소스와 싱크 사이에 타이밍 관계가 있는 데이터 즉, 싱크는 소스에 존재했던 타이밍 관계를 재현해야 합니다. 연속 미디어의 가장 일반적인 예로는 오디오와 모션 비디오가 있습니다. 연속 미디어는 소스와 싱크 사이에 "긴밀한" 타이밍 관계가 있는 실시간\(대화형\)이거나 관계가 덜 엄격한 스트리밍\(재생\)일 수 있습니다.
실재:
- 요청 또는 응답의 페이로드로 전송되는 정보입니다. 엔터티는 섹션 8에 설명된 대로 엔터티 헤더 필드 형식의 메타정보와 엔터티 본문 형식의 콘텐츠로 구성됩니다.
미디어 초기화:
- 데이터 유형/코덱별 초기화. 여기에는 클럭 속도, 색상 테이블 등이 포함됩니다. 미디어 스트림 재생을 위해 클라이언트에 필요한 모든 전송 독립적 정보는 스트림 설정의 미디어 초기화 단계에서 발생합니다.
미디어 매개변수:
- 스트림 재생 전이나 도중에 변경될 수 있는 미디어 유형별 매개변수입니다.
미디어 서버:
- 하나 이상의 미디어 스트림에 대한 재생 또는 녹음 서비스를 제공하는 서버입니다. 프레젠테이션 내의 다양한 미디어 스트림은 다양한 미디어 서버에서 시작될 수 있습니다. 미디어 서버는 프레젠테이션이 호출되는 웹 서버와 동일하거나 다른 호스트에 있을 수 있습니다.
미디어 서버 간접:
- 미디어 클라이언트를 다른 미디어 서버로 리디렉션합니다.
\(미디어\) 스트림:
- 단일 미디어 인스턴스\(예: 오디오 스트림, 비디오 스트림, 단일 화이트보드 또는 공유 애플리케이션 그룹\). RTP를 사용할 때 스트림은 RTP 세션 내의 소스에서 생성된 모든 RTP 및 RTCP 패킷으로 구성됩니다. 이는 DSM-CC 스트림\(\[5\]\)의 정의와 동일합니다.
메시지:
- RTSP 통신의 기본 단위로, 15절에 정의된 구문과 일치하는 구조화된 옥텟 시퀀스로 구성되고 연결 또는 비연결 프로토콜을 통해 전송됩니다.
참가자:
- 컨퍼런스 회원. 참가자는 미디어 기록 또는 재생 서버와 같은 기계일 수 있습니다.
프레젠테이션:
- 아래에 정의된 프레젠테이션 설명을 사용하여 완전한 미디어 피드로 클라이언트에 제공되는 하나 이상의 스트림 집합입니다. RTSP 컨텍스트에서 대부분의 경우 이는 해당 스트림의 총체적 제어를 의미하지만 반드시 그럴 필요는 없습니다.
프레젠테이션 설명:
- 프레젠테이션 설명에는 인코딩 집합, 네트워크 주소, 콘텐츠에 대한 정보 등 프레젠테이션 내의 하나 이상의 미디어 스트림에 대한 정보가 포함됩니다. SDP\(RFC 2327 \[6\]\)와 같은 다른 IETF 프로토콜은 라이브 프레젠테이션에 "세션"이라는 용어를 사용합니다. 프리젠테이션 설명은 세션 설명 형식 SDP를 포함하되 이에 국한되지 않는 여러 가지 다른 형식을 취할 수 있습니다.
응답:
- RTSP 응답. HTTP 응답을 의미하는 경우 이는 명시적으로 표시됩니다.
요구:
- RTSP 요청. HTTP 요청을 의미하는 경우 이는 명시적으로 표시됩니다.
RTSP 세션:
- 완전한 RTSP "거래"\(예: 영화 감상\). 세션은 일반적으로 클라이언트가 연속 미디어 스트림\(SETUP\)에 대한 전송 메커니즘을 설정하고, PLAY 또는 RECORD로 스트림을 시작하고,
- TEARDOWN으로 스트리밍합니다.
전송 초기화:
- 클라이언트와 서버 간의 전송 정보\(예: 포트 번호, 전송 프로토콜\) 협상.
---
## **1.4 Protocol Properties**
RTSP에는 다음과 같은 속성이 있습니다.
확장 가능:
- 새로운 방법과 매개변수를 RTSP에 쉽게 추가할 수 있습니다.
분석하기 쉬움:
- RTSP는 표준 HTTP 또는 MIME 파서로 구문 분석할 수 있습니다.
안전한:
- RTSP는 웹 보안 메커니즘을 재사용합니다. 기본\(RFC 2068 \[2, 섹션 11.1\]\) 및 다이제스트 인증\(RFC 2069 \[8\]\)과 같은 모든 HTTP 인증 메커니즘을 직접 적용할 수 있습니다. 전송 또는 네트워크 계층 보안 메커니즘을 재사용할 수도 있습니다.
운송에 독립적:
- RTSP는 UDP\(Unreliable Datagram Protocol\)\(RFC 768 \[9\]\), 신뢰할 수 있는 데이터그램 프로토콜\(RDP, RFC 1151, 널리 사용되지 않음\[10\]\) 또는 TCP\(RFC 793\[11\]와 같은 신뢰할 수 있는 스트림 프로토콜을 사용할 수 있습니다. \]\) 애플리케이션 수준의 안정성을 구현하기 때문입니다.
다중 서버 가능:
- 프레젠테이션 내의 각 미디어 스트림은 서로 다른 서버에 있을 수 있습니다. 클라이언트는 서로 다른 미디어 서버를 사용하여 여러 개의 동시 제어 세션을 자동으로 설정합니다. 미디어 동기화는 전송 수준에서 수행됩니다.
녹음 장치 제어:
- 프로토콜은 녹화 및 재생 장치뿐만 아니라 두 모드 사이를 전환할 수 있는 장치\("VCR"\)를 모두 제어할 수 있습니다.
스트림 제어와 회의 시작 분리:
- 스트림 제어는 미디어 서버를 회의에 초대하는 것과 분리됩니다. 유일한 요구 사항은 회의 시작 프로토콜이 고유한 회의 식별자를 제공하거나 생성하는 데 사용될 수 있다는 것입니다. 특히 SIP\[12\]나 H.323\[13\]은 서버를 회의에 초대하는 데 사용될 수 있습니다.
전문적인 용도에 적합:
- RTSP는 SMPTE 타임스탬프를 통해 프레임 수준 정확도를 지원하여 원격 디지털 편집이 가능합니다.
프레젠테이션 설명 중립:
- 프로토콜은 특정 프리젠테이션 설명이나 메타파일 형식을 강요하지 않으며 사용할 형식 유형을 전달할 수 있습니다. 그러나 프레젠테이션 설명에는 RTSP URI가 하나 이상 포함되어야 합니다.
프록시 및 방화벽 친화적:
- 프로토콜은 애플리케이션 및 전송 계층\(SOCKS \[14\]\) 방화벽 모두에서 쉽게 처리되어야 합니다. 방화벽은 UDP 미디어 스트림에 대한 "구멍"을 열려면 SETUP 방법을 이해해야 할 수도 있습니다.
HTTP 친화적:
- 합리적인 경우 RTSP는 HTTP 개념을 재사용하므로 기존 인프라를 재사용할 수 있습니다. 이 인프라에는 콘텐츠와 레이블을 연결하기 위한 PICS\(인터넷 콘텐츠 선택 플랫폼 \[15,16\]\)가 포함되어 있습니다. 그러나 연속 미디어를 제어하려면 대부분의 경우 서버 상태가 필요하므로 RTSP는 단순히 HTTP에 메서드를 추가하는 것이 아닙니다.
적절한 서버 제어:
- 클라이언트가 스트림을 시작할 수 있으면 스트림을 중지할 수 있어야 합니다. 클라이언트가 스트림을 중지할 수 없는 방식으로 서버는 클라이언트에 대한 스트리밍을 시작해서는 안 됩니다.
운송 협상:
- 클라이언트는 실제로 연속적인 미디어 스트림을 처리하기 전에 전송 방법을 협상할 수 있습니다.
역량 협상:
- 기본 기능이 비활성화된 경우 클라이언트가 구현되지 않을 메서드를 결정할 수 있는 깔끔한 메커니즘이 있어야 합니다. 이를 통해 클라이언트는 적절한 사용자 인터페이스를 제공할 수 있습니다. 예를 들어 탐색이 허용되지 않는 경우 사용자 인터페이스는 슬라이딩 위치 표시기 이동을 허용하지 않을 수 있어야 합니다.
```text
An earlier requirement in RTSP was multi-client capability.
However, it was determined that a better approach was to make sure
that the protocol is easily extensible to the multi-client
scenario. Stream identifiers can be used by several control
streams, so that "passing the remote" would be possible. The
protocol would not address how several clients negotiate access;
this is left to either a "social protocol" or some other floor
control mechanism.
```
---
## **1.5 Extending RTSP**
모든 미디어 서버가 동일한 기능을 갖고 있는 것은 아니기 때문에 미디어 서버는 필요에 따라 서로 다른 요청 세트를 지원하게 됩니다. 예를 들어:
\* 서버는 재생만 가능하므로 RECORD 요청을 지원할 필요가 없습니다. \* 서버가 라이브 이벤트만 지원하는 경우 검색\(절대 위치 지정\)이 불가능할 수 있습니다. \* 일부 서버에서는 스트림 매개변수 설정을 지원하지 않아 GET\_PARAMETER 및 SET\_PARAMETER를 지원하지 않을 수 있습니다.
서버는 섹션 12에 설명된 모든 헤더 필드를 구현해야 합니다\(SHOULD\).\(SHOULD\)
서버에 불가능함을 묻지 않는 것은 프레젠테이션 설명 작성자의 몫입니다. 이 상황은 \[H19.6\]에 설명된 방법이 모든 서버에서 지원되지 않는 HTTP/1.1 \[2\]에서도 유사합니다.
RTSP는 세 가지 방법으로 확장할 수 있습니다. 여기에는 지원되는 변경 규모 순서대로 나열되어 있습니다.
\* 기존 메서드는 수신자가 해당 매개변수를 안전하게 무시할 수 있는 한 새 매개변수로 확장될 수 있습니다. \(이는 HTML 태그에 새 매개변수를 추가하는 것과 같습니다.\) 메서드 확장이 지원되지 않을 때 클라이언트에 부정 승인이 필요한 경우 확장에 해당하는 태그가 필수: 필드에 추가될 수 있습니다\(섹션 12.32 참조\). \* 새로운 메소드가 추가될 수 있습니다. 메시지 수신자가 요청을 이해하지 못하는 경우 오류 코드 501\(구현되지 않음\)으로 응답하며 발신자는 이 방법을 다시 사용하려고 시도해서는 안 됩니다. 클라이언트는 OPTIONS 메소드를 사용하여 서버가 지원하는 메소드에 대해 문의할 수도 있습니다. 서버는 공개 응답 헤더를 사용하여 지원하는 메서드를 나열해야 합니다. \* 프로토콜의 새 버전을 정의하여 거의 모든 측면\(프로토콜 버전 번호의 위치 제외\)을 변경할 수 있습니다.\(SHOULD\)
---
## **1.6 Overall Operation**
각 프레젠테이션과 미디어 스트림은 RTSP URL로 식별될 수 있습니다. 전체적인 프리젠테이션과 프리젠테이션을 구성하는 미디어의 속성은 프리젠테이션 설명 파일에 의해 정의되며 그 형식은 이 사양의 범위를 벗어납니다. 프리젠테이션 설명 파일은 클라이언트가 다음을 사용하여 얻을 수 있습니다.
HTTP 또는 이메일과 같은 기타 수단은 반드시 미디어 서버에 저장되지 않을 수도 있습니다.
본 명세서의 목적을 위해, 프리젠테이션 설명은 각각이 공통 시간 축을 유지하는 하나 이상의 프리젠테이션을 설명하는 것으로 가정됩니다. 설명을 단순화하고 일반성을 잃지 않도록 표현 설명에는 그러한 표현이 정확히 하나만 포함되어 있다고 가정합니다. 프레젠테이션에는 여러 미디어 스트림이 포함될 수 있습니다.
프레젠테이션 설명 파일에는 클라이언트가 가장 적절한 미디어 조합을 선택할 수 있도록 하는 인코딩, 언어 및 기타 매개 변수를 포함하여 프레젠테이션을 구성하는 미디어 스트림에 대한 설명이 포함되어 있습니다. 이 프리젠테이션 설명에서 RTSP에 의해 개별적으로 제어 가능한 각 미디어 스트림은 특정 미디어 스트림을 처리하는 미디어 서버를 가리키고 해당 서버에 저장된 스트림의 이름을 지정하는 RTSP URL로 식별됩니다. 여러 미디어 스트림이 서로 다른 서버에 있을 수 있습니다. 예를 들어 오디오 및 비디오 스트림은 로드 공유를 위해 서버 간에 분할될 수 있습니다. 설명에는 서버가 수행할 수 있는 전송 방법도 열거되어 있습니다.
미디어 매개변수 외에도 네트워크 대상 주소와 포트를 결정해야 합니다. 여러 가지 작동 모드를 구분할 수 있습니다.
유니캐스트:
- 미디어는 클라이언트가 선택한 포트 번호를 사용하여 RTSP 요청 소스로 전송됩니다. 또는 미디어가 RTSP와 동일한 신뢰할 수 있는 스트림을 통해 전송됩니다.
멀티캐스트, 서버가 주소 선택:
- 미디어 서버는 멀티캐스트 주소와 포트를 선택합니다. 이는 라이브 또는 거의 주문형 미디어 전송의 일반적인 경우입니다.
멀티캐스트, 클라이언트가 주소 선택:
- 서버가 기존 멀티캐스트 회의에 참여하는 경우 멀티캐스트 주소, 포트 및 암호화 키는 이 사양의 범위를 벗어나는 수단으로 설정된 회의 설명에 의해 제공됩니다.
---
## **1.7 RTSP States**
RTSP는 제어 채널과 관계없이 별도의 프로토콜을 통해 전송될 수 있는 스트림을 제어합니다. 예를 들어, 데이터가 UDP를 통해 흐르는 동안 TCP 연결에서 RTSP 제어가 발생할 수 있습니다. 따라서 미디어에서 RTSP 요청을 받지 못하더라도 데이터 전달은 계속됩니다.
섬기는 사람. 또한 수명 동안 단일 미디어 스트림은 서로 다른 TCP 연결에서 순차적으로 발행되는 RTSP 요청에 의해 제어될 수 있습니다. 따라서 서버는 RTSP 요청을 스트림과 연관시킬 수 있도록 "세션 상태"를 유지해야 합니다. 상태 전환은 섹션 A에 설명되어 있습니다.
RTSP의 많은 메서드는 상태에 기여하지 않습니다. 그러나 SETUP, PLAY, RECORD, PAUSE 및 TEARDOWN은 서버에서 스트림 리소스의 할당 및 사용을 정의하는 데 핵심적인 역할을 합니다.
설정:
- 서버가 스트림에 대한 리소스를 할당하고 RTSP 세션을 시작하도록 합니다.
재생 및 녹음:
- SETUP을 통해 할당된 스트림으로 데이터 전송을 시작합니다.
정지시키다:
- 서버 리소스를 확보하지 않고 스트림을 일시적으로 중단합니다.
분해:
- 스트림과 관련된 리소스를 해제합니다. RTSP 세션이 서버에서 더 이상 존재하지 않습니다.
- 상태에 기여하는 RTSP 메서드는 세션 헤더 필드\(12.37절\)를 사용하여 상태가 조작되고 있는 RTSP 세션을 식별합니다. 서버는 SETUP 요청에 대한 응답으로 세션 식별자를 생성합니다\(10.4절\).
---
## **1.8 Relationship with Other Protocols**
RTSP는 HTTP와 기능이 일부 중복됩니다. 또한 스트리밍 콘텐츠와의 초기 접촉이 웹 페이지를 통해 이루어지는 경우가 많다는 점에서 HTTP와 상호 작용할 수도 있습니다. 현재 프로토콜 사양은 웹 서버와 RTSP를 구현하는 미디어 서버 간에 서로 다른 핸드오프 지점을 허용하는 것을 목표로 합니다. 예를 들어 HTTP 또는 RTSP를 사용하여 프레젠테이션 설명을 검색할 수 있습니다. 이는 웹 브라우저 기반 시나리오에서 왕복 횟수를 줄이면서 HTTP에 전혀 의존하지 않는 독립형 RTSP 서버 및 클라이언트도 허용합니다.
그러나 RTSP는 데이터 전달이 다른 프로토콜의 대역 외에서 이루어진다는 점에서 HTTP와 근본적으로 다릅니다. HTTP는 클라이언트가 요청을 발행하고 서버가 응답하는 비대칭 프로토콜입니다. RTSP에서는 미디어 클라이언트와 미디어 서버 모두 요청을 발행할 수 있습니다. RTSP 요청도 상태 비저장이 아닙니다. 매개변수를 설정하고 이벤트가 발생한 후에도 오랫동안 미디어 스트림을 계속 제어할 수 있습니다.
요청이 승인되었습니다.
HTTP 기능을 재사용하면 보안과 프록시라는 최소한 두 가지 영역에서 이점이 있습니다. 요구 사항은 매우 유사하므로 캐시, 프록시 및 인증에서 HTTP 작업을 채택하는 기능을 갖는 것이 중요합니다.
대부분의 실시간 미디어는 RTP를 전송 프로토콜로 사용하지만 RTSP는 RTP에 연결되지 않습니다.
RTSP는 여러 미디어 스트림을 포함하는 프리젠테이션의 정적 및 시간적 속성을 모두 표현할 수 있는 프리젠테이션 설명 형식이 존재한다고 가정합니다.
---
# **2 Notational Conventions**
많은 정의와 구문이 HTTP/1.1과 동일하므로 이 사양은 복사하는 것이 아니라 정의된 섹션만 가리킵니다. 간결하게 하기 위해 \[HX.Y\]는 현재 HTTP/1.1 사양\(RFC 2068 \[2\]\)의 섹션 X.Y를 참조하는 것으로 간주됩니다.
이 문서에 명시된 모든 메커니즘은 \[H2.1\]에서 사용된 것과 유사한 산문과 확장된 Backus-Naur 형식\(BNF\)으로 설명됩니다. RFC 2234 \[17\]에 자세히 설명되어 있지만 이 RTSP 사양은 쉼표로 구분된 목록에 대해 "1#" 표기법을 유지한다는 차이점이 있습니다.
이 메모에서는 배경과 동기를 제공하기 위해 들여쓰기 및 작은 유형의 단락을 사용합니다. 이는 사양 공식화에 참여하지 않은 독자에게 RTSP의 상황이 왜 그런 것인지에 대한 이해를 제공하기 위한 것입니다.
---
# **3 Protocol Parameters**
---
## **3.1 RTSP Version**
\[H3.1\]이 적용되며 HTTP는 RTSP로 대체됩니다.
---
## **3.2 RTSP URL**
"rtsp" 및 "rtspu" 체계는 RTSP 프로토콜을 통해 네트워크 리소스를 참조하는 데 사용됩니다. 이 섹션에서는 RTSP URL에 대한 체계별 구문과 의미를 정의합니다.
```text
rtsp_URL = ( "rtsp:" | "rtspu:" )
"//" host [ ":" port ] [ abs_path ]
host = <A legal Internet host domain name of IP address
(in dotted decimal form), as defined by Section 2.1
of RFC 1123 \cite{rfc1123}>
port = *DIGIT
```
abs\_path는 \[H3.2.1\]에 정의되어 있습니다.
조각 및 쿼리 식별자는 현재로서는 잘 정의된 의미가 없으며 해석은 RTSP 서버에 맡겨져 있습니다.
rtsp 구성표에서는 명령이 신뢰할 수 있는 프로토콜\(인터넷, TCP 내\)을 통해 실행되어야 하는 반면, rtspu 구성표는 신뢰할 수 없는 프로토콜\(인터넷, UDP 내\)을 식별합니다.
포트가 비어 있거나 지정되지 않은 경우 포트 554가 가정됩니다. 의미론은 식별된 리소스가 해당 호스트 포트에서 TCP\(구성표 "rtsp"\) 연결 또는 UDP\(구성표 "rtspu"\) 패킷을 수신하는 서버에서 RTSP에 의해 제어될 수 있고 리소스에 대한 요청-URI가 rtsp\_URL이라는 것입니다. .
URL에 IP 주소를 사용하는 것은 가능하면 피해야 합니다\(RFC 1924 \[19\] 참조\).\(SHOULD\)
프레젠테이션 또는 스트림은 URL의 문자 집합 및 이스케이프 규칙 \[H3.2\]\(RFC 1738 \[20\]\)을 사용하여 텍스트 미디어 식별자로 식별됩니다. URL은 스트림 또는 스트림 집합, 즉 프리젠테이션을 참조할 수 있습니다. 따라서 섹션 10에 설명된 요청은 전체 프리젠테이션 또는 프리젠테이션 내의 개별 스트림에 적용될 수 있습니다. 일부 요청 방법은 프레젠테이션이 아닌 스트림에만 적용될 수 있으며 그 반대의 경우도 마찬가지입니다.
예를 들어 RTSP URL: rtsp://media.example.com:554/twister/audiotrack
호스트 media.example.com의 포트 554에 대한 TCP 연결을 통해 발행된 RTSP 요청을 통해 제어될 수 있는 프레젠테이션 "twister" 내의 오디오 스트림을 식별합니다.
또한 RTSP URL: rtsp://media.example.com:554/twister
오디오 및 비디오 스트림으로 구성될 수 있는 프레젠테이션 "트위스터"를 식별합니다.
이는 URL에서 스트림을 참조하는 표준 방법을 의미하지 않습니다. 프레젠테이션 설명은 프레젠테이션의 계층적 관계와 개별 스트림의 URL을 정의합니다. 프레젠테이션 설명에서는 스트림 이름을 "a.mov"로 지정하고 전체 프레젠테이션 이름을 "b.mov"로 지정할 수 있습니다.
RTSP URL의 경로 구성 요소는 클라이언트에게 불투명하며 서버의 특정 파일 시스템 구조를 암시하지 않습니다.
또한 이러한 분리를 통해 간단히 URL의 구성표를 교체함으로써 비RTSP 미디어 제어 프로토콜과 함께 프레젠테이션 설명을 사용할 수 있습니다.
---
## **3.3 Conference Identifiers**
회의 식별자는 RTSP에 불투명하며 표준 URI 인코딩 방법을 사용하여 인코딩됩니다\(즉, LWS는 %로 이스케이프됩니다\). 모든 옥텟 값을 포함할 수 있습니다. 회의 식별자는 전역적으로 고유해야 합니다. H.323의 경우 conferenceID 값이 사용됩니다.\(MUST\)
```text
conference-id = 1*xchar
```
회의 식별자는 RTSP 세션이 미디어 서버가 참여하고 있는 멀티미디어 회의에서 매개변수를 얻을 수 있도록 하는 데 사용됩니다. 이러한 회의는 H.323 \[13\] 또는 SIP \[12\]와 같이 이 사양의 범위를 벗어나는 프로토콜에 의해 생성됩니다. 예를 들어 RTSP 클라이언트는 명시적으로 전송 정보를 제공하는 대신 회의 설명에 있는 값을 대신 사용하도록 미디어 서버에 요청합니다.
---
## **3.4 Session Identifiers**
세션 식별자는 임의 길이의 불투명 문자열입니다. 선형 공백은 URL 이스케이프 처리되어야 합니다. 세션 식별자는 무작위로 선택되어야 하며 추측을 더 어렵게 만들기 위해 길이가 최소 8옥텟이어야 합니다. \(섹션 16 참조\)\(MUST\)
```text
session-id = 1*( ALPHA | DIGIT | safe )
```
---
## **3.5 SMPTE Relative Timestamps**
SMPTE 상대 타임스탬프는 클립 시작을 기준으로 한 시간을 표현합니다. 상대 타임스탬프는 프레임 수준 액세스 정확도를 위해 SMPTE 시간 코드로 표현됩니다. 시간 코드의 형식은 시:분:초:frames.subframes이며, 원점은 클립 시작 부분입니다. 기본 smpte 형식은 "SMPTE 30 drop" 형식이며 프레임 속도는 초당 29.97프레임입니다. "smpte time"의 대체 사용을 통해 다른 SMPTE 코드\(예: "SMPTE 25"\)가 지원될 수 있습니다. 시간 값의 "프레임" 필드에 대해 0에서 29까지의 값을 가정할 수 있습니다. 초당 30프레임과 29.97프레임 사이의 차이는 10분마다를 제외하고 매 분마다 처음 두 프레임 인덱스\(값 00과 01\)를 삭제하여 처리됩니다. . 프레임 값이 0인 경우 생략될 수 있습니다. 서브프레임은 프레임의 100분의 1 단위로 측정됩니다.\(MAY\)
smpte-range = smpte-type "=" smpte-time "-" \[ smpte-time \] smpte-type = "smpte" | "smpte-30-드롭" | "smpte-25" ; 다른 타임코드가 추가될 수 있습니다. smpte-time = 1\*2DIGIT ":" 1\*2DIGIT ":" 1\*2DIGIT \[ ":" 1\*2DIGIT \] \[ "." 1\*2자리 \]
```text
Examples:
smpte=10:12:33:20-
smpte=10:07:33-
smpte=10:07:00-10:07:33:05.01
smpte-25=10:07:00-10:07:33:05.01
```
---
## **3.6 Normal Play Time**
NPT\(일반 재생 시간\)는 프레젠테이션 시작 부분을 기준으로 한 스트림 절대 위치를 나타냅니다. 타임스탬프는 소수 부분으로 구성됩니다. 소수점 왼쪽 부분은 초 또는 시, 분, 초로 표시될 수 있습니다. 소수점 오른쪽 부분은 1초의 분수를 측정합니다.
프레젠테이션의 시작은 0.0초에 해당합니다. 음수 값은 정의되지 않습니다. 이제 특수 상수는 라이브 이벤트의 현재 순간으로 정의됩니다. 라이브 이벤트에만 사용할 수 있습니다.
NPT는 DSM-CC에서 다음과 같이 정의됩니다. "직관적으로 NPT는 시청자가 프로그램과 연관시키는 시계입니다. 이는 종종 VCR에 디지털 방식으로 표시됩니다. NPT는 일반 재생 모드\(스케일 = 1\)에 있을 때 정상적으로 진행되며 더 빠른 속도로 진행됩니다. 빠른 스캔 순방향\(높은 양수 스케일 비율\)에서는 속도가 감소하고, 역방향 스캔\(높은 음수 스케일 비율\)에서는 감소하며 일시 중지 모드에서는 고정됩니다. NPT는 \(논리적으로\) SMPTE 시간 코드와 동일합니다." \[5\]
```text
npt-range = ( npt-time "-" [ npt-time ] ) | ( "-" npt-time )
npt-time = "now" | npt-sec | npt-hhmmss
npt-sec = 1*DIGIT [ "." *DIGIT ]
npt-hhmmss = npt-hh ":" npt-mm ":" npt-ss [ "." *DIGIT ]
npt-hh = 1*DIGIT ; any positive number
npt-mm = 1*2DIGIT ; 0-59
npt-ss = 1*2DIGIT ; 0-59
Examples:
npt=123.45-125
npt=12:05:35.3-
npt=now-
The syntax conforms to ISO 8601. The npt-sec notation is optimized
for automatic generation, the ntp-hhmmss notation for consumption
by human readers. The "now" constant allows clients to request to
```
저장된 버전이나 시간 지연 버전이 아닌 실시간 피드를 수신합니다. 이 경우에는 절대 시간이나 영 시간이 적합하지 않기 때문에 이것이 필요합니다.
---
## **3.7 Absolute Time**
절대 시간은 UTC\(GMT\)를 사용하여 ISO 8601 타임스탬프로 표현됩니다. 1초 단위까지 표시될 수 있습니다.
```text
utc-range = "clock" "=" utc-time "-" [ utc-time ]
utc-time = utc-date "T" utc-time "Z"
utc-date = 8DIGIT ; < YYYYMMDD >
utc-time = 6DIGIT [ "." fraction ] ; < HHMMSS.fraction >
```
1996년 11월 8일 14시 37분, UTC 20분의 1초의 예:
```text
19961108T143720.25Z
```
---
## **3.8 Option Tags**
옵션 태그는 RTSP에서 새 옵션을 지정하는 데 사용되는 고유 식별자입니다. 이러한 태그는 Require\(섹션 12.32\) 및 Proxy- Require\(섹션 12.27\) 헤더 필드에 사용됩니다.
```text
Syntax:
option-tag = 1*xchar
```
새로운 RTSP 옵션 작성자는 옵션 앞에 역방향 도메인 이름을 붙이거나\(예: "com.foo.mynewfeature"는 "foo.com"에서 발명가에게 연락할 수 있는 기능에 적합한 이름입니다\) IANA\(Internet Assigned Numbers Authority\)의 새로운 옵션입니다.
---
### **3.8.1 Registering New Option Tags with IANA**
새로운 RTSP 옵션을 등록할 때 다음 정보를 제공해야 합니다.
```text
* Name and description of option. The name may be of any length,
but SHOULD be no more than twenty characters long. The name MUST
not contain any spaces, control characters or periods.
* Indication of who has change control over the option (for
example, IETF, ISO, ITU-T, other international standardization
bodies, a consortium or a particular company or group of
companies);
* A reference to a further description, if available, for example
(in order of preference) an RFC, a published paper, a patent
filing, a technical report, documented source code or a computer
manual;
* For proprietary options, contact information (postal and email
address);
```
---
# **4 RTSP Message**
RTSP는 텍스트 기반 프로토콜이며 UTF-8 인코딩\(RFC 2279 \[21\]\)에서 ISO 10646 문자 집합을 사용합니다. 라인은 CRLF로 종료되지만 수신자는 CR 및 LF 자체를 라인 종결자로 해석할 준비도 되어 있어야 합니다.
텍스트 기반 프로토콜을 사용하면 자체 설명 방식으로 선택적 매개변수를 더 쉽게 추가할 수 있습니다. 매개변수 개수와 명령 빈도가 낮기 때문에 처리 효율성은 문제가 되지 않습니다. 텍스트 기반 프로토콜을 주의 깊게 수행하면 Tcl, Visual Basic 및 Perl과 같은 스크립팅 언어로 연구 프로토타입을 쉽게 구현할 수도 있습니다.
```text
The 10646 character set avoids tricky character set switching, but
is invisible to the application as long as US-ASCII is being used.
This is also the encoding used for RTCP. ISO 8859-1 translates
directly into Unicode with a high-order octet of zero. ISO 8859-1
characters with the most-significant bit set are represented as
1100001x 10xxxxxx. (See RFC 2279 [21])
```
RTSP 메시지는 8비트 깨끗한 하위 계층 전송 프로토콜을 통해 전달될 수 있습니다.
요청에는 메소드, 메소드가 작동하는 객체 및 메소드를 추가로 설명하는 매개변수가 포함됩니다. 별도로 명시하지 않는 한 메서드는 멱등원입니다. 또한 방법은 미디어 서버에서 상태 유지 관리가 거의 또는 전혀 필요하지 않도록 설계되었습니다.
---
## **4.1 Message Types**
```text
See [H4.1]
```
---
## **4.2 Message Headers**
```text
See [H4.2]
```
---
## **4.3 Message Body**
```text
See [H4.3]
```
---
## **4.4 Message Length**
메시지 본문이 메시지에 포함된 경우 해당 본문의 길이는 다음 중 하나에 따라 결정됩니다\(우선순위에 따라\).
1. 메시지 본문\(예: 1xx, 204 및 304 응답\)을 포함해서는 안 되는 모든 응답 메시지는 메시지에 있는 엔터티 헤더 필드에 관계없이 항상 헤더 필드 뒤의 첫 번째 빈 줄로 종료됩니다. \(참고: 빈 줄은 CRLF로만 구성됩니다.\)\(MUST NOT\)
2. Content-Length 헤더 필드\(섹션 12.14\)가 있는 경우 해당 값\(바이트\)은 메시지 본문의 길이를 나타냅니다. 이 헤더 필드가 없으면 값이 0으로 간주됩니다.
3. 서버가 연결을 종료합니다. \(연결을 닫으면 서버가 응답을 다시 보낼 가능성이 없기 때문에 요청 본문의 끝을 나타내는 데 사용할 수 없습니다.\)
RTSP는 \(현재\) HTTP/1.1 "청크" 전송 코딩\(\[H3.6\] 참조\)을 지원하지 않으며 Content-Length 헤더 필드가 필요합니다.
반환된 프리젠테이션 설명의 적당한 길이를 고려하면 서버는 동적으로 생성된 경우에도 항상 길이를 결정할 수 있어야 하므로 청크 분할 전송 인코딩이 필요하지 않습니다. 엔터티 본문이 있는 경우 Content-Length가 있어야 하지만 규칙은 길이가 명시적으로 지정되지 않은 경우에도 합리적인 동작을 보장합니다.
---
# **5 General Header Fields**
Pragma, Transfer-Encoding 및 Upgrade 헤더가 정의되지 않은 점을 제외하고 \[H4.5\]를 참조하세요.
```text
general-header = Cache-Control ; Section 12.8
| Connection ; Section 12.10
| Date ; Section 12.18
| Via ; Section 12.43
```
---
# **6 Request**
클라이언트에서 서버로 또는 그 반대로 요청 메시지에는 해당 메시지의 첫 번째 줄에 리소스에 적용할 메서드, 리소스 식별자 및 사용 중인 프로토콜 버전이 포함됩니다.
```text
Request = Request-Line ; Section 6.1
*( general-header ; Section 5
| request-header ; Section 6.2
| entity-header ) ; Section 8.1
CRLF
[ message-body ] ; Section 4.3
```
---
## **6.1 Request Line**
```text
Request-Line = Method SP Request-URI SP RTSP-Version CRLF
Method = "DESCRIBE" ; Section 10.2
| "ANNOUNCE" ; Section 10.3
| "GET_PARAMETER" ; Section 10.8
| "OPTIONS" ; Section 10.1
| "PAUSE" ; Section 10.6
| "PLAY" ; Section 10.5
| "RECORD" ; Section 10.11
| "REDIRECT" ; Section 10.10
| "SETUP" ; Section 10.4
| "SET_PARAMETER" ; Section 10.9
| "TEARDOWN" ; Section 10.7
| extension-method
extension-method = token
Request-URI = "*" | absolute_URI
RTSP-Version = "RTSP" "/" 1*DIGIT "." 1*DIGIT
```
---
## **6.2 Request Header Fields**
```text
request-header = Accept ; Section 12.1
| Accept-Encoding ; Section 12.2
| Accept-Language ; Section 12.3
| Authorization ; Section 12.5
| From ; Section 12.20
| If-Modified-Since ; Section 12.23
| Range ; Section 12.29
| Referer ; Section 12.30
| User-Agent ; Section 12.41
```
HTTP/1.1 \[2\]과 달리 RTSP 요청에는 항상 절대 경로가 아닌 절대 URL\(즉, 구성표, 호스트 및 포트 포함\)이 포함됩니다.
HTTP/1.1에서는 서버가 절대 URL을 이해해야 하지만 클라이언트는 호스트 요청 헤더를 사용해야 합니다. 이는 순전히 HTTP/1.0 서버와의 하위 호환성을 위해 필요하며 RTSP에는 적용되지 않는 고려 사항입니다.
Request-URI의 별표 "\*"는 요청이 특정 리소스에 적용되지 않고 서버 자체에 적용되며 사용된 방법이 반드시 리소스에 적용되지 않는 경우에만 허용됨을 의미합니다. 한 가지 예는 다음과 같습니다.
```text
OPTIONS * RTSP/1.0
```
---
# **7 Response**
\[H6\]은 HTTP 버전이 RTSP 버전으로 대체된다는 점을 제외하고 적용됩니다. 또한 RTSP는 추가 상태 코드를 정의하고 일부 HTTP 코드는 정의하지 않습니다. 유효한 응답 코드와 함께 사용할 수 있는 방법은 표 1에 정의되어 있습니다.
요청 메시지를 수신하고 해석한 후 수신자는 RTSP 응답 메시지로 응답합니다.
```text
Response = Status-Line ; Section 7.1
*( general-header ; Section 5
| response-header ; Section 7.1.2
| entity-header ) ; Section 8.1
CRLF
[ message-body ] ; Section 4.3
```
---
## **7.1 Status-Line**
응답 메시지의 첫 번째 라인은 상태 라인으로, 프로토콜 버전과 숫자 상태 코드, 상태 코드와 관련된 텍스트 문구로 구성되며 각 요소는 SP 문자로 구분됩니다. 최종 CRLF 시퀀스를 제외하고 CR 또는 LF는 허용되지 않습니다.
```text
Status-Line = RTSP-Version SP Status-Code SP Reason-Phrase CRLF
```
---
### **7.1.1 Status Code and Reason Phrase**
Status-Code 요소는 요청을 이해하고 만족시키려는 시도의 3자리 정수 결과 코드입니다. 이러한 코드는 섹션 11에 완전히 정의되어 있습니다. Reason-Phrase는 상태 코드에 대한 간단한 텍스트 설명을 제공하기 위한 것입니다. Status-Code는 오토마타에서 사용하기 위한 것이고 Reason-Phrase는 인간 사용자를 위한 것입니다. 클라이언트는 이유 문구를 검사하거나 표시할 필요가 없습니다.
상태 코드의 첫 번째 숫자는 응답 클래스를 정의합니다. 마지막 두 자리에는 분류 역할이 없습니다. 첫 번째 숫자에는 5개의 값이 있습니다.
\* 1xx: 정보 제공 - 요청 수신, 계속 프로세스 \* 2xx: 성공 - 작업이 성공적으로 수신되고 이해되었으며 승인되었습니다. \* 3xx: 리디렉션 - 요청을 완료하려면 추가 작업을 수행해야 합니다. \* 4xx: 클라이언트 오류 - 요청에 다음이 포함됩니다. 구문이 잘못되었거나 이행할 수 없습니다. \* 5xx: 서버 오류 - 서버가 명백히 유효한 요청을 이행하지 못했습니다.
RTSP/1.0에 대해 정의된 숫자 상태 코드의 개별 값과 해당 이유 문구의 예시 세트가 아래에 나와 있습니다. 여기에 나열된 이유 문구는 권장 사항일 뿐입니다. 프로토콜에 영향을 주지 않고 해당 지역의 문구로 대체될 수 있습니다. RTSP는 대부분의 HTTP/1.1 \[2\] 상태 코드를 채택하고 새로 정의된 HTTP 상태 코드와의 충돌을 피하기 위해 x50에서 시작하는 RTSP 관련 상태 코드를 추가합니다.
상태 코드 = "100" ; 계속하다
- | "200" ; 알았어 | "201" ; 생성됨 | "250" ; 저장 공간 부족 | "300" ; 다중 선택 | "301" ; 영구 이전 | "302" ; 임시 이전 | "303" ; 기타 보기 | "304" ; 수정되지 않음 | "305" ; 프록시 사용 | "400" ; 잘못된 요청 | "401" ; 무단 | "402" ; 결제 필요 | "403" ; 금지 | "404" ; 찾을 수 없음 | "405" ; 메소드가 허용되지 않음 | "406" ; 허용되지 않음 | "407" ; 프록시 인증 필요 | "408" ; 시간 초과 요청 | "410" ; 사라짐 | "411" ; 필요한 길이 | "412" ; 전제조건 실패 | "413" ; 요청 엔터티가 너무 큼 | "414" ; 요청-URI가 너무 큼 | "415" ; 지원되지 않는 미디어 유형 | "451" ; 매개변수를 이해할 수 없음 | "452" ; 회의를 찾을 수 없음 | "453" ; 대역폭이 충분하지 않음 | "454" ; 세션을 찾을 수 없음 | "455" ; 이 상태에서는 메서드가 유효하지 않습니다 | "456" ; 자원에 대한 헤더 필드가 유효하지 않음 | "457" ; 잘못된 범위 | "458" ; 매개변수가 읽기 전용임 | "459" ; 집계 작업이 허용되지 않음 | "460" ; 집계 작업만 허용됨 | "461" ; 지원되지 않는 전송 | "462" ; 목적지에 도달할 수 없습니다 | "500" ; 내부 서버 오류 | "501" ; 구현되지 않음 | "502" ; 나쁜 게이트웨이 | "503" ; 서비스를 이용할 수 없습니다 | "504" ; 게이트웨이 시간 초과 | "505" ; RTSP 버전이 지원되지 않음 | "551" ; 옵션이 지원되지 않습니다 | 확장 코드
```text
extension-code = 3DIGIT
Reason-Phrase = *<TEXT, excluding CR, LF>
```
RTSP 상태 코드는 확장 가능합니다. RTSP 응용 프로그램은 등록된 모든 상태 코드의 의미를 이해할 필요는 없지만, 그러한 이해가 분명히 바람직합니다. 그러나 애플리케이션은 첫 번째 숫자로 표시된 모든 상태 코드의 클래스를 이해해야 하며, 인식할 수 없는 응답을 캐시해서는 안 된다는 점을 제외하고는 인식할 수 없는 모든 응답을 해당 클래스의 x00 상태 코드와 동일한 것으로 처리해야 합니다. 예를 들어, 클라이언트가 인식할 수 없는 상태 코드 431을 수신하면 요청에 문제가 있다고 안전하게 가정하고 응답을 400 상태 코드를 수신한 것처럼 처리할 수 있습니다. 그러한 경우, 사용자 에이전트는 응답과 함께 반환된 엔터티를 사용자에게 제시해야 합니다. 왜냐하면 해당 엔터티에는 비정상적인 상태를 설명하는 사람이 읽을 수 있는 정보가 포함될 가능성이 높기 때문입니다.\(MUST NOT, SHOULD\)
```text
Code reason
100 Continue all
200 OK all
201 Created RECORD
250 Low on Storage Space RECORD
300 Multiple Choices all
301 Moved Permanently all
302 Moved Temporarily all
303 See Other all
305 Use Proxy all
400 Bad Request all
401 Unauthorized all
402 Payment Required all
403 Forbidden all
404 Not Found all
405 Method Not Allowed all
406 Not Acceptable all
407 Proxy Authentication Required all
408 Request Timeout all
410 Gone all
411 Length Required all
412 Precondition Failed DESCRIBE, SETUP
413 Request Entity Too Large all
414 Request-URI Too Long all
415 Unsupported Media Type all
451 Invalid parameter SETUP
452 Illegal Conference Identifier SETUP
453 Not Enough Bandwidth SETUP
454 Session Not Found all
455 Method Not Valid In This State all
456 Header Field Not Valid all
457 Invalid Range PLAY
458 Parameter Is Read-Only SET_PARAMETER
459 Aggregate Operation Not Allowed all
460 Only Aggregate Operation Allowed all
461 Unsupported Transport all
462 Destination Unreachable all
500 Internal Server Error all
501 Not Implemented all
502 Bad Gateway all
503 Service Unavailable all
504 Gateway Timeout all
505 RTSP Version Not Supported all
551 Option not support all
```
- 표 1: 상태 코드 및 RTSP 방법에서의 사용법
---
### **7.1.2 Response Header Fields**
응답 헤더 필드를 사용하면 요청 수신자가 상태 줄에 배치할 수 없는 응답에 대한 추가 정보를 전달할 수 있습니다. 이러한 헤더 필드는 서버에 대한 정보와 Request-URI로 식별된 리소스에 대한 추가 액세스에 대한 정보를 제공합니다.
```text
response-header = Location ; Section 12.25
| Proxy-Authenticate ; Section 12.26
| Public ; Section 12.28
| Retry-After ; Section 12.31
| Server ; Section 12.36
| Vary ; Section 12.42
| WWW-Authenticate ; Section 12.44
```
응답 헤더 필드 이름은 프로토콜 버전이 변경되는 경우에만 안정적으로 확장될 수 있습니다. 그러나 통신의 모든 당사자가 이를 응답 헤더 필드로 인식하는 경우 새롭거나 실험적인 헤더 필드에 응답 헤더 필드의 의미가 부여될 수 있습니다. 인식할 수 없는 헤더 필드는 엔터티 헤더 필드로 처리됩니다.\(MAY\)
---
# **8 Entity**
요청 및 응답 메시지는 요청 방법이나 응답 상태 코드에 의해 달리 제한되지 않는 한 엔터티를 전송할 수 있습니다. 엔터티는 엔터티 헤더 필드와 엔터티 본문으로 구성되지만 일부 응답에는 엔터티 헤더만 포함됩니다.\(MAY\)
이 섹션에서 보낸 사람과 받는 사람 모두 엔터티를 보내는 사람과 받는 사람에 따라 클라이언트나 서버를 나타냅니다.
---
## **8.1 Entity Header Fields**
엔터티 헤더 필드는 엔터티 본문에 대한 선택적 메타 정보를 정의하거나, 본문이 없는 경우 요청에 의해 식별된 리소스에 대한 메타 정보를 정의합니다.
```text
entity-header = Allow ; Section 12.4
| Content-Base ; Section 12.11
| Content-Encoding ; Section 12.12
| Content-Language ; Section 12.13
| Content-Length ; Section 12.14
| Content-Location ; Section 12.15
| Content-Type ; Section 12.16
| Expires ; Section 12.19
| Last-Modified ; Section 12.24
| extension-header
extension-header = message-header
```
확장 헤더 메커니즘을 사용하면 프로토콜을 변경하지 않고도 추가 엔터티 헤더 필드를 정의할 수 있지만 이러한 필드를 수신자가 인식할 수 있다고 가정할 수는 없습니다. 인식할 수 없는 헤더 필드는 수신자가 무시하고 프록시에 의해 전달되어야 합니다.\(SHOULD\)
---
## **8.2 Entity Body**
```text
See [H7.2]
```
---
# **9 Connections**
RTSP 요청은 여러 가지 방법으로 전송될 수 있습니다.
\* 여러 용도로 사용되는 지속적인 전송 연결
- 요청-응답 트랜잭션; \* 요청/응답 트랜잭션당 하나의 연결; \* 비연결 모드.
전송 연결 유형은 RTSP URI\(섹션 3.2\)에 의해 정의됩니다. "rtsp" 구성표의 경우 지속적인 연결이 가정되는 반면 "rtspu" 구성표는 연결을 설정하지 않고 RTSP 요청이 전송되도록 요구합니다.
HTTP와 달리 RTSP를 사용하면 미디어 서버가 미디어 클라이언트에 요청을 보낼 수 있습니다. 그러나 이는 미디어 서버가 클라이언트에 연결하는 안정적인 방법이 없기 때문에 지속적인 연결에 대해서만 지원됩니다. 또한 이는 미디어 서버에서 클라이언트로의 요청이 방화벽을 통과할 수 있는 유일한 방법입니다.
---
## **9.1 Pipelining**
지속적인 연결 또는 비연결 모드를 지원하는 클라이언트는 해당 요청을 "파이프라인"할 수 있습니다\(즉, 각 응답을 기다리지 않고 여러 요청을 보낼 수 있음\). 서버는 요청이 수신된 순서와 동일한 순서로 해당 요청에 대한 응답을 보내야 합니다.\(MAY, MUST\)
---
## **9.2 Reliability and Acknowledgements**
요청이 멀티캐스트 그룹으로 전송되지 않는 한 수신자는 요청을 승인합니다. 확인이 없으면 보낸 사람은 RTT\(왕복 시간\) 시간 초과 후 동일한 메시지를 다시 보낼 수 있습니다. 왕복 시간은 TCP\(RFC 1123\)\[18\]에서와 같이 추정되며 초기 왕복 값은 500ms입니다. 구현은 마지막 RTT 측정을 향후 연결을 위한 초기 값으로 캐시할 수 있습니다.\(MAY\)
신뢰할 수 있는 전송 프로토콜을 사용하여 RTSP를 전달하는 경우 요청을 재전송해서는 안 됩니다. 대신 RTSP 애플리케이션은 안정성을 제공하기 위해 기본 전송에 의존해야 합니다.\(MUST NOT\)
```text
If both the underlying reliable transport such as TCP and the RTSP
application retransmit requests, it is possible that each packet
loss results in two retransmissions. The receiver cannot typically
take advantage of the application-layer retransmission since the
```
전송 스택은 첫 번째 시도가 수신기에 도달하기 전에 애플리케이션 계층 재전송을 전달하지 않습니다. 혼잡으로 인해 패킷 손실이 발생한 경우 서로 다른 계층에서 여러 번 재전송하면 혼잡이 악화됩니다.
RTSP가 소규모 RTT LAN을 통해 사용되는 경우 T/TCP\(RFC 1644\)\[22\]에서 사용되는 것과 같은 초기 TCP 왕복 추정을 최적화하기 위한 표준 절차가 도움이 될 수 있습니다.
Timestamp 헤더\(12.38절\)는 재전송 모호성 문제 \[23, p. 301\] Karn의 알고리즘이 필요하지 않습니다.
각 요청은 CSeq 헤더\(12.17절\)에 시퀀스 번호를 전달하며, 이 시퀀스 번호는 전송된 개별 요청마다 1씩 증가됩니다. 승인 부족으로 인해 요청이 반복되는 경우 요청은 원래 시퀀스 번호를 전달해야 합니다\(즉, 시퀀스 번호가 증가되지 않음\).\(MUST\)
RTSP를 구현하는 시스템은 반드시 TCP를 통한 RTSP 전달을 지원해야 하며 UDP를 지원할 수 있습니다\(MAY\). RTSP 서버의 기본 포트는 UDP와 TCP 모두 554입니다.\(MUST\)
동일한 제어 종단점으로 향하는 다수의 RTSP 패킷은 단일 하위 계층 PDU로 압축되거나 TCP 스트림으로 캡슐화될 수 있습니다. RTSP 데이터는 RTP 및 RTCP 패킷과 함께 인터리브될 수 있습니다. HTTP와 달리 RTSP 메시지에는 해당 메시지에 페이로드가 포함될 때마다 Content-Length 헤더가 포함되어야 합니다. 그렇지 않으면 RTSP 패킷은 마지막 메시지 헤더 바로 다음에 빈 줄로 종료됩니다.\(MAY, MUST\)
---
# **10 Method Definitions**
메소드 토큰은 요청-URI에 의해 식별된 자원에 대해 수행될 메소드를 나타냅니다. 이 방법은 대소문자를 구분합니다. 미래에는 새로운 방법이 정의될 수 있습니다. 메소드 이름은 $ 문자\(10진수 24\)로 시작할 수 없으며 토큰이어야 합니다. 방법은 표 2에 요약되어 있습니다.
```text
method direction object requirement
DESCRIBE C->S P,S recommended
ANNOUNCE C->S, S->C P,S optional
GET_PARAMETER C->S, S->C P,S optional
OPTIONS C->S, S->C P,S required
(S->C: optional)
PAUSE C->S P,S recommended
PLAY C->S P,S required
RECORD C->S P,S optional
REDIRECT S->C P,S optional
SETUP C->S S required
SET_PARAMETER C->S, S->C P,S optional
TEARDOWN C->S P,S required
```
- 표 2: RTSP 방법 개요, 방향 및 작동하는 개체\(P: 프레젠테이션, S: 스트림\)
표 2에 대한 참고 사항: PAUSE가 권장되지만 라이브 피드와 같이 이 방법을 지원하지 않는 완전한 기능의 서버를 구축할 수 있다는 점에서 필수는 아닙니다. 서버가 특정 방법을 지원하지 않는 경우 "501 Not Implemented"를 반환해야 하며 클라이언트는 이 서버에 대해 이 방법을 다시 시도해서는 안 됩니다.\(MUST\)
---
## **10.1 OPTIONS**
동작은 \[H9.2\]에 설명된 것과 동일합니다. OPTIONS 요청은 언제든지 발행될 수 있습니다\(예: 클라이언트가 비표준 요청을 시도하려는 경우\). 서버 상태에는 영향을 주지 않습니다.
```text
Example:
C->S: OPTIONS * 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
```
이는 필연적으로 허구적인 기능이라는 점에 유의하세요\(이 섹션에서 강력한 예를 볼 수 있도록 의도적으로 유용한 기능을 간과하지 않기를 바랍니다\).
---
## **10.2 DESCRIBE**
DESCRIBE 메소드는 서버의 요청 URL로 식별되는 프리젠테이션 또는 미디어 객체에 대한 설명을 검색합니다. 클라이언트가 이해하는 설명 형식을 지정하기 위해 Accept 헤더를 사용할 수 있습니다. 서버는 요청된 리소스에 대한 설명으로 응답합니다. DESCRIBE 응답-응답 쌍은 RTSP의 미디어 초기화 단계를 구성합니다.
```text
Example:
C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/1.0
CSeq: 312
Accept: application/sdp, application/rtsl, application/mheg
S->C: RTSP/1.0 200 OK
CSeq: 312
Date: 23 Jan 1997 15:35:06 GMT
Content-Type: application/sdp
Content-Length: 376
v=0
o=mhandley 2890844526 2890842807 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
m=whiteboard 32416 UDP WB
a=orient:portrait
```
DESCRIBE 응답은 반드시 설명하는 리소스에 대한 모든 미디어 초기화 정보를 포함해야 합니다. 미디어 클라이언트가 DESCRIBE 이외의 소스로부터 프리젠테이션 설명을 얻고 해당 설명에 미디어 초기화 매개변수의 전체 세트가 포함되어 있는 경우 클라이언트는 해당 매개변수를 사용해야 하며 RTSP를 통해 동일한 미디어에 대한 설명을 요청해서는 안 됩니다.\(MUST, SHOULD\)
또한 서버는 DESCRIBE 응답을 미디어 간접 전달 수단으로 사용해서는 안 됩니다.\(SHOULD NOT\)
```text
Clear ground rules need to be established so that clients have an
unambiguous means of knowing when to request media initialization
information via DESCRIBE, and when not to. By forcing a DESCRIBE
```
설명하는 스트림 집합에 대한 모든 미디어 초기화를 포함하도록 응답하고 미디어 간접 참조에 DESCRIBE를 사용하지 않도록 하여 다른 접근 방식으로 인해 발생할 수 있는 루핑 문제를 방지합니다.
미디어 초기화는 모든 RTSP 기반 시스템의 요구 사항이지만 RTSP 사양에는 DESCRIBE 메서드를 통해 수행해야 한다고 명시되어 있지 않습니다. RTSP 클라이언트가 초기화 정보를 수신할 수 있는 세 가지 방법이 있습니다.
\* RTSP의 DESCRIBE 메소드를 통해; \* 다른 프로토콜\(HTTP, 이메일 첨부 등\)을 통해; \* 명령줄 또는 표준 입력을 통해\(따라서 SDP 파일 또는 기타 미디어 초기화 형식으로 실행되는 브라우저 도우미 응용 프로그램으로 작동\)
실질적인 상호 운용성을 위해서는 최소 서버가 DESCRIBE 메서드를 지원하는 것이 좋습니다. 그리고 최소 클라이언트가 표준 입력, 명령줄 및 명령줄에서 미디어 초기화 파일을 받아들이는 "도우미 응용 프로그램" 역할을 하는 기능을 지원하는 것이 좋습니다. /또는 클라이언트의 운영 환경에 적합한 기타 수단.
---
## **10.3 ANNOUNCE**
ANNOUNCE 메서드는 두 가지 목적으로 사용됩니다.
ANNOUNCE는 클라이언트에서 서버로 전송될 때 요청 URL로 식별되는 프리젠테이션 또는 미디어 개체에 대한 설명을 서버에 게시합니다. ANNOUNCE는 서버에서 클라이언트로 전송되면 세션 설명을 실시간으로 업데이트합니다.
새로운 미디어 스트림이 프레젠테이션에 추가되는 경우\(예: 라이브 프레젠테이션 중에\) 구성 요소를 삭제할 수 있도록 추가 구성 요소뿐만 아니라 전체 프레젠테이션 설명을 다시 전송해야 합니다.
```text
Example:
C->S: ANNOUNCE rtsp://server.example.com/fizzle/foo RTSP/1.0
CSeq: 312
Date: 23 Jan 1997 15:35:06 GMT
Session: 47112344
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: 312
```
---
## **10.4 SETUP**
URI에 대한 SETUP 요청은 스트리밍 미디어에 사용될 전송 메커니즘을 지정합니다. 클라이언트는 전송 매개변수를 변경하기 위해 이미 재생 중인 스트림에 대해 SETUP 요청을 발행할 수 있으며, 이는 서버가 허용할 수 있습니다. 이를 허용하지 않는 경우 "455 이 상태에서는 유효하지 않은 메서드" 오류로 응답해야 합니다. 중간 방화벽의 이점을 위해 클라이언트는 이러한 매개변수에 영향을 미치지 않더라도 전송 매개변수를 표시해야 합니다\(예: 서버가 고정 멀티캐스트 주소를 광고하는 경우\).\(MAY, MUST\)
SETUP에는 모든 전송 초기화 정보가 포함되어 있으므로 방화벽 및 기타 중간 네트워크 장치\(이 정보가 필요함\)는 미디어 초기화를 위해 예약된 DESCRIBE 응답을 구문 분석하는 더 힘든 작업을 수행하지 않습니다.
Transport 헤더는 데이터 전송을 위해 클라이언트가 허용할 수 있는 전송 매개변수를 지정합니다. 응답에는 서버에서 선택한 전송 매개변수가 포함됩니다.
```text
C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/1.0
CSeq: 302
Transport: RTP/AVP;unicast;client_port=4588-4589
S->C: RTSP/1.0 200 OK
CSeq: 302
Date: 23 Jan 1997 15:35:06 GMT
Session: 47112344
Transport: RTP/AVP;unicast;
client_port=4588-4589;server_port=6256-6257
```
서버는 SETUP 요청에 대한 응답으로 세션 식별자를 생성합니다. 서버에 대한 SETUP 요청에 세션 식별자가 포함되어 있는 경우 서버는 이 설정 요청을 세션 식별자로 묶어야 합니다.\(MUST\)
기존 세션 또는 "459 집계 작업이 허용되지 않음" 오류를 반환합니다\(섹션 11.3.10 참조\).
---
## **10.5 PLAY**
PLAY 메소드는 SETUP에 지정된 메커니즘을 통해 데이터 전송을 시작하도록 서버에 지시합니다. 클라이언트는 미해결 SETUP 요청이 성공으로 확인될 때까지 PLAY 요청을 발행해서는 안 됩니다.\(MUST NOT\)
PLAY 요청은 일반 재생 시간을 지정된 범위의 시작 부분에 배치하고 범위 끝에 도달할 때까지 스트림 데이터를 전달합니다. PLAY 요청은 파이프라인\(대기열\)에 포함될 수 있습니다. 서버는 순서대로 실행될 PLAY 요청을 대기열에 넣어야 합니다. 즉, 이전 PLAY 요청이 여전히 활성화되어 있는 동안 도착하는 PLAY 요청은 첫 번째 PLAY 요청이 완료될 때까지 지연됩니다.\(MUST\)
이를 통해 정확한 편집이 가능합니다.
예를 들어, 아래 예에서 두 PLAY 요청이 얼마나 가까운 간격으로 도착하는지에 관계없이 서버는 먼저 10\~15초를 재생한 다음 바로 다음에 20\~25초를 재생하고 마지막으로 30초를 끝까지 재생합니다.
```text
C->S: PLAY rtsp://audio.example.com/audio RTSP/1.0
CSeq: 835
Session: 12345678
Range: npt=10-15
C->S: PLAY rtsp://audio.example.com/audio RTSP/1.0
CSeq: 836
Session: 12345678
Range: npt=20-25
C->S: PLAY rtsp://audio.example.com/audio RTSP/1.0
CSeq: 837
Session: 12345678
Range: npt=30-
```
추가 예는 PAUSE 요청에 대한 설명을 참조하세요.
Range 헤더가 없는 PLAY 요청은 합법적입니다. 스트림이 일시 중지되지 않은 이상 처음부터 스트림 재생을 시작합니다. PAUSE를 통해 스트림이 일시 중지된 경우 일시 중지 지점에서 스트림 전송이 재개됩니다. 스트림이 재생 중인 경우 이러한 PLAY 요청은 추가 작업을 발생시키지 않으며 클라이언트가 서버 활성 상태를 테스트하는 데 사용할 수 있습니다.
Range 헤더에는 시간 매개변수도 포함될 수 있습니다. 이 매개변수는 재생이 시작되어야 하는 시간을 UTC로 지정합니다. 지정된 시간 이후에 메시지가 수신되면 즉시 재생이 시작됩니다. 시간 매개변수는 서로 다른 소스에서 얻은 스트림의 동기화를 돕기 위해 사용될 수 있습니다.
주문형 스트림의 경우 서버는 재생될 실제 범위로 응답합니다. 미디어 소스에 대해 요청된 범위를 유효한 프레임 경계에 맞춰 정렬해야 하는 경우 요청된 범위와 다를 수 있습니다. 요청에 범위가 지정되지 않은 경우 현재 위치가 응답으로 반환됩니다. 응답의 범위 단위는 요청의 범위 단위와 동일합니다.
원하는 범위를 재생한 후 마치 PAUSE 요청이 발생한 것처럼 프레젠테이션이 자동으로 일시 중지됩니다.
다음 예에서는 SMPTE 시간 코드 0:10:20부터 클립 끝까지 전체 프레젠테이션을 재생합니다. 재생은 1997년 1월 23일 15시 36분부터 시작됩니다.
```text
C->S: PLAY rtsp://audio.example.com/twister.en RTSP/1.0
CSeq: 833
Session: 12345678
Range: smpte=0:10:20-;time=19970123T153600Z
S->C: RTSP/1.0 200 OK
CSeq: 833
Date: 23 Jan 1997 15:35:06 GMT
Range: smpte=0:10:22-;time=19970123T153600Z
```
라이브 프레젠테이션의 녹화물을 재생하려면 시계 단위를 사용하는 것이 바람직할 수 있습니다.
```text
C->S: PLAY rtsp://audio.example.com/meeting.en RTSP/1.0
CSeq: 835
Session: 12345678
Range: clock=19961108T142300Z-19961108T143520Z
S->C: RTSP/1.0 200 OK
CSeq: 835
Date: 23 Jan 1997 15:35:06 GMT
```
재생만 지원하는 미디어 서버는 npt 형식을 지원해야 하며 시계 및 smpte 형식을 지원할 수 있습니다.\(MUST\)
---
## **10.6 PAUSE**
PAUSE 요청으로 인해 스트림 전달이 일시적으로 중단됩니다. 요청 URL이 스트림을 명명하는 경우 해당 스트림의 재생 및 녹화만 중지됩니다. 예를 들어 오디오의 경우 이는 음소거와 동일합니다. 요청 URL이 프레젠테이션이나 스트림 그룹의 이름을 지정하는 경우 프레젠테이션이나 그룹 내에서 현재 활성화된 모든 스트림의 전달이 중단됩니다. 재생이나 녹음을 재개한 후에는 트랙의 동기화가 유지되어야 합니다. 모든 서버 리소스는 유지되지만 서버는 SETUP 메시지에 있는 Session 헤더의 timeout 매개변수로 지정된 기간 동안 일시 중지된 후 세션을 닫고 리소스를 해제할 수 있습니다.\(MUST, MAY\)
```text
Example:
C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/1.0
CSeq: 834
Session: 12345678
S->C: RTSP/1.0 200 OK
CSeq: 834
Date: 23 Jan 1997 15:35:06 GMT
```
PAUSE 요청에는 스트림이나 프리젠테이션이 중단되는 시기를 지정하는 Range 헤더가 포함될 수 있습니다. 우리는 이 지점을 "일시 정지 지점"이라고 부릅니다. 헤더에는 시간 범위가 아닌 정확히 하나의 값이 포함되어야 합니다. 스트림의 일반 재생 시간은 일시 정지 지점으로 설정됩니다. 일시 중지 요청은 서버가 현재 보류 중인 PLAY 요청에 지정된 시점에 처음으로 도달할 때 유효해집니다. Range 헤더가 현재 보류 중인 PLAY 요청 이외의 시간을 지정하면 "457 Invalid Range" 오류가 반환됩니다. 미디어 단위\(예: 오디오 또는 비디오 프레임\)가 정확히 일시 중지 지점에서 프레젠테이션을 시작하면 재생되거나 기록되지 않습니다. Range 헤더가 없으면 메시지 수신 즉시 스트림 전달이 중단되고 일시 중지 지점이 현재 일반 재생 시간으로 설정됩니다.
PAUSE 요청은 대기 중인 모든 PLAY 요청을 삭제합니다. 그러나 미디어 스트림의 일시 중지 지점은 유지되어야 합니다. Range 헤더가 없는 후속 PLAY 요청은 일시 중지 지점에서 다시 시작됩니다.\(MUST\)
예를 들어, 서버에 보류 중인 범위 10\~15 및 20\~29에 대한 재생 요청이 있고 NPT 21에 대한 일시 중지 요청을 받은 경우 두 번째 범위 재생을 시작하고 NPT 21에서 중지합니다. 일시 중지 요청이 NPT 12에 대한 경우 서버가 첫 번째 재생 요청을 처리하는 NPT 13에서 재생 중이면 서버는 즉시 중지됩니다. 일시 중지 요청이 NPT 16에 대한 것인 경우 서버는 첫 번째 요청을 완료한 후 중지됩니다.
재생 요청을 삭제하고 두 번째 재생 요청을 삭제합니다.
또 다른 예로, 서버가 10\~15 범위, 13\~20 범위\(즉, 겹치는 범위\)를 재생하라는 요청을 받은 경우 서버가 첫 번째 범위를 재생하는 동안 NPT=14에 대한 PAUSE 요청이 적용되고 두 번째 범위는 서버가 두 번째 중첩 범위 재생을 시작하기 전에 PAUSE 요청이 도착한다고 가정하면 PLAY 요청이 효과적으로 무시됩니다. PAUSE 요청이 언제 도착하는지에 관계없이 NPT는 14로 설정됩니다.
서버가 Range 헤더에 지정된 시간을 초과하여 이미 데이터를 보낸 경우 클라이언트가 해당 시점 이후에 데이터를 삭제했다고 가정하므로 PLAY는 해당 시점에서 계속 재개됩니다. 이를 통해 공백 없이 지속적인 일시정지/재생 순환이 보장됩니다.
---
## **10.7 TEARDOWN**
TEARDOWN 요청은 지정된 URI에 대한 스트림 전달을 중지하고 이와 관련된 리소스를 해제합니다. URI가 이 프리젠테이션에 대한 프리젠테이션 URI인 경우 세션과 연관된 RTSP 세션 식별자는 더 이상 유효하지 않습니다. 모든 전송 매개변수가 세션 설명에 의해 정의되지 않는 한 세션을 다시 재생하기 전에 SETUP 요청을 발행해야 합니다.
```text
Example:
C->S: TEARDOWN rtsp://example.com/fizzle/foo RTSP/1.0
CSeq: 892
Session: 12345678
S->C: RTSP/1.0 200 OK
CSeq: 892
```
---
## **10.8 GET_PARAMETER**
GET\_PARAMETER 요청은 URI에 지정된 프리젠테이션 또는 스트림의 매개변수 값을 검색합니다. 응답과 응답의 내용은 구현에 달려 있습니다. 엔터티 본문이 없는 GET\_PARAMETER를 사용하여 클라이언트 또는 서버 활성 상태\("ping"\)를 테스트할 수 있습니다.
```text
Example:
S->C: GET_PARAMETER rtsp://example.com/fizzle/foo RTSP/1.0
CSeq: 431
Content-Type: text/parameters
Session: 12345678
Content-Length: 15
packets_received
jitter
C->S: RTSP/1.0 200 OK
CSeq: 431
Content-Length: 46
Content-Type: text/parameters
packets_received: 10
jitter: 0.3838
```
"텍스트/매개변수" 섹션은 매개변수 유형의 예일 뿐입니다. 이 방법은 회신 내용과 응답 내용이 추가 실험 후에 정의될 것이라는 의도로 의도적으로 느슨하게 정의되었습니다.
---
## **10.9 SET_PARAMETER**
이 메소드는 URI로 지정된 프리젠테이션 또는 스트림에 대한 매개변수 값 설정을 요청합니다.
요청에는 클라이언트가 특정 요청이 실패한 이유를 확인할 수 있도록 하는 단일 매개변수만 포함되어야 합니다. 요청에 여러 매개변수가 포함된 경우 서버는 모든 매개변수가 성공적으로 설정될 수 있는 경우에만 요청에 대해 조치를 취해야 합니다. 서버는 매개변수가 동일한 값으로 반복적으로 설정되도록 허용해야 하지만\(MUST\) 매개변수 값 변경을 허용하지 않을 수 있습니다.\(SHOULD, MUST, MUST\)
참고: 미디어 스트림의 전송 매개변수는 SETUP 명령으로만 설정해야 합니다.\(MUST\)
전송 매개변수 설정을 SETUP으로 제한하는 것은 방화벽에 도움이 됩니다.
매개변수는 보다 의미 있는 오류 표시가 있을 수 있도록 세분화된 방식으로 분할됩니다. 그러나 원자성 설정이 필요한 경우 여러 매개변수 설정을 허용하는 것이 합리적일 수 있습니다. 카메라가 동시에 올바른 각도로 기울어지지 않는 한 카메라가 패닝되는 것을 클라이언트가 원하지 않는 장치 제어를 상상해 보십시오.
```text
Example:
C->S: SET_PARAMETER rtsp://example.com/fizzle/foo RTSP/1.0
CSeq: 421
Content-length: 20
Content-type: text/parameters
barparam: barstuff
S->C: RTSP/1.0 451 Invalid Parameter
CSeq: 421
Content-length: 10
Content-type: text/parameters
barparam
```
"텍스트/매개변수" 섹션은 매개변수 유형의 예일 뿐입니다. 이 방법은 회신 내용과 응답 내용이 추가 실험 후에 정의될 것이라는 의도로 의도적으로 느슨하게 정의되었습니다.
---
## **10.10 REDIRECT**
리디렉션 요청은 클라이언트에게 다른 서버 위치에 연결해야 함을 알립니다. 여기에는 클라이언트가 해당 URL에 대한 요청을 발행해야 함을 나타내는 필수 헤더 위치가 포함되어 있습니다. 리디렉션이 적용되는 시기를 나타내는 매개변수 Range가 포함될 수 있습니다. 클라이언트가 이 URI에 대한 미디어를 계속 보내거나 받기를 원하는 경우 클라이언트는 지정된 호스트에서 현재 세션에 대한 TEARDOWN 요청과 새 세션에 대한 SETUP을 발행해야 합니다.\(MUST\)
이 예제 요청은 지정된 재생 시간에 이 URI에 대한 트래픽을 새 서버로 리디렉션합니다.
```text
S->C: REDIRECT rtsp://example.com/fizzle/foo RTSP/1.0
CSeq: 732
Location: rtsp://bigserver.com:8001
Range: clock=19960213T143205Z-
```
---
## **10.11 RECORD**
이 메서드는 프레젠테이션 설명에 따라 다양한 미디어 데이터 기록을 시작합니다. 타임스탬프는 시작 및 종료 시간\(UTC\)을 반영합니다. 시간 범위가 지정되지 않은 경우 프레젠테이션 설명에 제공된 시작 또는 종료 시간을 사용하세요. 세션이 이미 시작된 경우 즉시 녹음을 시작하십시오.
서버는 기록된 데이터를 request-URI 또는 다른 URI에 저장할지 여부를 결정합니다. 서버가 request-URI를 사용하지 않는 경우 응답은 201\(생성됨\)이어야 하며 요청 상태를 설명하고 새 리소스를 참조하는 엔터티와 위치 헤더를 포함해야 합니다.\(SHOULD\)
라이브 프레젠테이션 녹화를 지원하는 미디어 서버는 시계 범위 형식을 지원해야 합니다. smpte 형식은 의미가 없습니다.\(MUST\)
이 예에서 미디어 서버는 이전에 표시된 회의에 초대되었습니다.
```text
C->S: RECORD rtsp://example.com/meeting/audio.en RTSP/1.0
CSeq: 954
Session: 12345678
Conference: 128.16.64.19/32492374
```
---
## **10.12 Embedded (Interleaved) Binary Data**
특정 방화벽 설계 및 기타 상황에서는 서버가 RTSP 방법을 인터리브하고 데이터를 스트리밍하도록 강제할 수 있습니다. 이러한 인터리빙은 클라이언트와 서버 작업을 복잡하게 하고 추가 오버헤드를 부과하므로 필요하지 않는 한 일반적으로 피해야 합니다. 인터리브된 바이너리 데이터는 RTSP가 TCP를 통해 전달되는 경우에만 사용해야 합니다.\(SHOULD\)
RTP 패킷과 같은 스트림 데이터는 ASCII 달러 기호\(24개의 16진수\), 1바이트 채널 식별자, 네트워크 바이트 순서의 2진수 2바이트 정수로 캡슐화된 이진 데이터의 길이로 캡슐화됩니다. 스트림 데이터는 CRLF 없이 바로 뒤따르지만 상위 계층 프로토콜 헤더를 포함합니다. 각 $ 블록에는 정확히 하나의 상위 계층 프로토콜 데이터 단위\(예: 하나의 RTP 패킷\)가 포함됩니다.
채널 식별자는 인터리브 매개변수\(12.39절\)를 사용하여 전송 헤더에 정의됩니다.
전송 선택이 RTP인 경우 RTCP 메시지도 TCP 연결을 통해 서버에 의해 인터리브됩니다. 기본적으로 RTCP 패킷은 RTP 채널보다 높은 첫 번째 사용 가능한 채널에서 전송됩니다. 클라이언트는 다른 채널에서 RTCP 패킷을 명시적으로 요청할 수 있습니다. 이는 전송 헤더의 인터리브 매개변수에 두 개의 채널을 지정하여 수행됩니다\(12.39절\).\(MAY\)
두 개 이상의 스트림이 이러한 방식으로 인터리브되는 경우 동기화를 위해 RTCP가 필요합니다. 또한 이는 네트워크 구성에서 필요할 때 TCP 제어 연결을 통해 RTP/RTCP 패킷을 터널링하고 가능하면 UDP로 전송하는 편리한 방법을 제공합니다.
```text
C->S: SETUP rtsp://foo.com/bar.file RTSP/1.0
CSeq: 2
Transport: RTP/AVP/TCP;interleaved=0-1
S->C: RTSP/1.0 200 OK
CSeq: 2
Date: 05 Jun 1997 18:57:18 GMT
Transport: RTP/AVP/TCP;interleaved=0-1
Session: 12345678
C->S: PLAY rtsp://foo.com/bar.file RTSP/1.0
CSeq: 3
Session: 12345678
S->C: RTSP/1.0 200 OK
CSeq: 3
Session: 12345678
Date: 05 Jun 1997 18:59:15 GMT
RTP-Info: url=rtsp://foo.com/bar.file;
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}
```
---
# **11 Status Code Definitions**
해당되는 경우 HTTP 상태 \[H10\] 코드가 재사용됩니다. 동일한 의미를 갖는 상태 코드는 여기서 반복되지 않습니다. 어떤 요청에 의해 어떤 상태 코드가 반환될 수 있는지 목록은 표 1을 참조하세요.
---
## **11.1 Success 2xx**
---
### **11.1.1 250 Low on Storage Space**
서버는 저장 공간이 부족하여 완전히 수행할 수 없다는 RECORD 요청을 받은 후 이 경고를 반환합니다. 가능하다면 서버는 Range 헤더를 사용하여 아직 기록할 수 있는 기간을 나타내야 합니다. 서버의 다른 프로세스가 동시에 저장 공간을 소비할 수 있으므로 클라이언트는 이를 추정치로만 받아들여야 합니다.
---
## **11.2 Redirection 3xx**
```text
See [H10.3].
```
RTSP 내에서 리디렉션은 로드 밸런싱을 위해 사용되거나 스트림 요청을 위상적으로 클라이언트에 더 가까운 서버로 리디렉션하는 데 사용될 수 있습니다. 위상적 근접성을 결정하는 메커니즘은 이 사양의 범위를 벗어납니다.
---
## **11.3 Client Error 4xx**
---
### **11.3.1 405 Method Not Allowed**
요청에 지정된 메서드는 요청 URI로 식별되는 리소스에 허용되지 않습니다. 응답에는 요청된 리소스에 대한 유효한 메서드 목록이 포함된 Allow 헤더가 포함되어야 합니다. 이 상태 코드는 요청이 SETUP 중에 표시되지 않은 방법을 사용하려고 시도하는 경우에도 사용됩니다. 예를 들어 전송 헤더의 모드 매개변수가 PLAY만 지정했음에도 불구하고 RECORD 요청이 발행된 경우입니다.\(MUST\)
---
### **11.3.2 451 Parameter Not Understood**
요청 수신자가 요청에 포함된 매개변수를 하나 이상 지원하지 않습니다.
---
### **11.3.3 452 Conference Not Found**
컨퍼런스 헤더 필드에 표시된 컨퍼런스는 미디어 서버에서 알 수 없습니다.
---
### **11.3.4 453 Not Enough Bandwidth**
대역폭이 부족하여 요청이 거부되었습니다. 예를 들어 리소스 예약 실패로 인해 발생할 수 있습니다.
---
### **11.3.5 454 Session Not Found**
세션 헤더의 RTSP 세션 식별자가 누락되었거나 유효하지 않거나 시간이 초과되었습니다.
---
### **11.3.6 455 Method Not Valid in This State**
클라이언트나 서버는 현재 상태에서는 이 요청을 처리할 수 없습니다. 오류 복구를 더 쉽게 하기 위해 응답에는 Allow 헤더가 포함되어야 합니다.\(SHOULD\)
---
### **11.3.7 456 Header Field Not Valid for Resource**
서버가 필수 요청 헤더에 대해 작업을 수행할 수 없습니다. 예를 들어 PLAY에 Range 헤더 필드가 포함되어 있지만 스트림이 검색을 허용하지 않는 경우입니다.
---
### **11.3.8 457 Invalid Range**
주어진 범위 값이 범위를 벗어났습니다\(예: 프레젠테이션 끝을 넘어섰습니다\).
---
### **11.3.9 458 Parameter Is Read-Only**
SET\_PARAMETER로 설정할 매개변수는 읽을 수는 있지만 수정할 수는 없습니다.
---
### **11.3.10 459 Aggregate Operation Not Allowed**
해당 URL은 통합\(프레젠테이션\) URL이므로 요청하신 방법이 적용되지 않을 수 있습니다. 이 방법은 스트림 URL에 적용될 수 있습니다.
---
### **11.3.11 460 Only Aggregate Operation Allowed**
해당 URL은 통합\(프레젠테이션\) URL이 아니기 때문에 요청하신 방법이 적용되지 않을 수 있습니다. 이 메소드는 프리젠테이션 URL에 적용될 수 있습니다.
---
### **11.3.12 461 Unsupported Transport**
전송 필드에 지원되는 전송 사양이 포함되어 있지 않습니다.
---
### **11.3.13 462 Destination Unreachable**
클라이언트 주소에 연결할 수 없어 데이터 전송 채널을 설정할 수 없습니다. 이 오류는 클라이언트가 전송 필드에 잘못된 대상 매개변수를 배치하려고 시도한 결과일 가능성이 높습니다.
---
### **11.3.14 551 Option not supported**
필수 또는 프록시 필수 필드에 제공된 옵션이 지원되지 않았습니다. 지원되지 않는 옵션을 나타내는 Unsupported 헤더가 반환되어야 합니다.
---
# **12 Header Field Definitions**
HTTP/1.1 \[2\] 또는 여기에 나열되지 않은 기타 비표준 헤더 필드는 현재 잘 정의된 의미가 없으며 수신자는 무시해야 합니다.\(SHOULD\)
표 3에는 RTSP에서 사용하는 헤더 필드가 요약되어 있습니다. 유형 "g"는 요청과 응답 모두에서 찾을 일반 요청 헤더를 지정하고, 유형 "R"은 요청 헤더를 지정하고, 유형 "r"은 응답 헤더를 지정하고, 유형 "e"는 엔터티 헤더 필드를 지정합니다. "req."로 표시된 필드 "support"라고 표시된 열은 수신자가 특정 방법을 구현해야 하며, "opt"라고 표시된 필드는 반드시 구현해야 합니다. 선택 사항입니다. 모든 필드가 "req"로 표시된 것은 아닙니다. 이 유형의 모든 요청에 전송됩니다. "요구사항" 이는 클라이언트\(응답 헤더의 경우\)와 서버\(요청 헤더의 경우\)만 필드를 구현해야 함을 의미합니다. 마지막 열에는 이 헤더 필드가 의미 있는 방법이 나열되어 있습니다. "엔티티"라는 명칭은 메시지 본문을 반환하는 모든 메서드를 나타냅니다. 이 사양 내에서는 DESCRIBE 및 GET\_PARAMETER가 이 클래스에 속합니다.\(MUST, MUST\)
```text
Header type support methods
Accept R opt. entity
Accept-Encoding R opt. entity
Accept-Language R opt. all
Allow r opt. all
Authorization R opt. all
Bandwidth R opt. all
Blocksize R opt. all but OPTIONS, TEARDOWN
Cache-Control g opt. SETUP
Conference R opt. SETUP
Connection g req. all
Content-Base e opt. entity
Content-Encoding e req. SET_PARAMETER
Content-Encoding e req. DESCRIBE, ANNOUNCE
Content-Language e req. DESCRIBE, ANNOUNCE
Content-Length e req. SET_PARAMETER, ANNOUNCE
Content-Length e req. entity
Content-Location e opt. entity
Content-Type e req. SET_PARAMETER, ANNOUNCE
Content-Type r req. entity
CSeq g req. all
Date g opt. all
Expires e opt. DESCRIBE, ANNOUNCE
From R opt. all
If-Modified-Since R opt. DESCRIBE, SETUP
Last-Modified e opt. entity
Proxy-Authenticate
Proxy-Require R req. all
Public r opt. all
Range R opt. PLAY, PAUSE, RECORD
Range r opt. PLAY, PAUSE, RECORD
Referer R opt. all
Require R req. all
Retry-After r opt. all
RTP-Info r req. PLAY
Scale Rr opt. PLAY, RECORD
Session Rr req. all but SETUP, OPTIONS
Server r opt. all
Speed Rr opt. PLAY
Transport Rr req. SETUP
Unsupported r req. all
User-Agent R opt. all
Via g opt. all
WWW-Authenticate r opt. all
```
RTSP 헤더 필드 개요
---
## **12.1 Accept**
Accept 요청 헤더 필드는 응답에 허용되는 특정 프리젠테이션 설명 콘텐츠 유형을 지정하는 데 사용될 수 있습니다.
프리젠테이션 설명을 위한 "level" 매개변수는 여기가 아닌 MIME 유형 등록의 일부로 올바르게 정의됩니다.
구문은 \[H14.1\]을 참조하세요.
사용 예: Accept: application/rtsl, application/sdp;level=2
---
## **12.2 Accept-Encoding**
```text
See [H14.3]
```
---
## **12.3 Accept-Language**
\[H14.4\]를 참조하세요. 지정된 언어는 미디어 콘텐츠가 아닌 프레젠테이션 설명 및 이유 문구에 적용됩니다.
---
## **12.4 Allow**
허용 응답 헤더 필드에는 요청-URI로 식별된 리소스가 지원하는 메서드가 나열됩니다. 이 필드의 목적은 리소스와 관련된 유효한 방법을 수신자에게 엄격하게 알리는 것입니다. 405\(허용되지 않는 메서드\) 응답에는 Allow 헤더 필드가 있어야 합니다.
사용 예: 허용: SETUP, PLAY, RECORD, SET\_PARAMETER
---
## **12.5 Authorization**
```text
See [H14.8]
```
---
## **12.6 Bandwidth**
대역폭 요청 헤더 필드는 클라이언트가 사용할 수 있는 예상 대역폭을 설명하며 양의 정수로 표시되고 초당 비트 수로 측정됩니다. 클라이언트가 사용할 수 있는 대역폭은 모뎀 재교육 등으로 인해 RTSP 세션 중에 변경될 수 있습니다.
```text
Bandwidth = "Bandwidth" ":" 1*DIGIT
Example:
Bandwidth: 4000
```
---
## **12.7 Blocksize**
이 요청 헤더 필드는 클라이언트에서 미디어 서버로 전송되어 서버에 특정 미디어 패킷 크기를 요청합니다. 이 패킷 크기에는 IP, UDP 또는 RTP와 같은 하위 계층 헤더가 포함되지 않습니다. 서버는 요청된 것보다 작은 블록 크기를 자유롭게 사용할 수 있습니다. 서버는 이 패킷 크기를 최소 미디어별 블록 크기의 가장 가까운 배수로 자르거나 필요한 경우 미디어별 크기로 재정의할 수 있습니다. 블록 크기는 옥텟 단위로 측정된 양의 십진수여야 합니다. 서버는 값이 구문적으로 유효하지 않은 경우에만 오류\(416\)를 반환합니다.\(MAY, MUST\)
---
## **12.8 Cache-Control**
Cache-Control 일반 헤더 필드는 요청/응답 체인을 따라 모든 캐싱 메커니즘이 준수해야 하는 지시문을 지정하는 데 사용됩니다.\(MUST\)
캐시 지시문은 요청/응답 체인을 따라 모든 수신자에게 적용될 수 있으므로 해당 애플리케이션에 대한 중요성에 관계없이 프록시 또는 게이트웨이 애플리케이션을 통해 전달되어야 합니다. 특정 캐시에 대해 캐시 지시어를 지정할 수 없습니다.
Cache-Control은 SETUP 요청과 응답에만 지정되어야 합니다. 참고: Cache-Control은 HTTP와 마찬가지로 응답 캐싱을 관리하지 않고 SETUP 요청으로 식별된 스트림을 관리합니다. DESCRIBE에 대한 응답을 제외하고 RTSP 요청에 대한 응답은 캐시할 수 없습니다.
```text
Cache-Control = "Cache-Control" ":" 1#cache-directive
cache-directive = cache-request-directive
| cache-response-directive
cache-request-directive = "no-cache"
| "max-stale"
| "min-fresh"
| "only-if-cached"
| cache-extension
cache-response-directive = "public"
| "private"
| "no-cache"
| "no-transform"
| "must-revalidate"
| "proxy-revalidate"
| "max-age" "=" delta-seconds
| cache-extension
cache-extension = token [ "=" ( token | quoted-string ) ]
```
캐시 없음:
- 미디어 스트림이 어디에도 캐시되어서는 안 된다는 것을 나타냅니다. 이를 통해 원본 서버는 클라이언트 요청에 대해 오래된 응답을 반환하도록 구성된 캐시에 의한 캐싱도 방지할 수 있습니다.\(MUST NOT\)
공공의:
- 미디어 스트림이 모든 캐시에 의해 캐시될 수 있음을 나타냅니다.
사적인:
- 미디어 스트림이 단일 사용자를 위한 것이며 공유 캐시에 의해 캐시되어서는 안 된다는 것을 나타냅니다. 개인\(비공유\) 캐시는 미디어 스트림을 캐시할 수 있습니다.\(MUST NOT\)
변환 없음:
- 중간 캐시\(프록시\)는 특정 스트림의 미디어 유형을 변환하는 데 유용할 수 있습니다. 예를 들어, 프록시는 캐시 공간을 절약하거나 느린 링크의 트래픽 양을 줄이기 위해 비디오 형식을 변환할 수 있습니다. 그러나 이러한 변환이 특정 종류의 애플리케이션용 스트림에 적용된 경우 심각한 운영 문제가 발생할 수 있습니다. 예를 들어, 의료 영상, 과학 데이터 분석 및 종단 간 인증을 사용하는 응용 프로그램은 모두 원래 엔터티 본문과 비트 단위로 동일한 스트림 수신에 의존합니다. 따라서 응답에 no-transform 지시문이 포함된 경우 중간 캐시 또는 프록시는 스트림의 인코딩을 변경해서는 안 됩니다. HTTP와 달리 RTSP는 이 시점에서 부분적인 변환\(예: 다른 언어로의 번역 허용\)을 제공하지 않습니다.\(MUST NOT\)
캐시된 경우에만:
- 네트워크 연결이 매우 좋지 않은 경우와 같은 경우에 클라이언트는 캐시가 현재 저장한 미디어 스트림만 반환하고 원본 서버로부터 이러한 스트림을 수신하지 않기를 원할 수 있습니다. 이를 위해 클라이언트는 요청에 only-if-cached 지시문을 포함할 수 있습니다. 이 지시문을 수신하면 캐시는 요청의 다른 제약 조건과 일치하는 캐시된 미디어 스트림을 사용하여 응답하거나 504\(Gateway Timeout\) 상태로 응답해야 합니다. 그러나 캐시 그룹이 내부 연결이 양호한 통합 시스템으로 운영되는 경우 그러한 요청은 해당 캐시 그룹 내에서 전달될 수 있습니다.\(SHOULD, MAY\)
최대 부실:
- 클라이언트가 만료 시간을 초과한 미디어 스트림을 수락할 의사가 있음을 나타냅니다. max-stale에 값이 할당되면 클라이언트는 만료 시간을 지정된 초 수만큼 초과하지 않은 응답을 기꺼이 수락합니다. max-stale에 값이 할당되지 않으면 클라이언트는 모든 연령의 오래된 응답을 기꺼이 받아들입니다.
최소 신선도:
- 클라이언트가 최신 수명이 현재 수명에 지정된 시간\(초\)을 더한 것 이상인 미디어 스트림을 수락할 의사가 있음을 나타냅니다. 즉, 클라이언트는 최소한 지정된 시간\(초\) 동안 여전히 신선한 응답을 원합니다.
재검증 필수:
- 캐시가 수신한 SETUP 응답에 must-revalidate 지시문이 있는 경우 해당 캐시는 원서버에서 먼저 재검증하지 않고 후속 요청에 응답하기 위해 항목이 오래 된 후에 해당 항목을 사용해서는 안 됩니다. 즉, 원본 서버의 만료에만 기초하여 캐시된 응답이 오래된 경우 캐시는 매번 엔드투엔드 재검증을 수행해야 합니다.\)\(MUST NOT\)
---
## **12.9 Conference**
이 요청 헤더 필드는 사전 설정된 회의와 RTSP 스트림 간의 논리적 연결을 설정합니다. 동일한 RTSP 세션에 대해 conference-id를 변경하면 안 됩니다.
```text
Conference = "Conference" ":" conference-id Example:
Conference: 199702170042.SAA08642@obiwan.arl.wustl.edu%20Starr
```
컨퍼런스 ID가 유효하지 않으면 응답 코드 452\(452 Conference Not Found\)가 반환됩니다.
---
## **12.10 Connection**
```text
See [H14.10]
```
---
## **12.11 Content-Base**
```text
See [H14.11]
```
---
## **12.12 Content-Encoding**
```text
See [H14.12]
```
---
## **12.13 Content-Language**
```text
See [H14.13]
```
---
## **12.14 Content-Length**
이 필드에는 메소드 내용의 길이가 포함됩니다\(즉, 마지막 헤더 다음에 오는 이중 CRLF 뒤\). HTTP와 달리 메시지의 헤더 부분을 넘어서 콘텐츠를 전달하는 모든 메시지에 포함되어야 합니다. 누락된 경우 기본값은 0으로 간주됩니다. 이는 \[H14.14\]에 따라 해석된다.\(MUST\)
---
## **12.15 Content-Location**
```text
See [H14.15]
```
---
## **12.16 Content-Type**
\[H14.18\]을 참조하세요. RTSP에 적합한 콘텐츠 유형은 실제로 표현 설명 및 매개변수 값 유형으로 제한될 가능성이 높습니다.
---
## **12.17 CSeq**
CSeq 필드는 RTSP 요청-응답 쌍의 시퀀스 번호를 지정합니다. 이 필드는 모든 요청과 응답에 있어야 합니다. 주어진 시퀀스 번호를 포함하는 모든 RTSP 요청에 대해 동일한 번호를 갖는 해당 응답이 있습니다. 재전송된 모든 요청에는 원본과 동일한 시퀀스 번호가 포함되어야 합니다. 즉, 동일한 요청을 재전송할 때 시퀀스 번호가 증가되지 않습니다.\(MUST\)
---
## **12.18 Date**
```text
See [H14.19].
```
---
## **12.19 Expires**
Expires 엔터티 헤더 필드는 설명이나 미디어 스트림이 오래된 것으로 간주되어야 하는 날짜와 시간을 제공합니다. 해석은 방법에 따라 다릅니다.
응답 설명:
- Expires 헤더는 설명이 오래된 것으로 간주되어야 하는 날짜와 시간을 나타냅니다.
오래된 캐시 항목은 원본 서버\(또는 엔터티의 새로운 복사본이 있는 중간 캐시\)에서 먼저 유효성을 검사하지 않는 한 캐시\(프록시 캐시 또는 사용자 에이전트 캐시\)에 의해 일반적으로 반환되지 않을 수 있습니다. 만료 모델에 대한 자세한 내용은 섹션 13을 참조하세요.
Expires 필드가 있다고 해서 원래 리소스가 해당 시점, 이전 또는 이후에 변경되거나 존재하지 않게 된다는 의미는 아닙니다.
형식은 \[H3.3\]의 HTTP-date에 정의된 절대 날짜 및 시간입니다. RFC1123 날짜 형식이어야 합니다.\(MUST\)
```text
Expires = "Expires" ":" HTTP-date
```
그 사용 예는 다음과 같습니다.
```text
Expires: Thu, 01 Dec 1994 16:00:00 GMT
```
RTSP/1.0 클라이언트와 캐시는 특히 값 "0"을 포함한 다른 유효하지 않은 날짜 형식을 과거에 발생한 것으로\(즉, "이미 만료됨"\) 처리해야 합니다.\(MUST\)
응답을 "이미 만료됨"으로 표시하려면 원서버는 Date 헤더 값과 동일한 Expires 날짜를 사용해야 합니다. 응답을 "만료되지 않음"으로 표시하려면 원서버는 응답이 전송된 시점으로부터 약 1년 후의 만료 날짜를 사용해야 합니다. RTSP/1.0 서버는 만료 날짜를 1년 이상 앞으로 보내서는 안 됩니다.
기본적으로 캐시할 수 없는 미디어 스트림에서 미래 특정 시간의 날짜 값을 가진 Expires 헤더 필드가 존재한다는 것은 Cache-Control 헤더 필드에 의해 달리 지정되지 않는 한 미디어 스트림이 캐시 가능하다는 것을 나타냅니다\(섹션 12.8\).
---
## **12.20 From**
```text
See [H14.22].
```
---
## **12.21 Host**
이 HTTP 요청 헤더 필드는 RTSP에는 필요하지 않습니다. 전송되면 조용히 무시되어야 합니다.
---
## **12.22 If-Match**
```text
See [H14.25].
```
이 필드는 RTSP 외부 수단\(예: HTTP\)을 통해 가져오는 경우나 서버 구현이 표현 설명의 무결성을 보장하는 경우 모두 표현 설명의 무결성을 보장하는 데 특히 유용합니다. DESCRIBE 메시지와 SETUP 메시지의 시간.
식별자는 불투명 식별자이므로 특정 세션 설명 언어에 국한되지 않습니다.
---
## **12.23 If-Modified-Since**
If-Modified-Since 요청 헤더 필드는 DESCRIBE 및 SETUP 메소드와 함께 사용되어 조건부로 만듭니다. 이 필드에 지정된 시간 이후 요청된 변형이 수정되지 않은 경우 서버에서 설명이 반환되지 않거나\(DESCRIBE\) 스트림이 설정되지 않습니다\(SETUP\). 대신 메시지 본문 없이 304\(수정되지 않음\) 응답이 반환됩니다.
```text
If-Modified-Since = "If-Modified-Since" ":" HTTP-date
```
필드의 예는 다음과 같습니다.
```text
If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
```
---
## **12.24 Last-Modified**
Last-Modified 엔터티 헤더 필드는 원서버가 프레젠테이션 설명이나 미디어 스트림이 마지막으로 수정되었다고 믿는 날짜와 시간을 나타냅니다. \[H14.29\]를 참조하세요. DESCRIBE 또는 ANNOUNCE 메소드의 경우 헤더 필드는 설명의 마지막 수정 날짜 및 시간을 나타내고 SETUP의 경우 미디어 스트림의 설명을 나타냅니다.
---
## **12.25 Location**
```text
See [H14.30].
```
---
## **12.26 Proxy-Authenticate**
```text
See [H14.33].
```
---
## **12.27 Proxy-Require**
Proxy-Require 헤더는 프록시에서 반드시 지원해야 하는 프록시 관련 기능을 나타내는 데 사용됩니다. 프록시가 지원하지 않는 모든 Proxy-Require 헤더 기능은 지원되지 않는 경우 프록시가 클라이언트에 대해 부정적으로 승인해야 합니다. 서버\(MUST, MUST\)
이 필드를 필수 필드와 동일하게 처리해야 합니다.
이 메시지의 메커니즘과 사용 예에 대한 자세한 내용은 섹션 12.32를 참조하세요.
---
## **12.28 Public**
```text
See [H14.35].
```
---
## **12.29 Range**
이 요청 및 응답 헤더 필드는 시간 범위를 지정합니다. 범위는 여러 단위로 지정할 수 있습니다. 이 사양은 smpte\(섹션 3.5\), npt\(섹션 3.6\) 및 clock\(섹션 3.7\) 범위 단위를 정의합니다. RTSP 내에서 바이트 범위 \[H14.36.1\]은 의미가 없으며 사용되어서는 안 됩니다. 헤더에는 작업이 적용되는 시간을 지정하는 UTC의 시간 매개변수가 포함될 수도 있습니다. Range 헤더를 지원하는 서버는 NPT 범위 형식을 이해해야 하며 SMPTE 범위 형식을 이해해야 합니다. Range 응답 헤더는 실제로 재생되거나 녹음되는 시간 범위를 나타냅니다. Range 헤더가 이해되지 않는 시간 형식으로 제공되면 수신자는 "501 Not Implemented"를 반환해야 합니다.\(MUST NOT, MUST\)
범위는 하위 지점을 포함하지만 상위 지점을 제외한 반 개방 구간입니다. 즉, a-b의 범위는 정확히 a 시간에 시작하지만 b 직전에 중지됩니다. 비디오나 오디오 프레임과 같은 미디어 단위의 시작 시간만 관련됩니다. 예를 들어 비디오 프레임이 40ms마다 생성된다고 가정합니다. 10.0-10.1 범위에는 10.0 이상에서 시작하는 비디오 프레임이 포함되며, 간격을 넘어 지속되더라도 10.08에서 시작하는 비디오 프레임이 포함됩니다. 반면에 10.0-10.08 범위는 10.08의 프레임을 제외합니다.
```text
Range = "Range" ":" 1\#ranges-specifier
[ ";" "time" "=" utc-time ]
ranges-specifier = npt-range | utc-range | smpte-range
Example:
Range: clock=19960213T143205Z-;time=19970123T143720Z
```
표기법은 HTTP/1.1\[2\] 바이트 범위 헤더에 사용된 표기법과 유사합니다. 이를 통해 클라이언트는 미디어 개체에서 발췌한 부분을 선택하고, 특정 지점에서 끝까지 재생할 수 있으며, 현재 위치에서 특정 지점까지 재생할 수 있습니다. 서버가 연장된 유휴 기간 동안 서버 리소스 유지를 거부할 수도 있지만 재생 시작은 향후 언제든지 예약할 수 있습니다.
---
## **12.30 Referer**
\[H14.37\]을 참조하세요. URL은 일반적으로 HTTP를 통해 검색되는 프레젠테이션 설명의 URL을 나타냅니다.
---
## **12.31 Retry-After**
```text
See [H14.38].
```
---
## **12.32 Require**
Require 헤더는 클라이언트가 지원하거나 지원하지 않을 수 있는 옵션에 대해 서버에 쿼리하는 데 사용됩니다. 서버는 지원되지 않는 옵션을 부정적으로 승인하기 위해 Unsupported 헤더를 사용하여 이 헤더에 응답해야 합니다.\(MUST\)
이는 양쪽이 모든 옵션을 이해하면 클라이언트-서버 상호 작용이 지체 없이 진행되고, 옵션이 이해되지 않는 경우에만 속도가 느려지도록 하기 위한 것입니다\(위의 경우처럼\). 잘 일치하는 클라이언트-서버 쌍의 경우 상호 작용이 빠르게 진행되어 협상 메커니즘에 필요한 왕복 시간이 절약됩니다. 또한 클라이언트가 서버가 이해하지 못하는 기능을 요구할 때 상태 모호성을 제거합니다.
```text
Require = "Require" ":" 1#option-tag
Example:
C->S: SETUP rtsp://server.com/foo/bar/baz.rm RTSP/1.0
CSeq: 302
Require: funky-feature
Funky-Parameter: funkystuff
S->C: RTSP/1.0 551 Option not supported
CSeq: 302
Unsupported: funky-feature
C->S: SETUP rtsp://server.com/foo/bar/baz.rm RTSP/1.0
CSeq: 303
S->C: RTSP/1.0 200 OK
CSeq: 303
```
이 예에서 "funky-feature"는 가상의 Funky-Parameter 필드가 필요함을 클라이언트에 나타내는 기능 태그입니다. "funky-feature"와 Funky-Parameter 사이의 관계는 RTSP 교환을 통해 전달되지 않습니다. 왜냐하면 해당 관계는 "funky-feature"의 불변 속성이므로 모든 교환을 통해 전송되어서는 안 되기 때문입니다.
프록시 및 기타 중개 장치는 이 필드에서 이해되지 않는 기능을 무시해야 합니다\(SHOULD\). 특정 확장이 중간 장치의 지원을 요구하는 경우, 확장은 대신 Proxy-Require 필드에 태그를 지정해야 합니다\(섹션 12.27 참조\).\(SHOULD\)
---
## **12.33 RTP-Info**
이 필드는 PLAY 응답에서 RTP 관련 매개변수를 설정하는 데 사용됩니다.
URL:
- 다음 RTP 매개변수에 해당하는 스트림 URL을 나타냅니다.
순서:
- 스트림의 첫 번째 패킷의 시퀀스 번호를 나타냅니다. 이를 통해 클라이언트는 탐색 시 패킷을 우아하게 처리할 수 있습니다. 클라이언트는 이 값을 사용하여 검색 이전에 발생한 패킷과 검색 이후에 발생한 패킷을 구별합니다.
RTP시간:
- 범위 응답 헤더의 시간 값에 해당하는 RTP 타임스탬프를 나타냅니다. \(참고: 집합 제어의 경우 특정 스트림은 반환되거나 암시된 범위 시간 값에 대해 실제로 패킷을 생성하지 않을 수 있습니다. 따라서 seq로 표시된 시퀀스 번호가 있는 패킷이 실제로 rtptime으로 표시된 타임스탬프를 갖는다는 보장은 없습니다.\) 클라이언트는 이 값을 사용하여 RTP 시간과 NPT의 매핑을 계산합니다.
RTP 타임스탬프에서 NTP 타임스탬프\(벽시계\)로의 매핑은 RTCP를 통해 가능합니다. 그러나 이 정보는 RTP 타임스탬프에서 NPT로의 매핑을 생성하는 데 충분하지 않습니다. 또한 이 정보를 필요한 시간\(시작 시 또는 검색 후 즉시\)에 사용할 수 있고 안정적으로 전달되도록 하기 위해 이 매핑은 RTSP 제어 채널에 배치됩니다.
길고 중단되지 않는 프레젠테이션의 드리프트를 보상하기 위해 RTSP 클라이언트는 초기 RTCP 발신자 보고서를 사용하여 매핑을 수행하고 이후 보고서를 사용하여 매핑에 대한 드리프트를 확인하여 NPT를 NTP에 추가로 매핑해야 합니다.
```text
Syntax:
RTP-Info = "RTP-Info" ":" 1#stream-url 1*parameter
stream-url = "url" "=" url
parameter = ";" "seq" "=" 1*DIGIT
| ";" "rtptime" "=" 1*DIGIT
Example:
RTP-Info: url=rtsp://foo.com/bar.avi/streamid=0;seq=45102,
url=rtsp://foo.com/bar.avi/streamid=1;seq=30211
```
---
## **12.34 Scale**
스케일 값 1은 일반 앞으로 보기 속도로 일반 재생 또는 녹화를 나타냅니다. 1이 아닌 경우, 해당 값은 일반 시청률에 대한 비율에 해당합니다. 예를 들어 비율 2는 일반 시청률의 두 배\("빨리 감기"\)를 나타내고 비율 0.5는 일반 시청률의 절반을 나타냅니다. 즉, 비율이 2이면 벽시계 속도의 두 배로 정상적인 재생 시간이 증가합니다. 경과된\(벽시계\) 시간 1초마다 2초의 콘텐츠가 전달됩니다. 음수 값은 반대 방향을 나타냅니다.
Speed 매개변수에서 달리 요청하지 않는 한 데이터 속도는 변경되어서는 안 됩니다. 규모 변경 구현은 서버 및 미디어 유형에 따라 다릅니다. 비디오의 경우 서버는 예를 들어 키 프레임만 전달하거나 선택한 키 프레임을 전달할 수 있습니다. 오디오의 경우 피치를 유지하면서 오디오 시간 규모를 조정할 수도 있고, 바람직하지 않지만 오디오 조각을 전달할 수도 있습니다.\(SHOULD\)
서버는 시청률을 대략적으로 계산하려고 시도해야 하지만 지원하는 배율 값의 범위를 제한할 수 있습니다. 응답에는 서버가 선택한 실제 스케일 값이 포함되어야 합니다.\(MUST\)
요청에 Range 매개변수가 포함되어 있으면 해당 시점에 새 배율 값이 적용됩니다.
```text
Scale = "Scale" ":" [ "-" ] 1*DIGIT [ "." *DIGIT ]
```
정상 속도의 3.5배로 역방향 재생의 예:
```text
Scale: -3.5
```
---
## **12.35 Speed**
이 요청 헤더 필드 매개변수는 서버의 능력과 특정 속도로 미디어 스트림을 제공하려는 욕구에 따라 특정 속도로 클라이언트에 데이터를 전달하도록 서버에 요청합니다. 서버에 의한 구현은 선택사항입니다. 기본값은 스트림의 비트 전송률입니다.\(MAY\)
매개변수 값은 소수점 비율로 표현됩니다. 예를 들어 값 2.0은 데이터가 평소보다 두 배 빠르게 전달된다는 것을 나타냅니다. 0의 속도는 유효하지 않습니다. 요청에 Range 매개변수가 포함된 경우 해당 시점에 새 속도 값이 적용됩니다.
```text
Speed = "Speed" ":" 1*DIGIT [ "." *DIGIT ]
Example:
Speed: 2.5
```
이 필드를 사용하면 데이터 전달에 사용되는 대역폭이 변경됩니다. 더 높거나 낮은 속도로 프레젠테이션을 미리 봐야 하는 특정 상황에서 사용하기 위한 것입니다. 구현자는 세션의 대역폭이 사전에\(RTSP 이외의 수단으로\) 협상될 수 있으므로 재협상이 필요할 수 있다는 점을 명심해야 합니다. 데이터가 UDP를 통해 전달되는 경우 RTCP와 같은 수단을 사용하여 패킷 손실률을 추적하는 것이 좋습니다.
---
## **12.36 Server**
```text
See [H14.39]
```
---
## **12.37 Session**
이 요청 및 응답 헤더 필드는 SETUP 응답에서 미디어 서버에 의해 시작되고 프레젠테이션 URL에서 TEARDOWN에 의해 종료되는 RTSP 세션을 식별합니다. 세션 식별자는 미디어 서버에 의해 선택됩니다\(섹션 3.4 참조\). 클라이언트가 세션 식별자를 수신하면 해당 세션과 관련된 모든 요청에 대해 이를 반환해야 합니다. 동적으로 생성된 URL과 같이 세션을 식별하는 다른 방법이 있는 경우 서버는 세션 식별자를 설정할 필요가 없습니다.\(MUST\)
```text
Session = "Session" ":" session-id [ ";" "timeout" "=" delta-seconds ]
```
timeout 매개변수는 응답 헤더에서만 허용됩니다. 서버는 이를 사용하여 활동 부족으로 인해 세션을 닫기 전에 서버가 RTSP 명령 사이에서 대기할 준비가 된 시간을 클라이언트에 나타냅니다\(섹션 A 참조\). 시간 초과는 다음으로 측정됩니다.
초, 기본값은 60초\(1분\)입니다.
세션 식별자는 전송 세션 또는 연결 전체에서 RTSP 세션을 식별합니다. 둘 이상의 RTSP URL에 대한 제어 메시지는 단일 RTSP 세션 내에서 전송될 수 있습니다. 따라서 모든 스트림이 동일한 서버에서 나오는 한 클라이언트는 프레젠테이션을 구성하는 많은 스트림을 제어하기 위해 동일한 세션을 사용할 수 있습니다. \(섹션 14의 예 참조\) 그러나 동일한 클라이언트의 동일한 URL에 대한 여러 "사용자" 세션은 서로 다른 세션 식별자를 사용해야 합니다.\(MUST\)
동일한 클라이언트에서 오는 동일한 URL에 대한 여러 전달 요청을 구별하려면 세션 식별자가 필요합니다.
세션 식별자가 유효하지 않으면 응답 454\(세션을 찾을 수 없음\)가 반환됩니다.
---
## **12.38 Timestamp**
타임스탬프 일반 헤더는 클라이언트가 서버에 요청을 보낸 시기를 설명합니다. 타임스탬프의 값은 클라이언트에게만 중요하며 모든 시간 척도를 사용할 수 있습니다. 서버는 정확히 동일한 값을 반영해야 하며 이에 대한 정확한 정보가 있는 경우 요청을 수신한 후 경과된 시간\(초\)을 나타내는 부동 소수점 숫자를 추가할 수 있습니다. 타임스탬프는 클라이언트가 서버에 대한 왕복 시간을 계산하여 재전송에 대한 시간 초과 값을 조정할 때 사용됩니다.\(MUST\)
```text
Timestamp = "Timestamp" ":" *(DIGIT) [ "." *(DIGIT) ] [ delay ]
delay = *(DIGIT) [ "." *(DIGIT) ]
```
---
## **12.39 Transport**
이 요청 헤더는 사용할 전송 프로토콜을 나타내며 대상 주소, 압축, 멀티캐스트 TTL\(Time to Live\) 및 단일 스트림에 대한 대상 포트와 같은 매개변수를 구성합니다. 프리젠테이션 설명에 의해 아직 결정되지 않은 값을 설정합니다.
전송은 쉼표로 구분되어 선호도 순서대로 나열됩니다. 매개변수는 세미콜론으로 구분하여 각 전송에 추가할 수 있습니다.
Transport 헤더는 특정 전송 매개변수를 변경하는 데에도 사용될 수 있습니다. 서버는 기존 스트림의 매개변수 변경을 거부할 수 있습니다.\(MAY, MAY\)
서버는 실제로 선택된 값을 나타내기 위해 응답에 전송 응답 헤더를 반환할 수 있습니다.\(MAY\)
전송 요청 헤더 필드에는 클라이언트가 허용하는 전송 옵션 목록이 포함될 수 있습니다. 이 경우 서버는 실제로 선택된 단일 옵션을 반환해야 합니다.\(MUST\)
전송 지정자의 구문은 다음과 같습니다.
```text
transport/profile/lower-transport.
```
"lower-transport" 매개변수의 기본값은 프로필에 따라 다릅니다. RTP/AVP의 경우 기본값은 UDP입니다.
다음은 전송과 관련된 구성 매개변수입니다.
```text
General parameters:
```
유니캐스트 | 멀티캐스트:
- 유니캐스트 또는 멀티캐스트 전달이 시도되는지 여부에 대한 상호 배타적 표시입니다. 기본값은 멀티캐스트입니다. 유니캐스트와 멀티캐스트 전송을 모두 처리할 수 있는 클라이언트는 각각에 대해 별도의 매개변수가 있는 두 개의 전체 전송 사양을 포함하여 이러한 기능을 나타내야 합니다.\(MUST\)
목적지:
- 스트림이 전송될 주소입니다. 클라이언트는 대상 매개변수를 사용하여 멀티캐스트 주소를 지정할 수 있습니다. 원격 제어 서비스 거부 공격의 무의식적인 가해자가 되는 것을 방지하려면 서버는 클라이언트를 인증해야 하며 클라이언트가 서버가 선택하지 않은 주소로 미디어 스트림을 보낼 수 있도록 허용하기 전에 그러한 시도를 기록해야 합니다. 이는 RTSP 명령이 UDP를 통해 실행되는 경우 특히 중요하지만 구현에서는 TCP 자체를 클라이언트 식별의 안정적인 수단으로 사용할 수 없습니다. 서버는 클라이언트가 명령이 나오는 주소와 다른 주소로 미디어 스트림을 보내는 것을 허용해서는 안 됩니다.\(SHOULD, SHOULD\)
원천:
- 스트림의 소스 주소가 RTSP 엔드포인트 주소\(재생 중인 서버 또는 녹음 중인 클라이언트\)에서 파생될 수 있는 주소와 다른 경우 소스를 지정할 수 있습니다.\(MAY\)
이 정보는 SDP를 통해서도 제공될 수 있습니다. 그러나 이는 미디어 초기화라기보다는 전송 기능에 가깝기 때문에 이 정보에 대한 신뢰할 수 있는 소스는 SETUP 응답에 있어야 합니다.
레이어:
- 이 미디어 스트림에 사용될 멀티캐스트 레이어 수입니다. 레이어는 대상 주소에서 시작하여 연속적인 주소로 전송됩니다.
방법:
- 모드 매개변수는 이 세션에 대해 지원되는 방법을 나타냅니다. 유효한 값은 PLAY 및 RECORD입니다. 제공되지 않은 경우 기본값은 PLAY입니다.
추가:
- mode 매개변수에 RECORD가 포함된 경우, 추가 매개변수는 미디어 데이터가 기존 리소스를 덮어쓰는 대신 기존 리소스에 추가되어야 함을 나타냅니다. 추가가 요청되고 서버가 이를 지원하지 않는 경우에는 URI로 식별된 리소스를 덮어쓰는 대신 요청을 거부해야 합니다. mode 매개변수에 RECORD가 포함되어 있지 않으면 추가 매개변수가 무시됩니다.\(MUST\)
인터리브됨:
- 인터리브 매개변수는 섹션 10.12에 정의된 메커니즘을 사용하여 제어 스트림이 사용하는 프로토콜에 관계없이 미디어 스트림을 제어 스트림과 혼합하는 것을 의미합니다. 인수는 $ 문에 사용할 채널 번호를 제공합니다. 이 매개변수는 미디어 스트림에 대한 전송 선택이 요구하는 경우 interleaved=4-5와 같이 범위로 지정될 수 있습니다.
이를 통해 RTP/RTCP는 UDP에서 수행되는 방식과 유사하게 처리될 수 있습니다. 즉, 한 채널은 RTP용이고 다른 채널은 RTCP용입니다.
```text
Multicast specific:
ttl:
multicast time-to-live
RTP Specific:
```
포트:
- 이 매개변수는 멀티캐스트 세션에 대한 RTP/RTCP 포트 쌍을 제공합니다. 범위로 지정됩니다\(예: port=3456-3457\).
클라이언트\_포트:
- 이 매개변수는 클라이언트가 미디어 데이터 및 제어 정보를 수신하기 위해 선택한 유니캐스트 RTP/RTCP 포트 쌍을 제공합니다. 이는 범위로 지정됩니다\(예: client\_port=3456-3457\).
서버 포트:
- 이 매개변수는 서버가 미디어 데이터 및 제어 정보를 수신하기 위해 선택한 유니캐스트 RTP/RTCP 포트 쌍을 제공합니다. 범위로 지정됩니다\(예: server\_port=3456-3457\).
SSRC:
- ssrc 매개변수는 RTP SSRC를 나타냅니다. \[24, Sec. 3\] 미디어 서버에서 사용해야 하거나\(요청\) 사용하게 될\(응답\) 값입니다. 이 매개변수는 유니캐스트 전송에만 유효합니다. 미디어 스트림과 연결될 동기화 소스를 식별합니다.
```text
Transport = "Transport" ":"
1\#transport-spec
transport-spec = transport-protocol/profile[/lower-transport]
*parameter
transport-protocol = "RTP"
profile = "AVP"
lower-transport = "TCP" | "UDP"
parameter = ( "unicast" | "multicast" )
| ";" "destination" [ "=" address ]
| ";" "interleaved" "=" channel [ "-" channel ]
| ";" "append"
| ";" "ttl" "=" ttl
| ";" "layers" "=" 1*DIGIT
| ";" "port" "=" port [ "-" port ]
| ";" "client_port" "=" port [ "-" port ]
| ";" "server_port" "=" port [ "-" port ]
| ";" "ssrc" "=" ssrc
| ";" "mode" = <"> 1\#mode <">
ttl = 1*3(DIGIT)
port = 1*5(DIGIT)
ssrc = 8*8(HEX)
channel = 1*3(DIGIT)
address = host
mode = <"> *Method <"> | Method
Example:
Transport: RTP/AVP;multicast;ttl=127;mode="PLAY",
RTP/AVP;unicast;client_port=3456-3457;mode="PLAY"
```
Transport 헤더는 단일 RTP 스트림을 설명하는 것으로 제한됩니다. \(RTSP는 여러 스트림을 단일 엔터티로 제어할 수도 있습니다.\) 다양한 세션 설명 형식에 의존하는 대신 이를 RTSP의 일부로 만들면 방화벽 설계가 크게 단순화됩니다.
---
## **12.40 Unsupported**
지원되지 않는 응답 헤더에는 서버에서 지원하지 않는 기능이 나열됩니다. Proxy-Require 필드\(섹션 12.32\)를 통해 기능이 지정된 경우, 클라이언트와 서버 사이의 경로에 프록시가 있으면 프록시는 "551 Option Not Supported"라는 오류 메시지가 포함된 메시지 응답을 삽입해야 합니다. ".\(MUST\)
사용 예는 섹션 12.32를 참조하세요.
---
## **12.41 User-Agent**
```text
See [H14.42]
```
---
## **12.42 Vary**
```text
See [H14.43]
```
---
## **12.43 Via**
```text
See [H14.44].
```
---
## **12.44 WWW-Authentica**
```text
See [H14.46].
```
---
# **13 Caching**
HTTP에서는 응답-요청 쌍이 캐시됩니다. RTSP는 그 점에서 크게 다릅니다. DESCRIBE에서 반환되거나 ANNOUNCE에 포함된 프레젠테이션 설명을 제외하고 응답은 캐시할 수 없습니다. \(DESCRIBE 및 GET\_PARAMETER 이외의 것에 대한 응답은 데이터를 반환하지 않으므로 이러한 요청에 대한 캐싱은 실제로 문제가 되지 않습니다.\) 그러나 일반적으로 RTSP와 관련하여 대역 외로 전달되는 지속적인 미디어 데이터의 경우 바람직합니다. 세션 설명과 함께 캐시됩니다.
SETUP 또는 PLAY 요청을 받으면 프록시는 연속 미디어 콘텐츠와 해당 설명의 최신 복사본이 있는지 확인합니다. 각각 SETUP 또는 DESCRIBE 요청을 실행하고 Last-Modified 헤더를 캐시된 복사본의 헤더와 비교하여 복사본이 최신인지 확인할 수 있습니다. 복사본이 최신이 아닌 경우 SETUP 전송 매개변수를 적절하게 수정하고 요청을 원본 서버로 전달합니다. PLAY 또는 PAUSE와 같은 후속 제어 명령은 수정되지 않은 프록시를 전달합니다. 프록시는 지속적인 미디어 데이터를 클라이언트에 전달하는 동시에 나중에 재사용할 수 있도록 로컬 복사본을 만들 수도 있습니다. 캐시에 허용되는 정확한 동작은 캐시 응답 지시문에 의해 제공됩니다.
섹션 12.8에 설명되어 있습니다. 캐시는 현재 요청자에게 스트림을 제공하고 있는 경우 모든 DESCRIBE 요청에 응답해야 합니다. 스트림 설명의 하위 수준 세부 정보가 원본 서버에서 변경되었을 수 있기 때문입니다.\(MUST\)
RTSP 캐시는 HTTP 캐시와 달리 "컷스루\(cut-through\)" 종류에 속합니다. 캐시는 원본 서버에서 전체 리소스를 검색하는 대신 클라이언트로 전달되는 스트리밍 데이터를 단순히 복사합니다. 따라서 추가 대기 시간이 발생하지 않습니다.
클라이언트에게는 RTSP 프록시 캐시가 일반 미디어 서버처럼 나타나고 미디어 원본 서버에서는 클라이언트처럼 나타납니다. HTTP 캐시가 캐시하는 개체에 대한 콘텐츠 유형, 콘텐츠 언어 등을 저장해야 하는 것처럼 미디어 캐시는 프레젠테이션 설명을 저장해야 합니다. 일반적으로 캐시는 프레젠테이션 설명에서 모든 전송 참조\(즉, 멀티캐스트 정보\)를 제거합니다. 이는 캐시에서 클라이언트로의 데이터 전달과 독립적이기 때문입니다. 인코딩에 대한 정보는 동일하게 유지됩니다. 캐시가 캐시된 미디어 데이터를 변환할 수 있다면 캐시가 제공할 수 있는 모든 인코딩 가능성을 갖춘 새로운 프레젠테이션 설명을 생성하게 됩니다.
---
# **14 Examples**
다음 예에서는 RTSL과 같이 표준이 아닌 스트림 설명 형식을 참조합니다. 다음 예는 해당 형식에 대한 참조로 사용되지 않습니다.
---
## **14.1 Media on Demand (Unicast)**
클라이언트 C는 미디어 서버 A\( audio.example.com\) 및 V\(video.example.com\)에서 영화를 요청합니다. 미디어 설명은 웹 서버 W에 저장됩니다. 미디어 설명에는 사용 가능한 코덱, 동적 RTP 페이로드 유형, 프로토콜 스택, 언어 또는 저작권 제한과 같은 콘텐츠 정보를 포함하여 프레젠테이션과 모든 스트림에 대한 설명이 포함됩니다. 또한 영화의 타임라인에 대한 정보를 제공할 수도 있습니다.
이 예에서 클라이언트는 영화의 마지막 부분에만 관심이 있습니다.
```text
C->W: GET /twister.sdp HTTP/1.1
Host: www.example.com
Accept: application/sdp
W->C: HTTP/1.0 200 OK
Content-Type: application/sdp
v=0
o=- 2890844526 2890842807 IN IP4 192.16.24.202
s=RTSP Session
m=audio 0 RTP/AVP 0
a=control:rtsp://audio.example.com/twister/audio.en
m=video 0 RTP/AVP 31
a=control:rtsp://video.example.com/twister/video
C->A: SETUP rtsp://audio.example.com/twister/audio.en RTSP/1.0
CSeq: 1
Transport: RTP/AVP/UDP;unicast;client_port=3056-3057
A->C: RTSP/1.0 200 OK
CSeq: 1
Session: 12345678
Transport: RTP/AVP/UDP;unicast;client_port=3056-3057;
server_port=5000-5001
C->V: SETUP rtsp://video.example.com/twister/video RTSP/1.0
CSeq: 1
Transport: RTP/AVP/UDP;unicast;client_port=3058-3059
V->C: RTSP/1.0 200 OK
CSeq: 1
Session: 23456789
Transport: RTP/AVP/UDP;unicast;client_port=3058-3059;
server_port=5002-5003
C->V: PLAY rtsp://video.example.com/twister/video RTSP/1.0
CSeq: 2
Session: 23456789
Range: smpte=0:10:00-
V->C: RTSP/1.0 200 OK
CSeq: 2
Session: 23456789
Range: smpte=0:10:00-0:20:00
RTP-Info: url=rtsp://video.example.com/twister/video;
seq=12312232;rtptime=78712811
C->A: PLAY rtsp://audio.example.com/twister/audio.en RTSP/1.0
CSeq: 2
Session: 12345678
Range: smpte=0:10:00-
A->C: RTSP/1.0 200 OK
CSeq: 2
Session: 12345678
Range: smpte=0:10:00-0:20:00
RTP-Info: url=rtsp://audio.example.com/twister/audio.en;
seq=876655;rtptime=1032181
C->A: TEARDOWN rtsp://audio.example.com/twister/audio.en RTSP/1.0
CSeq: 3
Session: 12345678
A->C: RTSP/1.0 200 OK
CSeq: 3
C->V: TEARDOWN rtsp://video.example.com/twister/video RTSP/1.0
CSeq: 3
Session: 23456789
V->C: RTSP/1.0 200 OK
CSeq: 3
```
오디오 및 비디오 트랙이 두 개의 서로 다른 서버에 있고 약간 다른 시간에 시작하고 서로에 대해 표류할 수 있더라도 클라이언트는 표준 RTP 방법, 특히 RTCP 발신자에 포함된 시간 척도를 사용하여 둘을 동기화할 수 있습니다. 보고서.
---
## **14.2 Streaming of a Container file**
이 예의 목적에 따라 컨테이너 파일은 동일한 최종 사용자 프리젠테이션과 관련된 여러 연속 미디어 유형이 존재하는 저장 엔터티입니다. 실제로 컨테이너 파일은 각 구성 요소가 RTSP 스트림인 RTSP 프레젠테이션을 나타냅니다. 컨테이너 파일은 이러한 프레젠테이션을 저장하는 데 널리 사용되는 수단입니다. 구성 요소는 독립적인 스트림으로 전송되지만 서버 측에서는 해당 스트림에 대한 공통 컨텍스트를 유지하는 것이 바람직합니다.
이를 통해 서버는 단일 저장소 핸들을 쉽게 열어 둘 수 있습니다. 또한 서버에서 스트림 우선순위를 지정하는 경우 모든 스트림을 동일하게 처리할 수 있습니다.
프리젠테이션 작성자는 결합된 미디어 프리젠테이션의 예술적 효과를 보존하기 위해 클라이언트가 스트림을 선택적으로 검색하는 것을 방지하기를 원할 수도 있습니다. 마찬가지로, 이렇게 긴밀하게 바인딩된 프레젠테이션에서는 집계 URL을 사용하는 단일 제어 메시지를 통해 모든 스트림을 제어할 수 있는 것이 바람직합니다.
다음은 단일 RTSP 세션을 사용하여 여러 스트림을 제어하는 예입니다. 또한 집계 URL의 사용을 보여줍니다.
클라이언트 C는 미디어 서버 M에 프레젠테이션을 요청합니다. 동영상은 컨테이너 파일에 저장됩니다. 클라이언트가 컨테이너 파일에 대한 RTSP URL을 얻었습니다.
```text
C->M: DESCRIBE rtsp://foo/twister RTSP/1.0
CSeq: 1
M->C: RTSP/1.0 200 OK
CSeq: 1
Content-Type: application/sdp
Content-Length: 164
v=0
o=- 2890844256 2890842807 IN IP4 172.16.2.93
s=RTSP Session
i=An Example of RTSP Session Usage
a=control:rtsp://foo/twister
t=0 0
m=audio 0 RTP/AVP 0
a=control:rtsp://foo/twister/audio
m=video 0 RTP/AVP 26
a=control:rtsp://foo/twister/video
C->M: SETUP rtsp://foo/twister/audio RTSP/1.0
CSeq: 2
Transport: RTP/AVP;unicast;client_port=8000-8001
M->C: RTSP/1.0 200 OK
CSeq: 2
Transport: RTP/AVP;unicast;client_port=8000-8001;
server_port=9000-9001
Session: 12345678
C->M: SETUP rtsp://foo/twister/video RTSP/1.0
CSeq: 3
Transport: RTP/AVP;unicast;client_port=8002-8003
Session: 12345678
M->C: RTSP/1.0 200 OK
CSeq: 3
Transport: RTP/AVP;unicast;client_port=8002-8003;
server_port=9004-9005
Session: 12345678
C->M: PLAY rtsp://foo/twister RTSP/1.0
CSeq: 4
Range: npt=0-
Session: 12345678
M->C: RTSP/1.0 200 OK
CSeq: 4
Session: 12345678
RTP-Info: url=rtsp://foo/twister/video;
seq=9810092;rtptime=3450012
C->M: PAUSE rtsp://foo/twister/video RTSP/1.0
CSeq: 5
Session: 12345678
M->C: RTSP/1.0 460 Only aggregate operation allowed
CSeq: 5
C->M: PAUSE rtsp://foo/twister RTSP/1.0
CSeq: 6
Session: 12345678
M->C: RTSP/1.0 200 OK
CSeq: 6
Session: 12345678
C->M: SETUP rtsp://foo/twister RTSP/1.0
CSeq: 7
Transport: RTP/AVP;unicast;client_port=10000
M->C: RTSP/1.0 459 Aggregate operation not allowed
CSeq: 7
```
첫 번째 실패 사례에서 클라이언트는 프레젠테이션의 한 스트림\(이 경우 비디오\)을 일시 중지하려고 시도합니다. 이는 서버의 해당 프레젠테이션에 허용되지 않습니다. 두 번째 경우에는 집합 URL이 SETUP에 사용되지 않을 수 있으며 전송 매개변수를 설정하려면 스트림당 하나의 제어 메시지가 필요합니다.
이는 전송 헤더의 구문을 단순하게 유지하고 방화벽을 통해 전송 정보를 쉽게 구문 분석할 수 있게 해줍니다.
---
## **14.3 Single Stream Container Files**
일부 RTSP 서버는 모든 파일을 "컨테이너 파일"인 것처럼 처리할 수 있지만 다른 서버는 이러한 개념을 지원하지 않을 수 있습니다. 이 때문에 클라이언트는 일관된 URL이 항상 사용될 수 있다고 가정하기보다는 요청 URL에 대한 세션 설명에 명시된 규칙을 사용해야 합니다. 다음은 멀티 스트림 서버가 단일 스트림 파일이 제공될 것으로 예상하는 방법에 대한 예입니다.\(SHOULD\)
```text
Accept: application/x-rtsp-mh, application/sdp
CSeq: 1
S->C RTSP/1.0 200 OK
CSeq: 1
Content-base: rtsp://foo.com/test.wav/
Content-type: application/sdp
Content-length: 48
v=0
o=- 872653257 872653257 IN IP4 172.16.2.187
s=mu-law wave file
i=audio test
t=0 0
m=audio 0 RTP/AVP 0
a=control:streamid=0
C->S SETUP rtsp://foo.com/test.wav/streamid=0 RTSP/1.0
Transport: RTP/AVP/UDP;unicast;
client_port=6970-6971;mode=play
CSeq: 2
S->C RTSP/1.0 200 OK
Transport: RTP/AVP/UDP;unicast;client_port=6970-6971;
server_port=6970-6971;mode=play
CSeq: 2
Session: 2034820394
C->S PLAY rtsp://foo.com/test.wav RTSP/1.0
CSeq: 3
Session: 2034820394
S->C RTSP/1.0 200 OK
CSeq: 3
Session: 2034820394
RTP-Info: url=rtsp://foo.com/test.wav/streamid=0;
seq=981888;rtptime=3781123
```
SETUP 명령에서 다른 URL을 확인한 다음 PLAY 명령에서 집계 URL로 다시 전환하십시오. 이는 집계 제어가 가능한 여러 스트림이 있는 경우 완전히 의미가 있지만 스트림 수가 1개인 특수한 경우에는 직관적이지 않습니다.
이 특별한 경우에는 서버에서 다음을 보내는 구현을 허용하는 것이 좋습니다.
```text
C->S PLAY rtsp://foo.com/test.wav/streamid=0 RTSP/1.0
CSeq: 3
```
최악의 경우 서버는 다음을 다시 보내야 합니다.
```text
S->C RTSP/1.0 460 Only aggregate operation allowed
CSeq: 3
```
또한 서버 구현에서 다음 사항도 허용되기를 바랍니다.
```text
C->S SETUP rtsp://foo.com/test.wav RTSP/1.0
Transport: rtp/avp/udp;client_port=6970-6971;mode=play
CSeq: 2
```
이 파일에는 단일 스트림만 있으므로 이것이 의미하는 바는 모호하지 않습니다.
---
## **14.4 Live Media Presentation Using Multicast**
미디어 서버 M은 멀티캐스트 주소와 포트를 선택합니다. 여기서는 웹 서버가 전체 설명에 대한 포인터만 포함하고 미디어 서버 M이 전체 설명을 유지한다고 가정합니다.
```text
C->W: GET /concert.sdp HTTP/1.1
Host: www.example.com
W->C: HTTP/1.1 200 OK
Content-Type: application/x-rtsl
<session>
<track src="rtsp://live.example.com/concert/audio">
</session>
C->M: DESCRIBE rtsp://live.example.com/concert/audio RTSP/1.0
CSeq: 1
M->C: RTSP/1.0 200 OK
CSeq: 1
Content-Type: application/sdp
Content-Length: 44
v=0
o=- 2890844526 2890842807 IN IP4 192.16.24.202
s=RTSP Session
m=audio 3456 RTP/AVP 0
a=control:rtsp://live.example.com/concert/audio
c=IN IP4 224.2.0.1/16
C->M: SETUP rtsp://live.example.com/concert/audio RTSP/1.0
CSeq: 2
Transport: RTP/AVP;multicast
M->C: RTSP/1.0 200 OK
CSeq: 2
Transport: RTP/AVP;multicast;destination=224.2.0.1;
port=3456-3457;ttl=16
Session: 0456804596
C->M: PLAY rtsp://live.example.com/concert/audio RTSP/1.0
CSeq: 3
Session: 0456804596
M->C: RTSP/1.0 200 OK
CSeq: 3
Session: 0456804596
```
---
## **14.5 Playing media into an existing session**
회의 참가자 C는 미디어 서버 M이 기존 회의에서 데모 테이프를 재생하도록 하려고 합니다. C는 네트워크 주소와 암호화 키가 회의에서 이미 제공되었으므로 서버에서 선택해서는 안 된다는 것을 미디어 서버에 나타냅니다. 이 예에서는 간단한 ACK 응답을 생략했습니다.
```text
C->M: DESCRIBE rtsp://server.example.com/demo/548/sound RTSP/1.0
CSeq: 1
Accept: application/sdp
M->C: RTSP/1.0 200 1 OK
Content-type: application/sdp
Content-Length: 44
v=0
o=- 2890844526 2890842807 IN IP4 192.16.24.202
s=RTSP Session
i=See above
t=0 0
m=audio 0 RTP/AVP 0
C->M: SETUP rtsp://server.example.com/demo/548/sound RTSP/1.0
CSeq: 2
Transport: RTP/AVP;multicast;destination=225.219.201.15;
port=7000-7001;ttl=127
Conference: 199702170042.SAA08642@obiwan.arl.wustl.edu%20Starr
M->C: RTSP/1.0 200 OK
CSeq: 2
Transport: RTP/AVP;multicast;destination=225.219.201.15;
port=7000-7001;ttl=127
Session: 91389234234
Conference: 199702170042.SAA08642@obiwan.arl.wustl.edu%20Starr
C->M: PLAY rtsp://server.example.com/demo/548/sound RTSP/1.0
CSeq: 3
Session: 91389234234
M->C: RTSP/1.0 200 OK
CSeq: 3
```
---
## **14.6 Recording**
회의 참가자 클라이언트 C는 미디어 서버 M에게 회의의 오디오 및 비디오 부분을 녹음하도록 요청합니다. 클라이언트는 ANNOUNCE 메소드를 사용하여 녹화된 세션에 대한 메타 정보를 서버에 제공합니다.
```text
C->M: ANNOUNCE rtsp://server.example.com/meeting RTSP/1.0
CSeq: 90
Content-Type: application/sdp
Content-Length: 121
v=0
o=camera1 3080117314 3080118787 IN IP4 195.27.192.36
s=IETF Meeting, Munich - 1
i=The thirty-ninth IETF meeting will be held in Munich, Germany
u=http://www.ietf.org/meetings/Munich.html
e=IETF Channel 1 <ietf39-mbone@uni-koeln.de>
p=IETF Channel 1 +49-172-2312 451
c=IN IP4 224.0.1.11/127
t=3080271600 3080703600
a=tool:sdr v2.4a6
a=type:test
m=audio 21010 RTP/AVP 5
c=IN IP4 224.0.1.11/127
a=ptime:40
m=video 61010 RTP/AVP 31
c=IN IP4 224.0.1.12/127
M->C: RTSP/1.0 200 OK
CSeq: 90
C->M: SETUP rtsp://server.example.com/meeting/audiotrack RTSP/1.0
CSeq: 91
Transport: RTP/AVP;multicast;destination=224.0.1.11;
port=21010-21011;mode=record;ttl=127
M->C: RTSP/1.0 200 OK
CSeq: 91
Session: 50887676
Transport: RTP/AVP;multicast;destination=224.0.1.11;
port=21010-21011;mode=record;ttl=127
C->M: SETUP rtsp://server.example.com/meeting/videotrack RTSP/1.0
CSeq: 92
Session: 50887676
Transport: RTP/AVP;multicast;destination=224.0.1.12;
port=61010-61011;mode=record;ttl=127
M->C: RTSP/1.0 200 OK
CSeq: 92
Transport: RTP/AVP;multicast;destination=224.0.1.12;
port=61010-61011;mode=record;ttl=127
C->M: RECORD rtsp://server.example.com/meeting RTSP/1.0
CSeq: 93
Session: 50887676
Range: clock=19961110T1925-19961110T2015
M->C: RTSP/1.0 200 OK
CSeq: 93
```
---
# **15 Syntax**
RTSP 구문은 RFC 2068 \[2\]에서 사용되는 증강된 BNF\(Backus-Naur 형식\)로 설명됩니다.
---
## **15.1 Base Syntax**
```text
OCTET = <any 8-bit sequence of data>
CHAR = <any US-ASCII character (octets 0 - 127)>
UPALPHA = <any US-ASCII uppercase letter "A".."Z">
LOALPHA = <any US-ASCII lowercase letter "a".."z">
ALPHA = UPALPHA | LOALPHA
DIGIT = <any US-ASCII digit "0".."9">
CTL = <any US-ASCII control character
(octets 0 - 31) and DEL (127)>
CR = <US-ASCII CR, carriage return (13)>
LF = <US-ASCII LF, linefeed (10)>
SP = <US-ASCII SP, space (32)>
HT = <US-ASCII HT, horizontal-tab (9)>
<"> = <US-ASCII double-quote mark (34)>
CRLF = CR LF
LWS = [CRLF] 1*( SP | HT )
TEXT = <any OCTET except CTLs>
tspecials = "(" | ")" | "<" | ">" | "@"
| "," | ";" | ":" | "\" | <">
| "/" | "[" | "]" | "?" | "="
| "{" | "}" | SP | HT
token = 1*<any CHAR except CTLs or tspecials>
quoted-string = ( <"> *(qdtext) <"> )
qdtext = <any TEXT except <">>
quoted-pair = "\" CHAR
message-header = field-name ":" [ field-value ] CRLF
field-name = token
field-value = *( field-content | LWS )
field-content = <the OCTETs making up the field-value and
consisting of either *TEXT or
combinations of token, tspecials, and
quoted-string>
safe = "\$" | "-" | "_" | "." | "+"
extra = "!" | "*" | "$'$" | "(" | ")" | ","
hex = DIGIT | "A" | "B" | "C" | "D" | "E" | "F" |
"a" | "b" | "c" | "d" | "e" | "f"
escape = "\%" hex hex
reserved = ";" | "/" | "?" | ":" | "@" | "&" | "="
unreserved = alpha | digit | safe | extra
xchar = unreserved | reserved | escape
```
---
# **16 Security Considerations**
RTSP 서버와 HTTP 서버 간의 구문 및 사용법이 유사하기 때문에 \[H15\]에 설명된 보안 고려 사항이 적용됩니다. 구체적으로 다음 사항에 유의하시기 바랍니다.
인증 메커니즘:
- RTSP와 HTTP는 공통된 인증 방식을 공유하므로 인증과 관련하여 동일한 규정을 따라야 합니다. 클라이언트 인증 문제는 \[H15.1\]을, 다중 인증 메커니즘 지원 관련 문제는 \[H15.2\]를 참조하세요.
서버 로그 정보 남용:
- RTSP와 HTTP 서버는 아마도 유사한 로깅 메커니즘을 가질 것이므로 해당 로그의 내용을 보호하는 데 있어 동등하게 보호되어야 합니다.
서버 사용자. HTTP 서버에 대해서는 \[H15.3\]을 참조하세요.
- 서버 로그에 관한 권장 사항.
민감한 정보의 전송:
- RTSP를 통해 전송되는 정보가 일반적으로 HTTP를 통해 전송되는 정보보다 덜 민감할 수 있다고 믿을 이유가 없습니다. 따라서 데이터 개인 정보 보호 및 사용자 개인 정보 보호에 관한 모든 예방 조치는 RTSP 클라이언트, 서버 및 프록시 구현자에게 적용됩니다. 자세한 내용은 \[H15.4\]를 참조하세요.
파일 및 경로 이름을 기반으로 한 공격:
- RTSP URL은 반드시 파일 시스템 의미를 가질 필요는 없는 불투명 핸들이지만 많은 구현에서는 요청 URL의 일부를 파일 시스템 호출로 직접 변환할 것으로 예상됩니다. 이러한 경우 파일 시스템은 경로 구성 요소에서 ".."를 확인하는 것과 같이 \[H15.5\]에 설명된 예방 조치를 따라야 합니다.\(SHOULD\)
개인 정보:
- RTSP 클라이언트는 종종 HTTP 클라이언트와 동일한 정보\(사용자 이름, 위치 등\)를 갖고 있으므로 동일해야 합니다. 추가 권장사항은 \[H15.6\]을 참조하세요.
수락 헤더와 관련된 개인 정보 보호 문제:
- HTTP와 마찬가지로 RTSP에도 동일한 "Accept" 헤더가 존재할 수 있으므로 사용과 관련하여 \[H15.7\]에 설명된 동일한 주의 사항을 따라야 합니다.
DNS 스푸핑:
- 아마도 HTTP 세션에 비해 RTSP 세션과 관련된 연결 시간이 더 길다는 점을 고려하면 RTSP 클라이언트 DNS 최적화는 덜 일반적일 것입니다. 그럼에도 불구하고 \[H15.8\]에 제공된 권장 사항은 매핑의 단일 사용 이상을 유지하기 위해 DNS-to-IP 매핑에 의존하려는 모든 구현과 여전히 관련이 있습니다.
```text
Location Headers and Spoofing:
If a single server supports multiple organizations that do not
trust one another, then it must check the values of Location
and Content-Location headers in responses that are generated
under control of said organizations to make sure that they do
not attempt to invalidate resources over which they have no
authority. ([H15.9])
```
현재 HTTP 사양\(이 글을 쓰는 시점의 RFC 2068 \[2\]\)의 권장 사항 외에도 향후 HTTP 사양에서는 보안 문제에 대한 추가 지침을 제공할 수 있습니다.
다음은 RTSP 구현에 대한 추가 고려 사항입니다.
집중된 서비스 거부 공격:
- 프로토콜은 원격 제어 서비스 거부 공격 기회를 제공합니다. 공격자는 SETUP 요청에서 하나 이상의 IP 주소를 대상으로 지정하여 트래픽 흐름을 시작할 수 있습니다. 이 경우 공격자의 IP 주소가 알려질 수 있지만 추가 공격을 방지하거나 공격자의 신원을 확인하는 데 항상 유용한 것은 아닙니다. 따라서 RTSP 서버는 서버가 RTSP 인증 메커니즘\(다이제스트 인증 또는 더 강력한 방법 선호\)을 사용하는 알려진 사용자 데이터베이스 또는 기타 보안 수단에 대해 클라이언트의 신원을 확인한 경우 RTSP 시작 트래픽 흐름에 대한 클라이언트 지정 대상만 허용해야 합니다. .\(SHOULD\)
세션 하이재킹:
- 전송 계층 연결과 RTSP 세션 사이에는 아무런 관련이 없기 때문에 악의적인 클라이언트가 의심하지 않는 클라이언트에 영향을 미칠 수 있는 임의 세션 식별자를 사용하여 요청을 발행할 수 있습니다. 서버는 이런 종류의 공격 가능성을 최소화하기 위해 대규모의 무작위 비순차적 세션 식별자를 사용해야 합니다.\(SHOULD\)
입증:
- 서버는 기본 인증과 다이제스트\[8\] 인증을 모두 구현해야 합니다. 제어 메시지에 대해 더 엄격한 보안이 필요한 환경에서는 RTSP 제어 스트림이 암호화될 수 있습니다.\(SHOULD\)
스트림 문제:
- RTSP는 스트림 제어만 제공합니다. 스트림 전달 문제는 이 섹션이나 이 메모의 나머지 부분에서 다루지 않습니다. RTSP 구현은 RTP, IP 멀티캐스트, RSVP 및 IGMP와 같은 다른 프로토콜에 의존할 가능성이 높으며 이러한 프로토콜 및 기타 적용 가능한 사양에서 제기된 보안 고려 사항을 해결해야 합니다.
지속적으로 의심스러운 행동:
- RTSP 서버는 보안 위험으로 간주되는 단일 동작 인스턴스를 수신하면 오류 코드 403\(금지됨\)을 반환해야 합니다. RTSP 서버는 또한 서버의 약점과 진입점을 조사하려는 시도를 인식해야 하며 로컬 보안 정책을 위반하는 것으로 간주되는 클라이언트의 추가 요청을 임의로 연결 해제하고 무시할 수 있습니다.\(SHOULD, SHOULD\)
---
# **Appendix A: RTSP Protocol State Machines**
RTSP 클라이언트 및 서버 상태 시스템은 RTSP 세션 초기화부터 RTSP 세션 종료까지 프로토콜의 동작을 설명합니다.
상태는 개체별로 정의됩니다. 개체는 스트림 URL과 RTSP 세션 식별자로 고유하게 식별됩니다. 여러 스트림으로 구성된 RTSP 프레젠테이션을 나타내는 집계 URL을 사용하는 모든 요청/응답은 모든 스트림의 개별 상태에 영향을 미칩니다. 예를 들어, 프리젠테이션 /movie에 /movie/audio 및 /movie/video라는 두 개의 스트림이 포함된 경우 다음 명령은 다음과 같습니다.
```text
PLAY rtsp://foo.com/movie RTSP/1.0
CSeq: 559
Session: 12345678
```
영화/오디오 및 영화/비디오 상태에 영향을 미칩니다.
이 예는 URL의 스트림이나 파일 시스템과의 관계를 나타내는 표준 방법을 의미하지 않습니다. 섹션 3.2를 참조하세요.
OPTIONS, ANNOUNCE, DESCRIBE, GET\_PARAMETER, SET\_PARAMETER 요청은 클라이언트 또는 서버 상태에 영향을 미치지 않으므로 상태 테이블에 나열되지 않습니다.
---
## **A.1 Client State Machine**
클라이언트는 다음과 같은 상태를 가정할 수 있습니다.
초기화:
- SETUP이 전송되었으며 응답을 기다리고 있습니다.
준비가 된:
- 재생 상태에서 SETUP 응답을 받거나 PAUSE 응답을 받았습니다.
```text
Playing:
PLAY reply received
Recording:
RECORD reply received
```
일반적으로 클라이언트는 요청에 대한 응답을 받으면 상태를 변경합니다. 일부 요청은 미래의 시간이나 위치\(예: PAUSE\)에 유효하며 그에 따라 상태도 변경됩니다. 객체에 대해 명시적인 SETUP이 필요하지 않은 경우\(예:
멀티캐스트 그룹을 통해 사용 가능\) 상태는 준비에서 시작됩니다. 이 경우에는 준비\(Ready\)와 재생\(Playing\)의 두 가지 상태만 있습니다. 또한 클라이언트는 요청된 범위의 끝에 도달하면 상태를 재생/녹음에서 준비로 변경합니다.
"다음 상태" 열은 성공 응답\(2xx\)을 수신한 후 가정된 상태를 나타냅니다. 요청에서 상태 코드 3xx가 생성되면 상태는 Init가 되고, 상태 코드 4xx는 상태에 변화가 없습니다. 각 상태에 대해 나열되지 않은 메시지는 위에 나열된 대로 상태에 영향을 주지 않는 메시지를 제외하고 해당 상태의 클라이언트에 의해 발행되어서는 안 됩니다. 서버에서 REDIRECT를 수신하는 것은 서버에서 3xx 리디렉션 상태를 수신하는 것과 같습니다.\(MUST NOT\)
```text
state message sent next state after response
Init SETUP Ready
TEARDOWN Init
Ready PLAY Playing
RECORD Recording
TEARDOWN Init
SETUP Ready
Playing PAUSE Ready
TEARDOWN Init
PLAY Playing
SETUP Playing (changed transport)
Recording PAUSE Ready
TEARDOWN Init
RECORD Recording
SETUP Recording (changed transport)
```
---
## **A.2 Server State Machine**
서버는 다음과 같은 상태를 가정할 수 있습니다.
초기화:
- 초기 상태에서는 유효한 SETUP이 아직 수신되지 않았습니다.
준비가 된:
- 마지막으로 받은 SETUP이 성공하여 응답이 전송되었습니다. 또는 재생 후 마지막으로 PAUSE가 성공적으로 수신되어 응답이 전송되었습니다.
놀이:
- 마지막으로 받은 PLAY가 성공적으로 수신되었으며 응답이 전송되었습니다. 데이터가 전송되고 있습니다.
녹음:
- 서버가 미디어 데이터를 녹화하고 있습니다.
일반적으로 서버는 요청을 받으면 상태를 변경합니다. 서버가 재생 또는 녹음 상태이고 유니캐스트 모드인 경우 정의된 간격 동안 클라이언트로부터 RTCP 보고서 또는 RTSP 명령과 같은 "웰니스" 정보를 수신하지 못한 경우 Init로 되돌아가 RTSP 세션을 종료할 수 있습니다. , 기본값은 1분입니다. 서버는 세션 응답 헤더에서 다른 시간 초과 값을 선언할 수 있습니다\(12.37절\). 서버가 Ready 상태인 경우, 1분 이상 간격으로 RTSP 요청을 받지 못하면 Init으로 되돌아갈 수 있습니다. 일부 요청\(예: PAUSE\)은 미래의 시간이나 위치에 적용될 수 있으며 서버 상태는 적절한 시간에 변경됩니다. 서버는 클라이언트가 요청한 범위의 끝에서 재생 중 또는 녹음 상태에서 준비 상태로 되돌아갑니다.\(MAY, MAY\)
REDIRECT 메시지는 전송 시 리디렉션이 유효한 시기를 지정하는 Range 헤더가 없으면 즉시 적용됩니다. 이러한 경우 서버 상태도 적절한 시점에 변경됩니다.
개체에 대해 명시적인 SETUP이 필요하지 않은 경우 상태는 Ready에서 시작되며 Ready와 Playing의 두 가지 상태만 있습니다.
"다음 상태" 열은 성공 응답\(2xx\)을 보낸 후 가정된 상태를 나타냅니다. 요청 결과 상태 코드 3xx가 발생하면 상태는 Init가 됩니다. 상태 코드 4xx는 변경되지 않습니다.
```text
state message received next state
Init SETUP Ready
TEARDOWN Init
Ready PLAY Playing
SETUP Ready
TEARDOWN Init
RECORD Recording
Playing PLAY Playing
PAUSE Ready
TEARDOWN Init
SETUP Playing
Recording RECORD Recording
PAUSE Ready
TEARDOWN Init
SETUP Recording
```
---
# **Appendix B: Interaction with RTP**
RTSP를 사용하면 미디어 클라이언트가 미디어 프리젠테이션의 선택된 비연속 섹션을 제어하고 RTP 미디어 계층을 사용하여 해당 스트림을 렌더링할 수 있습니다\[24\]. RTP 스트림을 렌더링하는 미디어 계층은 NPT의 점프에 영향을 받아서는 안 됩니다. 따라서 RTP 시퀀스 번호와 RTP 타임스탬프는 모두 NPT 점프에서 연속적이고 단조로워야 합니다.\(MUST\)
예를 들어, 클록 주파수가 8000Hz, 패킷화 간격이 100ms, 초기 시퀀스 번호와 타임스탬프가 0이라고 가정합니다. 먼저 NPT 10\~15를 재생한 다음 앞으로 건너뛰고 NPT 18\~20을 재생합니다. 첫 번째 세그먼트는 시퀀스 번호 0\~49와 타임스탬프 0\~39,200이 있는 RTP 패킷으로 표시됩니다. 두 번째 세그먼트는 시퀀스 번호 50\~69, 타임스탬프 40,000\~55,200의 RTP 패킷으로 구성됩니다.
두 개가 독립적인 프로세스일 수 있으므로 RTSP 클라이언트가 RTP 미디어 에이전트와 통신할 수 있다고 가정할 수 없습니다. RTP 타임스탬프가 NPT와 동일한 간격을 표시하는 경우 미디어 에이전트는 프레젠테이션에 일시 중지가 있다고 가정합니다. NPT의 점프가 충분히 크면 RTP 타임스탬프가 롤오버될 수 있으며 미디어 에이전트는 이후의 패킷이 방금 재생된 패킷의 중복이라고 믿을 수 있습니다.
특정 데이터 유형의 경우 RTSP 계층과 RTP 계층 간의 긴밀한 통합이 필요합니다. 이는 결코 위의 제한을 배제하지 않습니다. 결합된 RTSP/RTP 미디어 클라이언트는 RTP-Info 필드를 사용하여 수신 RTP 패킷이 검색 전 또는 후에 전송되었는지 확인해야 합니다.
지속적인 오디오의 경우 서버는 새로운 PLAY 요청 제공 시작 시 RTP 마커 비트를 설정해야 합니다. 이를 통해 클라이언트는 재생 지연 적응을 수행할 수 있습니다.\(SHOULD\)
스케일링\(섹션 12.34 참조\)의 경우 RTP 타임스탬프는 재생 타이밍과 일치해야 합니다. 예를 들어, 2배율과 1배속\(섹션 12.35\)으로 초당 30프레임으로 녹화된 비디오를 재생할 때 서버는 프레임당 3,000의 일반 타임스탬프 간격으로 비디오 패킷을 유지하고 전달하기 위해 매초마다 프레임을 삭제합니다. NPT는 각 비디오 프레임마다 1/15초씩 증가합니다.
클라이언트는 재배치 후 도착하는 첫 번째 패킷의 RTP 타임스탬프 값을 확인하여 NPT의 올바른 표시를 유지할 수 있습니다. RTP-Info\(12.33절\) 헤더의 시퀀스 매개변수는 다음 세그먼트의 첫 번째 시퀀스 번호를 제공합니다.
---
# **Appendix C: Use of SDP for RTSP Session Descriptions**
세션 설명 프로토콜\(SDP, RFC 2327 \[6\]\)은 RTSP의 스트림이나 프리젠테이션을 설명하는 데 사용될 수 있습니다. 이러한 사용은 다음에 대한 액세스 및 인코딩 수단을 지정하는 것으로 제한됩니다.
집계 제어:
- 집계 제어에 사용할 수 없는 하나 이상의 서버의 스트림으로 구성된 프리젠테이션입니다. 이러한 설명은 일반적으로 HTTP 또는 기타 비RTSP 수단을 통해 검색됩니다. 그러나 ANNOUNCE 메소드를 사용하여 수신될 수 있습니다.
비집계 제어:
- 통합 제어가 가능한 단일 서버의 여러 스트림으로 구성된 프리젠테이션입니다. 이러한 설명은 일반적으로 URL에 대한 DESCRIBE 요청에 대한 응답으로 반환되거나 ANNOUNCE 메서드로 수신됩니다.
이 부록에서는 예를 들어 HTTP를 통해 검색된 SDP 파일이 RTSP 세션의 작동을 결정하는 방법을 설명합니다. 또한 클라이언트가 DESCRIBE 요청에 대한 응답으로 반환된 SDP 콘텐츠를 해석하는 방법도 설명합니다. SDP는 클라이언트가 사람의 안내 없이 동시에 렌더링할 여러 미디어 스트림과 대안 집합\(예: 서로 다른 언어로 사용되는 두 개의 오디오 스트림\)을 구별할 수 있는 메커니즘을 제공하지 않습니다.
---
## **C.1 Definitions**
이 부록에 사용된 "세션 수준", "미디어 수준"이라는 용어와 기타 키/속성 이름 및 값은 SDP\(RFC 2327 \[6\]\)에 정의된 대로 사용됩니다.
---
### **C.1.1 Control URL**
"a=control:" 속성은 제어 URL을 전달하는 데 사용됩니다. 이 속성은 세션 및 미디어 설명 모두에 사용됩니다. 개별 미디어에 사용되는 경우 해당 특정 미디어 스트림을 제어하는 데 사용되는 URL을 나타냅니다. 세션 수준에서 발견된 경우 속성은 집계 제어를 위한 URL을 나타냅니다.
```text
Example:
a=control:rtsp://example.com/foo
```
이 속성에는 RFC 1808 \[25\]에 명시된 규칙 및 규칙에 따라 상대 URL과 절대 URL이 포함될 수 있습니다. 구현에서는 다음 순서로 기본 URL을 찾아야 합니다.
1. RTSP Content-Base 필드 2. RTSP Content-Location 필드 3. RTSP 요청 URL
이 속성에 별표\(\*\)만 포함된 경우 URL은 비어 있는 내장 URL인 것처럼 처리되므로 전체 기본 URL을 상속합니다.
---
### **C.1.2 Media streams**
"m=" 필드는 스트림을 열거하는 데 사용됩니다. 지정된 모든 스트림이 적절한 동기화를 통해 렌더링될 것으로 예상됩니다. 세션이 유니캐스트인 경우 포트 번호는 서버에서 클라이언트로의 권장 사항 역할을 합니다. 클라이언트는 여전히 이를 SETUP 요청에 포함해야 하며 이 권장 사항을 무시할 수 있습니다. 서버에 기본 설정이 없으면 포트 번호 값을 0으로 설정해야 합니다.\(SHOULD\)
```text
Example:
m=audio 0 RTP/AVP 31
```
---
### **C.1.3 Payload type(s)**
페이로드 유형은 "m=" 필드에 지정됩니다. 페이로드 유형이 RFC 1890 \[1\]의 정적 페이로드 유형인 경우 다른 정보가 필요하지 않습니다. 동적 페이로드 유형인 경우 미디어 속성 "rtpmap"을 사용하여 미디어가 무엇인지 지정합니다. "rtpmap" 속성 내의 "인코딩 이름"은 RFC 1890\(섹션 5 및 6\)에 지정된 것 중 하나이거나 SDP\(RFC 2327 \[6\]\)에 지정된 "X-" 접두사가 있는 실험적 인코딩일 수 있습니다. 코덱별 매개변수는 이 필드에 지정되지 않고 아래 설명된 "fmtp" 속성에 지정됩니다. 새로운 인코딩을 등록하려는 구현자는 RFC 1890 \[1\]의 절차를 따라야 합니다. 미디어 유형이 RTP AV 프로필에 적합하지 않은 경우 새 프로필을 생성하고 "m=" 필드에 "RTP/AVP" 대신 적절한 프로필 이름을 사용하는 것이 좋습니다.
---
### **C.1.4 Format-specific parameters**
형식별 매개변수는 "fmtp" 미디어 속성을 사용하여 전달됩니다. "fmtp" 속성의 구문은 속성이 참조하는 인코딩에 따라 다릅니다. 패킷화 간격은 "ptime" 속성을 사용하여 전달됩니다.
---
### **C.1.5 Range of presentation**
"a=range" 속성은 저장된 세션의 총 시간 범위를 정의합니다. \(라이브 세션의 길이는 "t" 및 "r" 매개변수에서 추론할 수 있습니다.\) 프레젠테이션에 다양한 기간의 미디어 스트림이 포함되어 있지 않으면 범위 속성은 세션 수준 속성입니다. 단위가 먼저 지정되고 그 뒤에 값 범위가 지정됩니다. 단위와 그 값은 섹션 3.5, 3.6 및 3.7에 정의되어 있습니다.
```text
Examples:
a=range:npt=0-34.4368
a=range:clock=19971113T2115-19971113T2203
```
---
### **C.1.6 Time of availability**
"t=" 필드에는 집계 및 비집계 스트림 제어 모두에 대한 시작 및 중지 시간에 적합한 값이 포함되어야 합니다. 집계 제어를 사용하면 서버는 설명이 유효함을 보장하는 중지 시간 값과 DESCRIBE 요청이 수신된 시간과 같거나 그 이전의 시작 시간을 표시해야 합니다. 또한 시작 및 중지 시간을 0으로 표시할 수도 있습니다. 이는 세션이 항상 사용 가능함을 의미합니다. 비집계 제어의 경우 값은 SDP 의미 체계에 따라 세션을 사용할 수 있는 실제 기간을 반영해야 하며 이 목적을 위해 다른 수단\(예: 설명이 포함된 웹 페이지의 수명\)에 의존해서는 안 됩니다.\(MUST, SHOULD, MAY\)
---
### **C.1.7 Connection Information**
SDP에서 "c=" 필드에는 미디어 스트림의 대상 주소가 포함됩니다. 그러나 주문형 유니캐스트 스트림 및 일부 멀티캐스트 스트림의 경우 클라이언트가 SETUP 요청을 통해 대상 주소를 지정합니다. 미디어 콘텐츠에 고정된 대상 주소가 없으면 "c=" 필드는 적절한 null 값으로 설정됩니다. "IP4" 유형의 주소의 경우 이 값은 "0.0.0.0"입니다.
```text
C.1.8 Entity Tag
```
선택적 "a=etag" 속성은 세션 설명의 버전을 식별합니다. 클라이언트에게는 불투명합니다. SETUP 요청은 이 속성 값이 현재 설명의 값과 여전히 일치하는 경우에만 세션 설정을 허용하기 위해 If-Match 필드\(12.22절 참조\)에 이 식별자를 포함할 수 있습니다. 속성 값은 불투명하며 SDP 속성 값 내에서 허용되는 모든 문자를 포함할 수 있습니다.
```text
Example:
a=etag:158bb3e7c7fd62ce67f12b533f06b83a
```
"o=" 필드가 동일한 기능을 제공한다고 주장할 수도 있습니다. 그러나 이는 동일한 미디어 콘텐츠에 대해 SDP 이외의 여러 세션 설명 유형을 지원해야 하는 서버에 제약을 가하는 방식으로 수행됩니다.
---
## **C.2 Aggregate Control Not Available**
프레젠테이션이 집계 제어를 지원하지 않고 여러 미디어 섹션이 지정된 경우 각 섹션에는 "a=control:" 속성을 통해 지정된 제어 URL이 있어야 합니다.\(MUST\)
예: v=0 o=- 2890844256 2890842807 IN IP4 204.34.34.32 s=웹페이지에서 왔습니다 t=0 0 c=IN IP4 0.0.0.0 m=video 8002 RTP/AVP 31 a=control:rtsp:// audio.com/movie.aud m=audio 8004 RTP/AVP 3 a=control:rtsp://video.com/movie.vid
설명에서 제어 URL의 위치는 클라이언트가 audio.com 및 video.com 서버에 대해 별도의 RTSP 제어 세션을 설정한다는 것을 의미합니다.
RTSP가 아닌 수단을 통해 미디어 클라이언트에 전달되더라도 SDP 파일에는 완전한 미디어 초기화 정보가 포함되어 있는 것이 좋습니다. 클라이언트가 DESCRIBE를 통해 더 자세한 미디어 스트림 정보를 요청해야 함을 나타내는 메커니즘이 없기 때문에 이는 필요합니다.
---
## **C.3 Aggregate Control Available**
이 시나리오에서 서버에는 전체적으로 제어할 수 있는 여러 스트림이 있습니다. 이 경우 스트림 URL을 지정하는 데 사용되는 미디어 수준 "a=control:" 속성과 집계 제어를 위한 요청 URL로 사용되는 세션 수준 "a=control:" 속성이 모두 있습니다. 미디어 수준 URL이 상대 URL인 경우 위의 섹션 C.1.1에 따라 절대 URL로 확인됩니다.
프리젠테이션이 단일 스트림으로만 구성된 경우 미디어 수준 "a=control:" 속성은 모두 생략될 수 있습니다. 그러나 프레젠테이션에 둘 이상의 스트림이 포함된 경우 각 미디어 스트림 섹션에는 자체 "a=control" 속성이 포함되어야 합니다.\(MUST\)
예: v=0 o=- 2890844256 2890842807 IN IP4 204.34.34.32 s=I 포함 i=<추가 정보\> t=0 0 c=IN IP4 0.0.0.0 a=control:rtsp://example.com/movie/ m=비디오 8002 RTP/AVP 31 a=컨트롤:트랙ID=1 m=오디오 8004 RTP/AVP 3 a=컨트롤:트랙ID=2
이 예에서 클라이언트는 서버에 대한 단일 RTSP 세션을 설정해야 하며 URL rtsp://example.com/movie/trackID=1 및 rtsp://example.com/movie/trackID=2를 사용하여 비디오 및 오디오 스트림을 각각 설정합니다. URL rtsp://example.com/movie/는 전체 영화를 제어합니다.
---
# **Appendix D: Minimal RTSP implementation**
---
## **D.1 Client**
클라이언트 구현은 다음을 수행할 수 있어야 합니다.\(MUST\)
\* 다음 요청을 생성합니다: SETUP, TEARDOWN 및 PLAY\(즉, 최소 재생 클라이언트\) 또는 RECORD\(즉, 최소 녹음 클라이언트\) 중 하나. RECORD가 구현되면 ANNOUNCE도 구현되어야 합니다. \* 요청에 CSeq, Connection, Session, Transport 헤더를 포함합니다. ANNOUNCE가 구현되면 Content-Language, Content-Encoding, Content-Length 및 Content-Type 헤더를 포함하는 기능도 구현되어야 합니다. \* 응답에서 CSeq, Connection, Session, Transport, Content-Language, Content-Encoding, Content-Length, Content-Type 헤더를 구문 분석하고 이해합니다. RECORD가 구현되면 Location 헤더도 이해해야 합니다. RTP 호환 구현은 RTP-Info도 구현해야 합니다. \* 수신된 각 오류 코드의 클래스를 이해하고, 오류 코드가 있는 경우 클래스 4xx 및 5xx의 오류 코드를 최종 사용자에게 알립니다. 최종 사용자가 하나 또는 모든 상태 코드에 대해 명시적으로 원하지 않는 경우 알림 요구 사항이 완화될 수 있습니다. \* ANNOUNCE와 같은 서버의 비동기 요청을 예상하고 응답합니다. 이는 반드시 ANNOUNCE 메소드를 구현해야 한다는 의미는 아니며, 단지 서버에서 수신된 모든 요청에 긍정적 또는 부정적으로 응답해야 한다는 의미입니다.\(MUST\)
필수는 아니지만 초기 구현과의 실질적인 상호 운용성 및/또는 "좋은 시민"이 되기 위해 게시 시점에 다음 사항을 적극 권장합니다.
\* RTP/AVP/UDP를 유효한 전송으로 구현합니다. \* User-Agent 헤더가 포함됩니다. \* 부록 C에 정의된 SDP 세션 설명을 이해합니다. \* 표준 입력, 명령줄 또는 운영 환경에 적합한 기타 수단에서 미디어 초기화 형식\(예: SDP\)을 수락하여 다른 애플리케이션\(예: 웹 애플리케이션\)에 대한 "도우미 애플리케이션" 역할을 합니다. 브라우저\).
위의 요구 사항이 타당하지 않은 RTSP 사양 기여자가 처음에 구상한 것과 다른 RTSP 응용 프로그램이 있을 수 있습니다. 따라서 위의 권장 사항은 엄격한 요구 사항이 아닌 지침으로만 사용됩니다.
---
### **D.1.1 Basic Playback**
미디어 스트림의 주문형 재생을 지원하려면 클라이언트는 추가로 다음을 수행할 수 있어야 합니다. \* PAUSE 요청을 생성합니다. \* REDIRECT 메소드와 Location 헤더를 구현합니다.\(MUST\)
---
### **D.1.2 Authentication-enabled**
인증이 필요한 RTSP 서버의 미디어 프리젠테이션에 액세스하려면 클라이언트는 추가로 다음을 수행할 수 있어야 합니다. \* 401 상태 코드를 인식합니다. \* WWW-Authenticate 헤더를 구문 분석하고 포함합니다. \* 기본 인증 및 다이제스트 인증을 구현합니다.\(MUST\)
---
## **D.2 Server**
최소 서버 구현은 다음을 수행할 수 있어야 합니다.\(MUST\)
\* 다음 메소드를 구현하십시오: SETUP, TEARDOWN, OPTIONS 및 PLAY\(최소 재생 서버의 경우\) 또는 RECORD\(최소 녹음 서버의 경우\). RECORD가 구현되면 ANNOUNCE도 구현되어야 합니다. \* 응답에 다음 헤더를 포함합니다: Connection, Content-Length, Content-Type, Content-Language, Content-Encoding, Transport, Public. RECORD 메소드가 있는 경우 Location 헤더를 포함하는 기능을 구현해야 합니다. RTP 호환 구현은 RTP-Info 필드도 구현해야 합니다. \* 요청의 연결, 세션, 전송, 요구 헤더를 구문 분석하고 적절하게 응답합니다.
필수는 아니지만 초기 구현과의 실질적인 상호 운용성 및/또는 "좋은 시민"이 되기 위해 게시 시점에 다음 사항을 적극 권장합니다.
\* RTP/AVP/UDP를 유효한 전송으로 구현합니다. \* 서버 헤더를 포함합니다. \* DESCRIBE 메소드를 구현합니다. \* 부록 C에 정의된 대로 SDP 세션 설명을 생성합니다.
위의 요구 사항이 타당하지 않은 RTSP 사양 기여자가 처음에 구상한 것과 다른 RTSP 응용 프로그램이 있을 수 있습니다. 따라서 위의 권장 사항은 엄격한 요구 사항이 아닌 지침으로만 사용됩니다.
---
### **D.2.1 Basic Playback**
미디어 스트림의 주문형 재생을 지원하려면 서버가 추가로 다음을 수행할 수 있어야 합니다.\(MUST\)
\* Range 헤더를 인식하고 검색이 지원되지 않으면 오류를 반환합니다. \* PAUSE 메소드를 구현하십시오.
또한 일반적으로 사용되는 사용자 인터페이스 기능을 지원하려면 주문형 미디어 서버에 다음을 적극 권장합니다.
\* NPT 단위로 Range 헤더를 포함하고 구문 분석합니다.
- SMPTE 장치 구현을 권장합니다. \* 미디어 초기화 정보에 미디어 프레젠테이션의 길이를 포함합니다. \* 데이터별 타임스탬프에서 NPT로의 매핑을 포함합니다. RTP가 사용되는 경우 RTP-Info 필드의 rtptime 부분을 사용하여 RTP 타임스탬프를 NPT에 매핑할 수 있습니다.
클라이언트 구현은 길이 정보의 존재를 사용하여 클립이 검색 가능한지 확인하고 길이 정보를 사용할 수 없는 클립에 대한 검색 기능을 시각적으로 비활성화할 수 있습니다. 프레젠테이션 길이의 일반적인 용도는 진행률 표시기와 타임라인 위치 지정 도구 역할을 모두 수행하는 "슬라이더 막대"를 구현하는 것입니다.
슬라이더 막대의 올바른 위치를 보장하려면 RTP 타임스탬프에서 NPT로의 매핑이 필요합니다.
---
### **D.2.2 Authentication-enabled**
클라이언트 인증을 올바르게 처리하려면 서버가 추가로 다음을 수행할 수 있어야 합니다.\(MUST\)
\* 리소스에 대한 인증이 필요한 경우 401 상태 코드를 생성합니다. \* WWW-Authenticate 헤더를 구문 분석하고 포함합니다. \* 기본 인증 및 다이제스트 인증을 구현합니다.
---
# **Appendix E: Authors' Addresses**
Henning Schulzrinne 컴퓨터 과학과 Columbia University 1214 Amsterdam Avenue New York, NY 10027 USA
```text
EMail: schulzrinne@cs.columbia.edu
Anup Rao
Netscape Communications Corp.
501 E. Middlefield Road
Mountain View, CA 94043
USA
EMail: anup@netscape.com
Robert Lanphier
RealNetworks
1111 Third Avenue Suite 2900
Seattle, WA 98101
USA
EMail: robla@real.com
```
---
# **Appendix F: Acknowledgements**
이 메모는 96년 10월에 제출된 원본 RTSP 문서의 기능을 기반으로 합니다. 또한 HTTP/1.1에서 형식과 설명을 차용했습니다.
이 문서는 MMUSIC-WG에 참여하는 모든 분들의 의견으로부터 큰 도움을 받았습니다. 이미 언급된 사람들 외에도 다음 개인이 이 사양에 기여했습니다.
Rahul Agarwal, Torsten Braun, Brent Browning, Bruce Butterfield, Steve Casner, Francisco Cortes, Kelly Djahandari, Martin Dunsmuir, Eric Fleischman, Jay Geagan, Andy Grignon, V. Guruprasad, Peter Haight, Mark Handley, Brad Hefta-Gaub, John K Ho, Philipp Hoschka, Anne Jones, Anders Klemets, Ruth Lang, Stephanie Leif, Jonathan Lennox, Eduardo F. Llach, Rob McCool, David Oran, Maria Papadopouli, Sujal Patel, Ema Patki, Alagu Periyannan, Igor Plotnikov, Pinaki Shah, 데이비드 싱어, 제프 스미스, 알렉산더 소콜스키, 데일 스태먼, 존 프란시스 스트라케.
---
# **References**
1 Schulzrinne, H., "최소 제어를 통한 오디오 및 비디오 회의용 RTP 프로필", RFC 1890, 1996년 1월.
2 Fielding, R., Gettys, J., Mogul, J., Nielsen, H. 및 T. Berners-Lee, "하이퍼텍스트 전송 프로토콜 - HTTP/1.1", RFC 2068, 1997년 1월.
3 Yergeau, F., Nicol, G., Adams, G. 및 M. Duerst,
- "하이퍼텍스트 마크업 언어의 국제화", RFC 2070, 1997년 1월.
4 Bradner, S., "RFC에서 다음을 나타내는 데 사용되는 핵심 단어
- 요구 사항 수준", BCP 14, RFC 2119, 1997년 3월.
5 ISO/IEC, "정보 기술 - 동영상 및 관련 오디오 정보의 일반 코딩 - 6부: 디지털 저장 매체 및 제어를 위한 확장", 국제 표준 초안 ISO 13818-6, 국제 표준화 기구 ISO/IEC JTC1/SC29/ WG11, 스위스 제네바, 1995년 11월.
6 Handley, M. 및 V. Jacobson, "SDP: 세션 설명 프로토콜", RFC 2327, 1998년 4월.
7 Franks, J., Hallam-Baker, P. 및 J. Hostetler, "HTTP 확장: 다이제스트 액세스 인증", RFC 2069, 1997년 1월.
```text
8 Postel, J., "User Datagram Protocol", STD 6, RFC 768, August
1980.
```
9 Hinden, B. 및 C. Partridge, "신뢰할 수 있는 데이터 프로토콜\(RDP\) 버전 2", RFC 1151, 1990년 4월.
```text
10 Postel, J., "Transmission control protocol", STD 7, RFC 793,
September 1981.
```
11 H. Schulzrinne, "포괄적인 멀티미디어 제어
- 디지털 오디오 및 비디오를 위한 네트워크 및 운영 체제 지원\(NOSSDAV\)에 관한 Proc. 국제 워크숍\(미주리주 세인트루이스\), 1997년 5월, "인터넷을 위한 아키텍처".
12 국제전기통신연합\(International Telecommunication Union\), "보증되지 않는 서비스 품질을 제공하는 근거리 통신망용 영상 전화 시스템 및 장비", 권고안 H.323, ITU 통신 표준화 부문, 스위스 제네바, 1996년 5월.
13 McMahon, P., "SOCKS 버전 5에 대한 GSS-API 인증 방법", RFC 1961, 1996년 6월.
14 J. Miller, P. Resnick 및 D. Singer, "평가 서비스 및 평가 시스템\(및 기계 판독 가능 설명\)" 권장 사항 REC-PICS-services-961031, W3C\(World Wide Web Consortium\), Boston, Massachusetts, 1996년 10월.
15 J. Miller, T. Krauskopf, P. Resnick 및 W. Treese, "PICS 레이블 배포 레이블 구문 및 통신 프로토콜," 권장 사항 REC-PICS-labels-961031, W3C\(World Wide Web Consortium\), Boston, Massachusetts, 1996년 10월.
16 Crocker, D. 및 P. Overell, "구문을 위한 증강된 BNF
- 사양: ABNF", RFC 2234, 1997년 11월.
17 Braden, B., "인터넷 호스트에 대한 요구 사항 - 응용 프로그램 및 지원", STD 3, RFC 1123, 1989년 10월.
18 Elz, R., "IPv6 주소의 압축된 표현", RFC 1924, 1996년 4월.
19 Berners-Lee, T., Masinter, L. 및 M. McCahill, "Uniform Resource Locator\(URL\)", RFC 1738, 1994년 12월.
20 Yergeau, F., "UTF-8, ISO 10646의 변환 형식", RFC 2279, 1998년 1월.
22 Braden, B., "T/TCP - 트랜잭션을 위한 TCP 확장
- 기능 사양", RFC 1644, 1994년 7월.
22 W. R. Stevens, TCP/IP 설명: 구현, vol. 2. 매사추세츠주 레딩: 애디슨-웨슬리, 1994.
23 Schulzrinne, H., Casner, S., Frederick, R. 및 V. Jacobson, "RTP: 실시간 애플리케이션을 위한 전송 프로토콜", RFC 1889, 1996년 1월.
```text
24 Fielding, R., "Relative uniform resource locators", RFC 1808,
June 1995.
```
---
# **Full Copyright Statement**
저작권\(C\)인터넷학회\(1998\). 판권 소유.
본 문서와 그 번역본은 다른 사람에게 복사 및 제공될 수 있으며, 본 문서에 대해 논평하거나 설명하거나 구현을 지원하는 파생 저작물은 어떤 종류의 제한 없이 전체 또는 일부를 준비, 복사, 출판 및 배포할 수 있습니다. 단, 위의 저작권 표시와 이 단락은 모든 사본과 파생물에 포함되어 있어야 합니다. 그러나 이 문서 자체는 저작권 표시를 제거하거나 인터넷 협회 또는 기타 인터넷 조직에 대한 참조를 제거하는 등 어떠한 방식으로도 수정할 수 없습니다. 단, 인터넷 표준을 개발할 목적으로 필요한 경우는 제외됩니다. 이 경우 저작권에 대한 절차는 인터넷 표준 프로세스를 따라야 하거나 영어 이외의 언어로 번역하려면 필요한 대로 따라야 합니다.
위에서 부여된 제한된 권한은 영구적이며 Internet Society 또는 그 승계자 또는 양수인에 의해 취소되지 않습니다.
이 문서와 여기에 포함된 정보는 "있는 그대로" 제공되며 인터넷 사회 및 인터넷 공학 태스크포스는 여기에 포함된 정보의 사용이 상품성 또는 특정 목적에의 적합성에 대한 권리 또는 묵시적 보증을 침해하는 행위.
original document link : https://www.ietf.org/rfc/rfc2326.txt
Disclaimer of Accuracy for Translation:
This document is a translation of the original (RFC 2326). While every effort has been made to ensure the accuracy of this translation, it may contain errors or discrepancies. For verification of the content and to ensure consistency with the original document, please refer to the original version.
Non-Commercial Use and Educational Purpose Statement:
This translated document is intended solely for educational purposes and is not to be used for any commercial purposes. The content of this translation is provided to facilitate learning and understanding of the original (RFC 2326) and should not be utilized in any commercial context.
translator : yevgeny hong, used google translator api
contact : hongyevgeny@gmail.com