Khác biệt giữa bản sửa đổi của “Real Time Streaming Protocol”

Nội dung được xóa Nội dung được thêm vào

Nội tuyến

Phiên bản lúc 05:40, ngày 2 tháng 8 năm 2017

Real Time Streaming Protocol (RTSP) – Giao thức truyền tin thời gian thực là một giao thức điều khiển truyền thông mạng ở tầng ứng dụng được thiết kế để sử dụng trong các hệ thống giải trí và truyền thông để điều khiển máy chủ chứa các dữ liệu truyền tin đa phương tiện (streaming media). Giao thức này được sử dụng để thiết lập và điều khiển các phiên truyền thông giữa các trạm cuối. Các máy khách của các máy chủ truyền thông ban ra các lệnh kiểu VCR, chẳng hạn như chơi, thâu và tạm dừng, để điều khiển thời gian thực của các phương tiện truyền tin trực tuyến từ máy chủ tới máy khách (Video On Demand) hoặc từ máy khách đến máy chủ (Voice Recording) .

Việc truyền tải dữ liệu trực tuyến không phải là một nhiệm vụ của RTSP. Hầu hết các máy chủ RTSP sử dụng giao thức truyền tải thời gian thực (RTP) kết hợp với giao thức điều khiển thời gian thực (RTCP) để phân phối luồng truyền thông. Tuy nhiên, một số nhà cung cấp thực hiện các giao thức vận tải độc quyền. Phần mềm máy chủ RTSP của RealNetworks, thí dụ, cũng sử dụng Real Data Transport (RDT) độc quyền của RealNetworks.

RTSP được phát triển bởi RealNetworks, Netscape ^[1] và Đại học Columbia, với dự thảo đầu tiên đệ trình lên IETF năm 1996. ^[2] Nó đã được tiêu chuẩn hóa bởi Nhóm làm việc Multiparty Multimedia Session Control (MMUSIC WG) của IETF và công bố như là RFC 2326 vào năm 1998.<ref name=":0"> RTSP 2.0 xuất bản như là RFC 7826 vào năm 2016 để thay thế cho RTSP 1.0. RTSP 2.0 dựa trên RTSP 1.0 nhưng không tương thích ngược với các cơ chế khác hơn là cơ chế đàm phán trong phiên bản cơ bản.

Một số đặc điểm của RTSP

- Khả năng mở rộng: Các phương pháp và các thông số mới có thể dễ dàng thêm vào RTSP.

- Dễ dàng phân tích: RTSP có thể được phân tích theo bộ phân tích cú pháp HTTP hoặc MIME.

- An toàn: RTSP tái sử dụng những cơ chế bảo mật web. Tất cả các cơ chế chứng thực HTTP như chứng thực cơ bản và chứng thực băm được trực tiếp áp dụng. Ngoài ra RTSP cũng có thể tái sử dụng những cơ chế an ninh tầng giao vận hoặc tầng mạng.

- Độc lập với tầng vận chuyển: RTSP có thể sử dụng hoặc một giao thức truyền tin không tin cậy như UDP, hoặc một giao thức truyền tin tin cậy như TCP.

- Khả năng đa máy chủ: Mỗi luồng dữ liệu truyền thông trong một biểu diễn có thể nằm trên một máy chủ khác. Máy khách sẽ tự động thiết lập một số phiên kiểm soát đồng thời với các máy chủ truyền thông khác. Đồng bộ dữ liệu truyền thông được thực hiện ở mức độ vận chuyển.

- Kiểm soát các thiết bị ghi: Các giao thức có thể kiểm soát cả các thiết bị ghi và phát, cũng như thiết bị có thể thay đổi giữa hai chế độ.

- Tách kiểm soát dòng và khởi tạo kết nối: Kiểm soát dòng đã được tách ra khỏi việc mời một máy chủ truyền thông tham gia một kết nối. Yêu cầu duy nhất là giao thức khởi tạo kết nối có thể cung cấp hoặc được sử dụng để tạo ra một nhận dạng kết nối duy nhất. Trong một số trường hợp đặc biệt, tiêu chuẩn SIP (Session Initiation Protocol – Giao thức khởi tạo phiên) hoặc tiêu chuẩn H.323 có thể được sử dụng để mời một máy chủ tham gia một kết nối.

- Thích hợp cho các ứng dụng chuyên nghiệp: RTSP hỗ trợ độ chính xác khung hình thông qua nhãn thời gian, cho phép chỉnh sửa ảnh kỹ thuật số từ xa.

- Mô tả biểu diễn trung tính: Giao thức không áp đặt một biểu diễn đặc biệt mô tả hoặc định dạng tập tin đặc tả (metafile) và có thể truyền tải loại định dạng được sử dụng. Tuy nhiên, các mô tả trình bày phải có ít nhất một URI RTSP.

- Thành phần trung gian và tường lửa thân thiện: Các giao thức nên sẵn sàng xử lý bởi cả tường lửa ứng dụng và tầng giao vận.

