stanford-oval/wikipedia huggingface dataset:
Real Time Streaming Protocol
Một số đặc điểm của RTSP > [null 3.     Các tham số của giao thức RTSP] (protocol parameters) > [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).
Một số đặc điểm của RTSP > [null 3.     Các tham số của giao thức RTSP] (protocol parameters) > [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
Một số đặc điểm của RTSP > [null 3.     Các tham số của giao thức RTSP] (protocol parameters) > [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
Một số đặc điểm của RTSP > [null 3.     Các tham số của giao thức RTSP] (protocol parameters) > [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
Một số đặc điểm của RTSP > [null 3.     Các tham số của giao thức RTSP] (protocol parameters) > [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
Một số đặc điểm của RTSP > [null 3.     Các tham số của giao thức RTSP] (protocol parameters) > [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
Một số đặc điểm của RTSP > [null 3.     Các tham số của giao thức RTSP] (protocol parameters) > [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
Một số đặc điểm của RTSP > [null 3.     Các tham số của giao thức RTSP] (protocol parameters) > [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).
Một số đặc điểm của RTSP > [null 3.     Các tham số của giao thức RTSP] (protocol parameters) > 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
Một số đặc điểm của RTSP > [null 3.     Các tham số của giao thức RTSP] (protocol parameters) > [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
Một số đặc điểm của RTSP > [null 3.     Các tham số của giao thức RTSP] (protocol parameters) > [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[liên kết hỏng] 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
Một số đặc điểm của RTSP > [null 3.     Các tham số của giao thức RTSP] (protocol parameters) > [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[liên kết hỏng] 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
Một số đặc điểm của RTSP > [null 3.     Các tham số của giao thức RTSP] (protocol parameters) > [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[liên kết hỏng] 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
Một số đặc điểm của RTSP > [null 3.     Các tham số của giao thức RTSP] (protocol parameters) > [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[liên kết hỏng] 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[liên kết hỏng]
Một số đặc điểm của RTSP > [null 3.     Các tham số của giao thức RTSP] (protocol parameters) > [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[liên kết hỏng] RTSP/1.0
CSeq: 834
Session: 12345678
S->C: RTSP/1.0 200 OK
CSeq: 834
Date: 23 Jan 1997 15:35:06 GMT
Một số đặc điểm của RTSP > [null 3.     Các tham số của giao thức RTSP] (protocol parameters) > [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[liên kết hỏng] RTSP/1.0
CSeq: 892
Session: 12345678
S->C: RTSP/1.0 200 OK
CSeq: 892
Một số đặc điểm của RTSP > [null 3.     Các tham số của giao thức RTSP] (protocol parameters) > [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[liên kết hỏng] 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
Một số đặc điểm của RTSP > [null 3.     Các tham số của giao thức RTSP] (protocol parameters) > [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[liên kết hỏng] 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
Một số đặc điểm của RTSP > [null 3.     Các tham số của giao thức RTSP] (protocol parameters) > [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[liên kết hỏng] RTSP/1.0
CSeq: 11
Location: rtsp://bigserver.com:8001[liên kết hỏng]
Range: clock=19960213T143205Z-
Một số đặc điểm của RTSP > [null 3.     Các tham số của giao thức RTSP] (protocol parameters) > [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[liên kết hỏng] 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[liên kết hỏng] 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[liên kết hỏng];
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}
Achyrocalyx decaryi

| Achyrocalyx decaryi> Phân loại khoa học |
| --- | --- |
Giới (regnum): Plantae
(không phân hạng): Angiospermae
(không phân hạng): Eudicots
Bộ (ordo): Lamiales
Họ (familia): Acanthaceae
Phân họ (subfamilia): Acanthoideae
Tông (tribus): Acantheae
Chi (genus): Achyrocalyx
Loài (species): A. decaryi
Danh pháp hai phần
Achyrocalyx decaryi Benoist, 1929 công bố 1930 
Achyrocalyx decaryi là một loài thực vật có hoa trong họ Ô rô. Loài này được Raymond Benoist mô tả khoa học đầu tiên năm 1929 công bố năm 1930.
Phân bố

Loài đặc hữu Madagascar.
Chú thích

Tư liệu liên quan tới Achyrocalyx decaryi tại Wikimedia Commons
Dữ liệu liên quan tới Achyrocalyx decaryi tại Wikispecies
↑  Raymond Benoist, 1930. Achyrocalyx decaryi. Bulletin de la Société Botanique de France 76: 1037.
↑  The Plant List (2010). “Achyrocalyx decaryi”. Truy cập ngày 4 tháng 6 năm 2013.
↑  Achyrocalyx decaryi trong Plants of the World Online. Tra cứu ngày 10-12-2020.
| --- | --- |
Thẻ nhận dạng đơn vị phân loại:  Wikidata: Q15336977  Wikispecies: Achyrocalyx decaryi  APDB: 202956  GBIF: 3772645  iNaturalist: 894469  IPNI: 44936-1  NCBI: 328102  Plant List: kew-2617796  POWO: urn:lsid:ipni.org:names:44936-1  Tropicos: 101407
Callipseustes variegata

| Callipseustes variegata> Phân loại khoa học |
| --- | --- |
Giới (regnum): Animalia
Ngành (phylum): Arthropoda
Lớp (class): Insecta
Bộ (ordo): Lepidoptera
Họ (familia): Geometridae
Chi (genus): Callipseustes
Loài (species): C. variegata
Danh pháp hai phần
Callipseustes variegata Bastelberger 1908 
Callipseustes variegata là một loài bướm đêm trong họ Geometridae.
Chú thích

↑  Bisby, F.A.; Roskov, Y.R.; Orrell, T.M.; Nicolson, D.; Paglinawan, L.E.; Bailly, N.; Kirk, P.M.; Bourgoin, T.; Baillargeon, G.; Ouvrard, D. (2011). “Species 2000 & ITIS Catalogue of Life: 2011 Annual Checklist”. Species 2000: Reading, UK. Truy cập ngày 24 tháng 9 năm 2012.