- Thân thiện với HTTP: Trường hợp cần thiết, RTSP tái sử dụng khái niệm HTTP, do đó, cơ sở hạ tầng hiện tại có thể được tái sử dụng. Cơ sở hạ tầng này bao gồm PICS (Platform for Internet Content Selection – Nền tảng để lựa chọn nội dung Internet) cho gắn nhãn với nội dung. Tuy nhiên, RTSP không chỉ thêm các phương pháp vào HTTP bởi vì việc kiểm soát dữ liệu truyền thông liên tục đòi hỏi trạng thái máy chủ trong hầu hết các trường hợp.

- Kiểm soát máy chủ thích hợp: Nếu một máy khách có thể bắt đầu một luồng dữ liệu, nó phải có khả năng ngăn chặn một luồng dữ liệu. Máy chủ không nên bắt đầu truyền dữ liệu cho các máy khách trong trường hợp máy khách không thể ngăn chặn luồng dữ liệu.

- Đàm phán vận chuyển: Máy khách có thể đàm phán phương pháp vận chuyển trước khi thực sự cần phải xử lý một luồng dữ liệu truyền thông liên tục.

- Khả năng đàm phán: Nếu tắt các tính năng cơ bản, phải có một cơ chế an toàn cho máy khách để xác định phương pháp không tiếp tục thực hiện. Điều này cho phép các máy khách trình bày giao diện người dùng phù hợp. Ví dụ, nếu tìm kiếm không cho phép, giao diện người sử dụng phải có khả năng không cho phép di chuyển một thanh trượt chỉ báo vị trí.

[null 2. Thuật ngữ của giao thức]

- Kiểm soát tổng hợp (Aggregate control): Việc kiểm soát của nhiều dòng bằng cách sử dụng một thời gian duy nhất bởi máy chủ. Đối với việc cung cấp âm thanh, video, điều này có nghĩa rằng máy khách có thể phát hành một bản chơi duy nhất hoặc tạm dừng thông điệp để kiểm soát cả nguồn cấp dữ liệu âm thanh và video.

- Hội nghị (Conference): Nơi có nhiều đối tượng tham gia, trình diễn.

- Máy khách (Client): Máy khách yêu cầu dữ liệu truyền thông liên tục từ máy chủ truyền thông.

- Kết nối (Connection): Một mạch ảo lớp vận chuyển thiết lập giữa hai chương trình cho mục đích giao tiếp.

- Tập tin bao hàm (Container file): Một tập tin có thể chứa các dòng dữ liệu truyền thông đa luồng thường bao gồm một biểu diễn khi chơi cùng nhau. Các máy chủ RTSP có thể cung cấp kiểm soát tổng hợp về những tập tin này, mặc dù khái niệm về một tập tin bao hàm không được có trong giao thức.

- Dữ liệu truyền thông liên tục (Continuous media): Là dữ liệu có một mối quan hệ thời gian giữa nguồn và đích, nghĩa là, đích đến phải tạo lại mối quan hệ thời gian đã tồn tại nguồn. Các ví dụ phổ biến nhất của dữ liệu truyền thông liên tục là những âm thanh và video chuyển động. Dữ liệu truyền thông liên tục có thể tương tác trong thời gian thực, trong đó có một mối quan hệ thời gian "chặt chẽ" giữa luồng vào và luồng ra, hoặc truyền dữ liệu (phát lại), trong đó mối quan hệ thời gian lỏng hơn.

- Thực thể (Entity): Các thông tin được truyền đi được đóng gói theo một yêu cầu hoặc phản hồi. Một thực thể bao gồm thông tin đặc tả được mô tả trong các trường tiêu đề và nội dung trong phần thân của thực thể.

- Khởi tạo truyền thông (Media initialization): Khởi tạo cụ thể Loại dữ liệu/chương trình mã hóa, giải mã; bao gồm chẳng hạn như tần số, bảng màu... Bất cứ thông tin độc lập với vận chuyển do một máy khách yêu cầu phát lại của một luồng dữ liệu truyền thông xuất hiện trong giai đoạn khởi tạo truyền thông của quá trình thiết lập luồng dữ liệu.

- Tham số truyền thông (Media parameter): Thông số cụ thể cho một loại truyền thông có thể được thay đổi trước hoặc trong quá trình phát lại luồng dữ liệu.

- Máy chủ truyền thông: Máy chủ cung cấp dịch vụ phát lại hoặc ghi cho một hoặc nhiều luồng dữ liệu truyền thông. Dòng dữ liệu truyền thông khác nhau trong một biểu diễn có thể bắt đầu từ các máy chủ truyền thông khác nhau. Một máy chủ truyền thông có thể nằm trên cùng một hoặc một máy chủ khác như máy chủ web nơi mà biểu diễn được khởi tạo.

- Máy chủ truyền thông gián tiếp: Định hướng của một máy khách truyền thông đến một máy chủ truyền thông khác.

- Luồng dữ liệu truyền thông (Media stream): Một thể hiện của dữ liệu truyền thông duy nhất, ví dụ một luồng âm thanh hoặc luồng video. Khi sử dụng RTP, một luồng dữ liệu bao gồm tất cả các gói dữ liệu RTP và RTCP được tạo ra bởi một nguồn tin trong một phiên RTP.

- Thông điệp (Message): Bao gồm một chuỗi có cấu trúc các gói tin 8 bít phù hợp với cú pháp và được truyền qua một giao thức có kết nối hoặc giao thức không kết nối.

- Đối tượng tham gia (Presenter): Thành viên của một kết nối. Một đối tượng tham gia có thể là một máy, ví dụ, một máy chủ lưu trữ hoặc phát lại.

- Trình diễn (Presentation): Một tập của một hoặc nhiều luồng dữ liệu được chiếu cho máy khách như là một nguồn cung cấp dữ liệu truyền thông đầy đủ, bằng cách sử dụng một mô tả biểu diễn được định nghĩa trước. Trong hầu hết các trường hợp, điều này bao hàm việc kiểm soát tổng hợp của những luồng dữ liệu, nhưng không bắt buộc.

- Mô tả trình diễn (Presentation description): Một mô tả trình diễn chứa thông tin về một hoặc nhiều dữ liệu truyền thông trong một trình diễn, chẳng hạn như các bộ mã hóa, các địa chỉ mạng và thông tin về nội dung.

- Phiên RTSP (RTSP session): Là việc hoàn thành một giao dịch RTSP, ví dụ như việc xem một bộ phim. Một phiên thường bao gồm một máy khách thiết lập một cơ chế vận chuyển cho dữ liệu truyền thông liên tục, bắt đầu truyền dữ liệu bằng cách phát hoặc ghi, và cuối cùng đóng giao dịch.

- Khởi tạo vận chuyển (Transport initialization): Là việc đàm phán về thông tin vận chuyển (ví dụ số cổng, các giao thức vận chuyển) giữa máy khách và máy chủ.

- Multicast: Là mô hình truyền tin từ một điểm đồng thời đến một nhóm các điểm trong mạng.

- Unicast: Là mô hình truyền tin từ một điểm đến một điểm trong mạng.

[null 3. Các tham số của giao thức RTSP] (protocol parameters)

A. RTSP VERSION

Ứng dụng HTTP thay thế bởi RTSP

[null B. RTSP URL]

"RTSP" và "RTSPu" dùng để chỉ các tài nguyên mạng thông qua giao thức RTSP. Phần này quy định cụ thể cú pháp và ngữ nghĩa cho RTSP URLs.

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 is defined in [H3.2.1].

RTSP yêu cầu này được ban hành thông qua một giao thức đáng tin cậy (TCP), trong khi các chương trình RTSPu xác định một giao thức không đáng tin cậy (UDP).

Nếu port trống rỗng, hoặc không được chỉ ra, thì port 554 được giả định.Các nguồn tài nguyên được xác định có thể được kiểm soát bởi RTSP, tại các server sẽ lắng nghe các kết nối TCP ("RTSP") hoặc UDP ("rtspu") các gói tin trên cổng đó của host, và URI yêu cầu cho tài nguyên RTSP_URL.

[null C. CONFERENCE IDENTIFIERS]

Conference Identifiers được mã hóa bằng cách sử dụng phương pháp mã hóa URI tiêu chuẩn. Có thể chứa bất kỳ giá trị octet.

conference-id = 1*xchar

Conference Identifiers dùng để cho phép các phiên RTSP có được các thông số từ các hội nghị đa phương tiện máy chủ phương tiện truyền thông tham gia. Những conference này được tạo ra bởi các giao thức bên ngoài phạm vi của đặc tả này như H.323 [13] hoặc SIP [12].Thay vì khách hàng RTSP cung cấp thông tin, ví dụ yêu cầu máy chủ phương tiện truyền thông sử dụng các giá trị trong các mô tả Conference.

[null D. SESSION IDENTIFIERS]

Session identifiers là một chuỗi độ dài tùy ý không xác định. Session identifiers được lựa chọn ngẫu nhiên và phải có ít nhất là tám octet làm cho phỏng đoán khó khăn hơn.

session-id = 1*(ALPHA | DIGIT | safe)

[null E. SMPTE RELATIVE TIMESTAMPS]

SMPTE Relative Timestamps biểu diễn thời gian liên quan đến sự bắt đầu của clip. Nhãn thời gian tương đối được thể hiện dưới dạng mã thời gian SMPTE cho độ chính xác truy cập cấp độ khung hình. Mã thời gian có định dạng giờ: phút: giây: frames.subframes, lúc bắt đầu của clip. Định dạng mặc định SMPTE là "SMPTE 30 drop" định dạng với tỷ lệ khung hình là 29,97 khung hình mỗi giây. Các mã khác SMPTE MAY được hỗ trợ thông qua việc sử dụng sử dụng thay thế "thời gian SMPTE" (như "SMPTE 25"). Đối với lĩnh vực "khung" trong giá trị thời gian có thể giả định các giá trị 0 đến 29. Sự khác biệt giữa 30 và 29,97 khung hình mỗi giây được xử lý bằng cách thả hai chỉ số frame đầu tiên (giá trị 00 và 01) của mỗi phút, ngoại trừ mỗi phút thứ mười. Nếu giá trị khung là số không, nó có thể được bỏ qua. Subframes được đo trong một phần trăm của một khung.

smpte-range = smpte-type "=" smpte-time "-" [ smpte-time ]

smpte-type = "smpte" | "smpte-30-drop" | "smpte-25"

; other timecodes may be added

smpte-time = 1*2DIGIT ":" 1*2DIGIT ":" 1*2DIGIT [ ":" 1*2DIGIT ]

[ "." 1*2DIGIT ]

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

[null F. NORMAL PLAY TIME]

Thời gian chơi bình thường (NPT) cho biết vị trí dòng tuyệt đối liên quan đến sự khởi đầu của bài trình bày. Dấu thời gian bao gồm một phần số thập phân. Phần còn lại của số thập phân có thể được thể hiện bằng một trong hai giây hoặc giờ, phút, và giây. Phần bên phải của điểm thập phân biện pháp phần của một giây.

Sự khởi đầu của một bản mô tả tương ứng với 0,0 giây. Giá trị âm không xác định. Hằng số đặc biệt được xác định ngay lập tức một sự kiện trực tiếp. Có thể chỉ sử dụng cho các sự kiện trực tiếp.

NPT được định nghĩ trong DSM-CC: "Theo trực giác NPT là đồng hồ liên kết trình xem với một chương trình thường kỹ thuật số hiển thị trên một VCR. NPT cải tiến bình thường khi ở chế độ chơi bình thường (quy mô = 1), tiến bộ nhanh hơn. NPT (logic) tương đương với mã thời gian SMPTE. "

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-

[null G. ABSOLUTE TIME]

Absolute time được thể hiện bởi ISO 8601 timestamps, bằng cách sử dụng UTC (GMT). Các phần phân đoạn của một giây có thể được chỉ định.

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 >

Example for ngày 8 tháng 11 năm 1996 at 14h37 and 20 and a quarter seconds

UTC:

19961108T143720.25Z

[null H. OPTION TAGS]

Option tags được sử dụng để chỉ định các tùy chọn mới trong RTSP. Các thẻ này được sử dụng trong Require và Proxy- Require trường header.

Cú pháp: Option-tag = 1 * xchar

[null Registering New Option Tags with IANA]

Khi đăng ký một lựa chọn RTSP mới, cần được cung cấp các thông tin sau:

* Tên và mô tả của các tùy chọn. Tên có thể là chiều dài bất kỳ, nhưng không quá hai mươi ký tự. Tên không được chứa bất kỳ khoảng trắng, ký tự điều khiển hoặc thời gian.

* Chỉ định ai có quyền kiểm soát thay đổi theo tùy chọn (ví dụ, IETF, ISO, ITU-T, các tiêu chuẩn hóa quốc tế, một tập đoàn hay một công ty cụ thể hoặc nhóm các công ty).

* Đối với các tùy chọn độc quyền, thông tin liên lạc (bưu điện và địa chỉ email).

[null I. RTSP MESSAGE]

RTSP là một giao thức dựa trên văn bản và sử dụng ký tự với thiết lập ISO 10.646 trong mã UTF-8 (RFC 2279 [21]). Dòng được kết thúc bằng CRLF, nhưng phải được thông dịch CR và LF như dây chuyền terminators.

Các giao thức dựa trên văn bản nên dễ dàng hơn để thêm các thông số tùy chọn trong một bản mô tả.Vì số lượng các thông số và tần số của các lệnh thấp, hiệu quả không phải là mối lo ngại. Dựa vào văn bản giao thức, nếu được thực hiện một cách cẩn thận, cũng cho phép dễ dàng thực hiện các nghiên cứu trong scripting ngôn ngữ như Tcl, Visual Basic và Perl.

RTSP Message có thể được vận chuyển qua bất kỳ giao thức vận chuyển thấp hơn lớp 8 bit.

- Message Types.

- Message Headers.

- Message Body được bao gồm tin nhắn, chiều dài được xác định bởi một trong những điều sau đây (theo thứ tự ưu tiên):

+ Bất kỳ thông điệp trả lời MUST NOT bao gồm một khối thông báo (như 1xx, 204, và 304 responses) luôn luôn chấm dứt các trường entity-header hiện diện trong tin nhắn.(Lưu ý: Một dòng rỗng bao gồm các chỉ CRLF).

+ Nếu một tiêu đề Content-Length hiện nay, giá trị của nó tính theo byte đại diện cho độ dài của tin khối nhắn. Nếu header field không có mặt, một giá trị zero được giả định.

+ Bởi các máy chủ đóng kết nối.(Đóng kết nối không thể được sử dụng để báo hiệu kết thúc của một cơ thể yêu cầu, từ đó sẽ để lại không có khả năng cho máy chủ để gửi lại một phản ứng).

[null J. GENERAL HEADER FIELDS]

Ngoại trừ tiêu đề Pragma, Transfer-Encoding và Upgrade headers chưa được xác định:

general-header = Cache-Control ; Section 12.8

| Connection ; Section 12.10

| Date ; Section 12.18

| Via ; Section 12.43

[null K. REQUEST]

Tin nhắn yêu cầu từ một client đến một máy chủ hoặc ngược lại bao gồm, trong dòng đầu tiên của tin nhắn đó, phương pháp này được áp dụng cho các nguồn tài nguyên, nhận dạng của tài nguyên, và phiên bản giao thức được sử dụng.

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

[null L. REQUEST LINE]

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

Dấu sao "*" trong-Request URI có nghĩa yêu cầu không áp dụng với một tài nguyên cụ thể, đến máy chủ riêng, và chỉ được phép khi phương thức sử dụng không nhất thiết phải áp dụng cho một tài nguyên.

Ví dụ:

OPTIONS * RTSP/1.0

[null M. RESPONSE]

Sau khi tiếp nhận và phiên dịch một tin nhắn yêu cầu, người nhận trả lời bằng một tin nhắn phản hồi RTSP.

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

[null N. STATUS-LINE]

Dòng đầu tiên của một tin nhắn Response Status-Line, bao gồm các phiên bản giao thức tiếp theo là một mã trạng thái số, cụm từ văn bản liên kết với mã trạng thái, với mỗi phần tử cách nhau bằng ký tự SP. Không có CR hoặc LF được phép ngoại trừ trong chuỗi CRLF chính thức.

Status-Line = RTSP-Version SP Status-Code SP Reason-Phrase CRLF

Status Code and Reason Phrase

Status-Code có 3-digit số nguyên để hiểu và đáp ứng yêu cầu. Các mã được xác định đầy đủ trong Phần 11. Reason-Phrase được thiết kế để cung cấp cho một mô tả ngắn văn bản của Status-Code. Status-Code được thiết kế để sử dụng automata và Reason-Phrase chỉ dành cho người dùng. Khách hàng không cần thiết kiểm tra hoặc hiển thị Reason-Phrase.

Status-Code = "100" ; Continue

| "200" ; OK

| "201" ; Created

| "250" ; Low on Storage Space

| "300" ; Multiple Choices

| "301" ; Moved Permanently

| "302" ; Moved Temporarily

| "303" ; See Other

| "304" ; Not Modified

| "305" ; Use Proxy

| "400" ; Bad Request

| "401" ; Unauthorized

| "402" ; Payment Required

| "403" ; Forbidden

| "404" ; Not Found

| "405" ; Method Not Allowed

| "406" ; Not Acceptable

| "407" ; Proxy Authentication Required

| "408" ; Request Time-out

| "410" ; Gone

| "411" ; Length Required

| "412" ; Precondition Failed

| "413" ; Request Entity Too Large

| "414" ; Request-URI Too Large

| "415" ; Unsupported Media Type

| "451" ; Parameter Not Understood

| "452" ; Conference Not Found

| "453" ; Not Enough Bandwidth

| "454" ; Session Not Found

| "455" ; Method Not Valid in This State

| "456" ; Header Field Not Valid for Resource

| "457" ; Invalid Range

| "458" ; Parameter Is Read-Only

| "459" ; Aggregate operation not allowed

| "460" ; Only aggregate operation allowed

| "461" ; Unsupported transport

| "462" ; Destination unreachable

| "500" ; Internal Server Error

| "501" ; Not Implemented

| "502" ; Bad Gateway

| "503" ; Service Unavailable

| "504" ; Gateway Time-out

| "505" ; RTSP Version not supported

| "551" ; Option not supported

| extension-code

extension-code = 3DIGIT

Reason-Phrase = *<TEXT, excluding CR, LF>

Response Header Fields

Response-header fields cho phép bên nhận yêu cầu thông qua thông tin bổ sung đáp ứng không thể được đặt trong Status-Line. Những header fields cung cấp thông tin về máy chủ và truy cập tài nguyên được xác định bởi các-Request URI.

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

[null O. ENTITY]

Tin nhắn yêu cầu và đáp ứng MAY chuyển một đối tượng nếu không bị hạn chế bởi request method or response status code. Một đối tượng gồm các entity-header fields and an entity-body, mặc dù một số câu trả lời sẽ chỉ bao gồm các entity-headers.

Trong phần này, cả người gửi và người nhận giới thiệu cho khách hàng hoặc máy chủ, tùy thuộc vào người gửi và người nhận được các entity.

Entity Header Fields

Entity Header Fields xác định metainformation tùy chọn về entity-body, hoặc không có mặt, các nguồn tài nguyên được xác định theo yêu cầu.

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

Entity Body

[null P. CONNECTIONS]

RTSP có thể được truyền theo nhiều cách khác nhau:

- Kết nối vận chuyển liên tục được sử dụng cho các giao dịch request-response.

- Một kết nối các giao dịch request/response.

- Chế độ kết nối.

Các loại kết nối vận chuyển được xác định bởi URI RTSP (Phần 3,2).Đối với "RTSP", một kết nối liên tục được giả định, trong khi "RTSPu" các cuộc gọi cho RTSP yêu cầu được gửi mà không cần thiết lập một HTTP connection. RTSP cho phép máy chủ phương tiện truyền thông gửi các yêu cầu cho khách hàng.Tuy nhiên, đây chỉ là hỗ trợ cho các kết nối liên tục, máy chủ phương tiện truyền thông khác không được tin cậy. Ngoài ra, đây là cách duy nhất là các yêu cầu từ máy chủ phương tiện truyền thông cho khách hàng để đi qua bức tường lửa.

Pipelining

Client hỗ trợ kết nối liên tục hoặc mode kết nối MAY " pipeline" yêu cầu (gửi nhiều yêu cầu mà không cần phải chờ đợi câu trả lời). Server phải gửi phản hồi theo thứ tự các yêu cầu đã nhận được.

Reliability and Acknowledgements

Yêu cầu được công nhận bởi người nhận, trừ khi chúng được gửi đến một nhóm multicast. Nếu không có xác nhận, người gửi có thể gửi lại tin nhắn tương tự sau khi một thời gian chờ (RTT) thời gian đi được ước tính như trong giao thức TCP (RFC 1123).

4. Định nghĩa các thông điệp

Để thực hiện kỹ thuật streaming video theo giao thức RTSP nhất thiết máy client phải gửi lên máy server (streaming server) những request sau và phải theo một trình tự nhất định

[null - OPTIONS]

Đầu tiên, máy client sẻ gửi yêu cầu OPTIONS kèm với đường link trỏ tới file video cần xem tới máy server, để máy server chấp nhận đường link này.

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

[null - DESCRIBE]

Nếu máy server trả về mã chấp nhận đường link trên thì máy client tiếp tục gửi yêu cầu DESCRIBE tới máy server để máy server phân tích đường link. Một yêu cầu DESCRIBE bao gồm một đường link RTSP có dạng (rtsp://) và kiểu dữ liệu đáp trả từ phía server. Cổng mặc định được sử dụng cho giao thức RTSP là 554 và cổng này được sử dụng cho cả giao thức của tầng giao vận UDP và TCP. Thông điệp đáp lại từ máy server cho yêu cầu DESCRIBE của máy client bao gồm bản tin miêu tả chi tiết phiên giao dịch (Session Description Protocol – SDP). Ngoài ra trong thông điệp trả về từ máy server còn liệt kê các đường link thích hợp hơn tới file video cần chơi khi mà trong file video đó có trộn lẫn giữa phụ đề và âm thanh. Và điều quan trọng nhất ở trong bản tin miêu tả phiên giao dịch này là streamid của luồng video và streamid của luồng âm thanh khi mà đoạn video đó có lồng âm thanh vào trong các frame.

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

[null - ANNOUNCE]

Phương thức announce dùng hai mục đích:

Khi gửi từ máy khách đến máy chủ, thông báo bản mô tả nội dung hoặc phương tiện truyền thông được xác định bởi các URL yêu cầu đến máy chủ. Khi gửi từ máy chủ cho khách hàng, thông báo cập nhật mô tả phiên họp trong thời gian thực.

Nếu một dòng phương tiện truyền thông mới được thêm vào một bản mô tả nội dung, và bản mô tả này được gửi lại, chứ không phải chỉ là thành phần bổ sung, để có thể xóa được.

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

[null - SETUP]

Sau khi máy client nhận được thông điệp đáp trả từ máy server sau yêu cầu DESCRIPTION thì máy client sẽ tiếp tục gửi tiếp yêu cầu SETUP tới máy server. Một yêu cầu SETUP sẽ chỉ ra cách mà một dòng dữ liệu (single media stream) bắt buộc phải được truyền đi như thế nào. Và yêu cầu SETUP bắt buộc phải được hoàn thành trước khi một yêu cầu PLAY được gửi từ máy client. Yêu cầu SETUP bao gồm một đường link tới file video cần streaming và một thông tin đặc tả cho phần giao vận. Đặc tả này bao gồm 2 cổng trong đó có một cổng cục bộ trên máy client dành cho việc nhận cac gói tin RTP (audio và video) và cổng còn lại dùng để nhận các gói tin RTCP (meta information). Máy server sẽ đáp trả lại bằng các xác nhận các tham số đã được lựa chọn, và điền vào các phần còn thiếu ví dụ như máy server có thể chọn lại cổng của mình. Mỗi luồng dữ liệu sẽ được cấu hình cụ thể sau khi yêu cầu SETUP được hoàn tất trước khi máy client gửi yêu cầu PLAY.

Example:

C->S: SETUP rtsp://example.com/media.mp4/streamid=0 RTSP/1.0

CSeq: 3

Transport: RTP/AVP;unicast;client_port=8000-8001

S->C: RTSP/1.0 200 OK

CSeq: 3

Transport: RTP/AVP;unicast;client_port=8000-8001;server_port=9000-9001

Session: 12345678

[null - PLAY]

Sau khi hoàn tất yêu cầu SETUP, cấu hình được các luồng dữ liệu để chuẩn bị streaming, máy client sẽ gửi yêu cầu PLAY để thực hiện truyền các frame dữ liệu thật sự từ máy server tới máy client, và các frame dữ liệu này sẽ được lưu trong một bộ đệm của máy client, các frame này sẽ được giải mã (decode), rồi được hiển thị bởi trình chơi file video và âm thanh (VLC). Yêu cầu PLAY bao gồm một đường dẫn trỏ tới file video cần phát giống như các yêu cầu trước đó. Đường link này có thể là đường tổng hợp (để phát các luồng dữ liệu) hoặc là một đường link đơn lẻ (chỉ phát một luồng dữ liệu duy nhất). Trong yêu cầu PLAY, máy client cũng sẽ chỉ ra một dải (range) chỉ rõ một cách cụ thể số hiệu frame bắt đầu được gửi và số hiệu frame kết thúc, Nếu như không chỉ rõ tham số này, thì toàn bộ các frame sẽ được gửi tới máy client. Và nếu như luồng dữ liệu có bị tạm dừng (pause) thì luồng dữ liệu này cũng sẽ được phục hồi ở frame mà nó tạm dừng truyền.

Example:

C->S: PLAY rtsp://example.com/media.mp4 RTSP/1.0

CSeq: 4

Range: npt=5-20

Session: 12345678

S->C: RTSP/1.0 200 OK

CSeq: 4

Session: 12345678

RTP-Info: url=rtsp://example.com/media.mp4/streamid=0;seq=9810092;rtptime=345002

[null - PAUSE]

Trong quá trình streaming video, nếu như người dùng muốn tạm dừng quá trình streaming thì sẽ gửi yêu cầu PAUSE tới máy server, yêu cầu này sẽ làm tạm dừng một hay nhiều luồng dữ liệu đang truyền các frame về máy client. Máy server sẽ tạm dừng gửi các frame dữ liệu tới máy client.

Ví dụ đối âm thanh điều này tương đương với tắt tiếng, sau khi nối lại phát lại hoặc ghi âm, đồng bộ hóa các bài hát phải được duy trì. Bất kỳ tài nguyên máy chủ được lưu giữ, mặc dù máy chủ có thể đóng các phiên họp và các nguồn tài nguyên miễn phí sau khi được tạm dừng trong thời gian quy định với số thời gian chờ của tiêu đề Session trong SETUP message.

Một yêu cầu PAUSE tạm thời tạm dừng một hoặc tất cả các dòng phương tiện truyền thông, do đó, nó sau này có thể được nối lại với một yêu cầu PLAY. Yêu cầu có chứa một URL dòng tổng hợp hay các phương tiện truyền thông. Một thông số trên phạm vi yêu cầu PAUSE quy định khi tạm dừng. Khi tham số phạm vi được bỏ qua, tạm dừng xảy ra ngay lập tức và vô thời hạn.

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

[null - TEARDOWN]

Trong quá trình streaming video, nếu như người dùng muốn dừng hẳn quá trình streaming thì sẽ gửi yêu cầu TEARDOWN để dừng truyền và kết thúc một phiên giao dịch của giao thức RTSP. Máy server sẽ đáp trả lại thông điệp xác nhận cho yêu cầu TEARDOWN và sẽ dừng gửi các frame tới máy client.

Yêu cầu Teardown dừng việc cung cấp dòng cho URI (là một chuỗi ký tự được sử dụng để xác định một tên hoặc một tài nguyên), giải phóng các nguồn tài nguyên liên kết với nó. Nếu URI trình bày cho các bài trình bày này, bất kỳ định danh phiên RTSP liên kết với phiên không còn giá trị. Trừ khi tất cả các thông số vận chuyển được xác định bởi mô tả phiên, một yêu cầu thiết lập đã được cấp trước phiên họp có thể được PLAY một lần nữa.

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

[null - GET_PARAMETER]

Cho phép các thông số được trao đổi. Yêu cầu GET_PARAMETER lấy giá trị của một tham số của một bài thuyết trình hoặc dòng quy định trong URI. Nội dung của các trả lời và phản ứng còn lại để thực hiện. GET_PARAMETER không được sử dụng để kiểm tra client hoặc máy chủ liveness ("ping").

Example:

S->C: GET_PARAMETER rtsp://example.com/media.mp4 RTSP/1.0

CSeq: 9

Content-Type: text/parameters

Session: 12345678

Content-Length: 15

packets_received

jitter

C->S: RTSP/1.0 200 OK

CSeq: 9

Content-Length: 46

Content-Type: text/parameters

packets_received: 10

jitter: 0.3838

[null - SET_PARAMETER]

Phương pháp này yêu cầu để thiết lập giá trị của một tham số cho một bản mô tả hoặc dòng quy định của URI (là một chuỗi ký tự được sử dụng để xác định một tên hoặc một tài nguyên).

C->S: SET_PARAMETER rtsp://example.com/media.mp4 RTSP/1.0

CSeq: 10

Content-length: 20

Content-type: text/parameters

barparam: barstuff

S->C: RTSP/1.0 451 Invalid Parameter

CSeq: 10

Content-length: 10

Content-type: text/parameters

Barparam

[null - REDIRECT]

Một yêu cầu chuyển hướng thông báo cho client rằng phải kết nối đến một địa điểm máy chủ. Chứa Location tiêu đề bắt buộc, trong đó chỉ ra rằng máy khách nên đưa ra yêu cầu cho URL đó. Có thể chứa dãy tham số, trong đó cho biết khi chuyển hướng có hiệu lực thi hành. Nếu khách hàng muốn tiếp tục để gửi hoặc nhận các phương tiện truyền thông cho URI này, khách hàng phải ra một yêu cầu teardown cho phiên hiện tại và thiết lập một phiên làm việc mới tại máy chủ được chỉ định.

S->C: REDIRECT rtsp://example.com/media.mp4 RTSP/1.0

CSeq: 11

Location: rtsp://bigserver.com:8001

Range: clock=19960213T143205Z-

[null - EMBEDDED (INTERLEAVED) DỮ LIỆU NHỊ PHÂN]

Một số thiết kế tường lửa và các trường hợp khác có thể buộc một máy chủ để interleave RTSP các phương pháp và các dòng dữ liệu. Interleaving này cũng nên tránh trừ khi cần thiết vì nó phức tạp máy khách và máy chủ hoạt động và áp dụng bổ sung. Dữ liệu nhị phân Interleaved chỉ nên được sử dụng nếu RTSP được thực hiện trên dữ liệu TCP. Stream chẳng hạn như RTP gói tin được đóng gói bởi một ký hiệu đô la ASCII (24 hệ thập lục phân), tiếp theo là một định danh kênh một byte, tiếp theo chiều dài của dữ liệu nhị phân đóng gói là số nguyên nhị phân hai byte, trong mạng tự byte. Các dòng dữ liệu sau ngay lập tức sau đó, không có CRLF một, nhưng bao gồm các tiêu đề giao thức lớp trên. Mỗi khối $ chứa đúng một giao thức lớp trên đơn vị dữ liệu, ví dụ như một RTP gói.

C->S: SETUP rtsp://example.com/media.mp4 RTSP/1.0

CSeq: 3

Transport: RTP/AVP/TCP;interleaved=0-1

S->C: RTSP/1.0 200 OK

CSeq: 3

Date: 05 Jun 1997 18:57:18 GMT

Transport: RTP/AVP/TCP;interleaved=0-1

Session: 12345678

C->S: PLAY rtsp://example.com/media.mp4 RTSP/1.0

CSeq: 4

Session: 12345678

S->C: RTSP/1.0 200 OK

CSeq: 4

Session: 12345678

Date: 05 Jun 1997 18:59:15 GMT

RTP-Info: url=rtsp://example.com/media.mp4;

seq=232433;rtptime=972948234

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

S->C: $\001{2 byte length}{"length" bytes RTCP packet}

Tham khảo

^ InfoWorld Media Group, Inc. (2 tháng 3 năm 1998). InfoWorld. InfoWorld Media Group, Inc. tr. 18. ISSN 0199-6649.
^ Rafael Osso (1999). Handbook of Emerging Communications Technologies: The Next Decade. CRC Press. tr. 42. ISBN 978-1-4200-4962-6.

[Inc.1998-1] InfoWorld Media Group, Inc. (2 tháng 3 năm 1998). InfoWorld. InfoWorld Media Group, Inc. tr. 18. ISSN 0199-6649.

[Osso1999-2] Rafael Osso (1999). Handbook of Emerging Communications Technologies: The Next Decade. CRC Press. tr. 42. ISBN 978-1-4200-4962-6.

[1]

[2]

@@ Dòng 8: / Dòng 8: @@
 RTSP được phát triển bởi RealNetworks, Netscape <ref name="Inc.1998">{{cite book|author=InfoWorld Media Group, Inc.|title=InfoWorld|url=https://books.google.com/books?id=DFEEAAAAMBAJ&pg=PA18|date=2 March 1998|publisher=InfoWorld Media Group, Inc.|page=18|issn=0199-6649}}</ref> và Đại học Columbia, với dự thảo đầu tiên đệ trình lên IETF năm 1996. <ref name="Osso1999">{{cite book|author=Rafael Osso|title=Handbook of Emerging Communications Technologies: The Next Decade|url=https://books.google.com/books?id=5fms2DW7mMUC&pg=PA42|year=1999|publisher=CRC Press|isbn=978-1-4200-4962-6|page=42}}</ref> Nó đã được tiêu chuẩn hóa bởi Nhóm làm việc Multiparty Multimedia Session Control (MMUSIC WG) của IETF và công bố như là RFC 2326 vào năm 1998.<ref name=":0"> RTSP 2.0 xuất bản như là RFC 7826 vào năm 2016 để thay thế cho RTSP 1.0. RTSP 2.0 dựa trên RTSP 1.0 nhưng không tương thích ngược với các cơ chế khác hơn là cơ chế đàm phán trong phiên bản cơ bản.
-=== [null 1.    Một số đặc điểm của RTSP] ===
+===  Một số đặc điểm của RTSP ===
 -        '''Khả năng mở rộng:''' Các phương pháp và các thông số mới có thể dễ dàng thêm vào RTSP.