Đồ Án Real Time Streaming Protocol (RTSP)

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (1.35 MB, 66 trang )

SVTH: Lê Sơn Đồ án: R ea

l T

i m

e

S

t r

e

a m

i n

g

P

ro

t o

c o

l

(

R T

SP)
MỤC LỤC:
CHƯƠNG I: GII THIU V GIAO THC RTSP 5
a.Quá trình khởi tạo kết nối giữa Client và Server: 45
b.Phân tích gói OPTION: 48
MỤC TIÊU ĐỒ ÁN:
RTSP (Real Time Streaming Protocol) là một giao thức điều khiển trên mạng được
thiết kế để sử dụng giao tiếp giữa máy client và máy streaming server. Giao thức này được sử
dụng để thiết lập và điều khiển phiên giao dịch giữa các máy tính (end points).
Trang 1
SVTH: Lê Sơn Đồ án: R ea

l T

i m

e

S

t r

e

a m

i n

g

P

ro

t o

c o

l

(

R T

SP)
Về hình thức giao thức RTSP cũng có nét tương đồng với giao thức HTTP, RTSP
định nghĩa một bộcác tín hiệu điều khiển tuần tự, phục vụ cho việc điều khiển quá trình
playback. Trong khi giao thức HTTP là giao thức không có trạng thái thì RTSP là giao thức
có xác định trạng thái. Một định danh được sử dụng khi cần thiết để theo dõi các phiên giao
dịch hiện tại của quá trình streaming video gọi là số hiệu session. Cũng giống như HTTP,
RTSP sử dụng TCP là giao thức để duy trì một kết nối đầu cuối tới đầu cuối và các thông
điệp điểu khiển của RTSP được gửi bởi máy client tới máy server.Nó cũng thực hiện điều
khiển lại các đáp trả từ máy server tới máy client. Cổng mặc định được sử dụng bởi giao thức
này là 554.
Real Time Streaming Protocol (RTSP) thiết lập và kiểm soát một hay một số dòng
thời gian đồng bộ của
các

phương tiện truyền thông liên tục như âm thanh và video. RTSP
hoạt động như một "mạng điều khiển từ xa" cho các máy chủ đa phương
tiện.
RTSP lợi dụng truyền chỉ vi phạm các dữ liệu thành các gói nhiều kích thước theo
băng thông có sẵn
giữa
máy khách và máy chủ. Khi đủ các gói tin đã nhận được của
server, client
có thể
play một gói tin. Người sử dụng có thể bắt đầu nghe gần như ngay
lập tức mà không cần phải có
được
toàn bộ các tập tin media.
Streaming Time Protocol Real còn là một giao thức để kiểm soát các phiên dữ liệu,
cung cấp cách để lựa chọn các kênh phân phối như UDP, TCP và IP multicast.
Các
cơ chế
giao nhận chỉ dựa trên RTP. RTSP đã được thiết kế dựa trên RTP để kiểm soát và cung
cấp nội dung thời gian thực. Vì vậy, RTSP triển khai sẽ có thể tận dụng lợi thế của các
cải
tiến RTP, như nén tiêu đề RTP. Mặc dù RTSP có thể được sử dụng với unicast, sử dụng
của nó có thể
giúp
để sự thay đổi trơn tru từ unicast multicast IP với RTP. RTSP cũng có
thể được
sử
dụng với RSVP để thiết lập và quản lý các phiên họp trực tuyến dành riêng
băng
thông.


Đề tài này được chia làm 4 phần
Trang 2
SVTH: Lê Sơn Đồ án: R ea

l T

i m

e

S

t r

e

a m

i n

g

P

ro

t o

c o

l

(

R T

SP)
 :Giới thiệu khái quát về RTSP (Real Time Streaming Protocol) là
một giao thức điều khiển trên mạng được thiết kế để sử dụng giao tiếp giữa máy client
và máy streaming server.
 : Giới thiệu các tham số của giao thức RTSP.
 Chương 3Giới thiệu các thông điệp trao dổi qua lại giữa Client và
Server:
 :Mô Hình Thực Hiện
- Bước 1: Cấu hình các router và sử dụng định tuyến rip .
- Bước 2: Cấu hình Stream trên máy Server sử dụng phần mềm VLC media player .
- Bước 3: Cấu hình trên máy Client để xem đoạn video máy Server đang phát, sử dụng
phần mềm VLC media player để cấu hình .
PHỤ LỤC BẢNG:
Bảng địa chỉ ip: trang 36
Trang 3
SVTH: Lê Sơn Đồ án: R ea

l T

i m

e

S

t r

e

a m

i n

g

P

ro

t o

c o

l

(

R T

SP)
PHỤ LỤC HÌNH ẢNH:
Hình 2.7 Các kết nối hình thành trong phiên làm việc
IPTV: trang
Trang 4

SVTH: Lê Sơn Đồ án: R ea

l T

i m

e

S

t r

e

a m

i n

g

P

ro

t o

c o

l

(

R T

SP)
H 1 : trang 39
H 2: trang 40
H 3: trang 40
H 4: trang 41
H 5: trang 41
H 6: trang 42
H 7: trang 42
H 8: trang 43
H 9: trang 43
H 10: trang 44
H 11: trang 44
H 12: trang 45
 !"#$
 %&'()''*+,+-
./'
Trang 5
SVTH: Lê Sơn Đồ án: R ea

l T

i m

e

S

t r

e

a m

i n

g

P

ro

t o

c o

l

(

R T

SP)
RTSP (Real Time Streaming Protocol) là một giao thức điều khiển trên mạng được
thiết kế để sử dụng giao tiếp giữa máy client và máy streaming server. Giao thức này được sử
dụng để thiết lập và điều khiển phiên giao dịch giữa các máy tính (end points).
Về hình thức giao thức RTSP cũng có nét tương đồng với giao thức HTTP, RTSP

định nghĩa một bộcác tín hiệu điều khiển tuần tự, phục vụ cho việc điều khiển quá trình
playback. Trong khi giao thức HTTP là giao thức không có trạng thái thì RTSP là giao thức
có xác định trạng thái. Một định danh được sử dụng khi cần thiết để theo dõi các phiên giao
dịch hiện tại của quá trình streaming video gọi là số hiệu session. Cũng giống như HTTP,
RTSP sử dụng TCP là giao thức để duy trì một kết nối đầu cuối tới đầu cuối và các thông
điệp điểu khiển của RTSP được gửi bởi máy client tới máy server.Nó cũng thực hiện điều
khiển lại các đáp trả từ máy server tới máy client. Cổng mặc định được sử dụng bởi giao thức
này là 554.
Real Time Streaming Protocol (RTSP) thiết lập và kiểm soát một hay một số dòng
thời gian đồng bộ của
các
phương tiện truyền thông liên tục như âm thanh và video. RTSP
hoạt động như một "mạng điều khiển từ xa" cho các máy chủ đa phương
tiện.
RTSP lợi dụng truyền chỉ vi phạm các dữ liệu thành các gói nhiều kích thước theo
băng thông có sẵn
giữa
máy khách và máy chủ. Khi đủ các gói tin đã nhận được của
server, client
có thể
play một gói tin. Người sử dụng có thể bắt đầu nghe gần như ngay
lập tức mà không cần phải có
được
toàn bộ các tập tin media.
Streaming Time Protocol Real còn là một giao thức để kiểm soát các phiên dữ liệu,
cung cấp cách để lựa chọn các kênh phân phối như UDP, TCP và IP multicast.
Các
cơ chế
giao nhận chỉ dựa trên RTP. RTSP đã được thiết kế dựa trên RTP để kiểm soát và cung
cấp nội dung thời gian thực. Vì vậy, RTSP triển khai sẽ có thể tận dụng lợi thế của các

cải
tiến RTP, như nén tiêu đề RTP. Mặc dù RTSP có thể được sử dụng với unicast, sử dụng
của nó có thể
giúp
để sự thay đổi trơn tru từ unicast multicast IP với RTP. RTSP cũng có
thể được
sử
dụng với RSVP để thiết lập và quản lý các phiên họp trực tuyến dành riêng
băng
thông.
RTSP là cố ý tương tự như trong cú pháp và hoạt động HTTP/1.1. Tuy nhiên, nó khác nhau
trong một
số
khía cạnh quan trọng từ
HTTP:
Trang 6
SVTH: Lê Sơn Đồ án: R ea

l T

i m

e

S

t r

e

a m

i n

g

P

ro

t o

c o

l

(

R T

SP)
 RTSP giới thiệu một số phương pháp mới và có một định danh giao thức khác
nhau.
 Một máy chủ RTSP cần để duy trì trạng thái mặc định trong hầu hết các trường
hợp, như trái
ngược
với bản chất không trạng thái của
HTTP.
Cả hai máy chủ RTSP và khách hàng có thể vấn đề yêu cầu dữ
liệu

 Dữ liệu được truyền out-of-band bởi một giao thức khác nhau. (Có một ngoại lệ
này.)
 RTSP được định nghĩa để sử dụng ISO 10646 (UTF-8) hơn là ISO 8859-1, phù
hợp với những
phát
triển hiện nay
HTML.
 URI Yêu cầu luôn luôn có chứa các URI tuyệt
đối.
Các hoạt động hỗ trợ bởi
RTSP:
 Retrieval of media from media server: Khách hàng có thể yêu cầu đến máy chủ
phương tiện
truyền
thông mô tả về phiên họp có nghĩa là sẽ bắt đầu. Yêu cầu có thể
được cấp thông qua HTTP, ví
dụ.
Khách hàng có thể kiểm soát các phương tiện truyền
thông bằng cách yêu cầu các máy chủ để
cung
cấp chỉ có phạm vi quy định của
tream.
 Invitation of a media server to a conference: Lời mời của một máy chủ phương tiện
truyền thông
cho
một hội nghị của những người tham gia một hội nghị trực tuyến có thể
mời một máy chủ phương
tiện
truyền thông tham gia, để lấy các tập tin media có sẵn tại
máy chủ đó, hoặc cho các mục đích ghi

âm.
 Addition of media to an existing presentation:Máy chủ có thể thông báo cho khách
hàng mà
các
phương tiện truyền thông bổ
sung.
 012.34-5.(6'*+,+-
./'
Client-Server Computing Model RTSP hoạt động sử dụng chế độ client-server.
Dưới chế độ này
3
liên kết riêng lẻ được thiết lập để cung cấp sự truyền thông giữa
RTSP client đang chạy trên
một
IPTVCD và một VoD server được chỉ ra ở hình
dưới:
Trang 7
SVTH: Lê Sơn Đồ án: R ea

l T

i m

e

S

t r

e

a m

i n

g

P

ro

t o

c o

l

(

R T

SP)
Hình 2.7 Các kết nối hình thành trong phiên làm việc
IPTV
Trang 8
SVTH: Lê Sơn Đồ án: R ea

l T

i m

e

S

t r

e

a m

i n

g

P

ro

t o

c o

l

(

R T

SP)

 Một liên kết báo hiệu ngoài được thiết lập để mang thông tin điều khiển RTSP.
Giao
thức lớp vận chuyển được sử dụng bởi liên kết này có thể là TCP hoặc UDP.
Trong
trường hợp một mạng DVB, một liên kết TCP bền vững được sử dụng. Ngoài việc
mang
các thông tin điều khiển kết nối này còn mang cả nội dụng của
IPTV.
 Một liên kết RTP dựa trên UDP được thiết lập để mang nội dung IPTV được mã
hóa.
Liên kết thứ 3 này mang RTCP trên UDP để mang các thông tin đồng bộ. Sẽ cung
cấp
các phản hồi về server dựa trên chất lượng của luồng đang được phân phối đến
IPTVCD.
Các phương pháp RTSP cung cấp một proxy với tất cả các thông tin cần thiết để mở cổng,
bản đồ
và
các cảng gần SETUP và teardown. Máy chủ cần phải duy trì trạng thái phiên
để có thể tương
quan
RTSP yêu cầu với một dòng suối. Các phương pháp đóng một vai
trò trung tâm trong việc phân
bổ
và sử dụng tài nguyên dòng trên máy chủ là SETUP,
PLAY, RECORD, PAUSE, và
teardown.
- Hỗ trợ cả unicast và mutilcast. RTSP cho phép để điều khiển cả các
luồng multicast
và
unicast. Nhưng trong luồng mutilcast không cho phép

khả năng tua nhanh, tua
lùi.
- Độc lập vơi giao thức lớp vận chuyển. RTSP có thể hoạt động trên cả UDP
và
TCP.
- Làm việc trong mối liên kết với RTP. RTSP và RTP làm việc cùng
nhau để phân phối
nội
dung qua
mạng.
- Cấu trúc bản tin của RTSP. Bản tin được chia ra làm hai loại: yêu cầu và phúc
đáp.
Trang 9
SVTH: Lê Sơn Đồ án: R ea

l T

i m

e

S

t r

e

a m

i n

g

P

ro

t o

c o

l

(

R T

SP)
- Cấu trúc chung của RTSP request là : {method name} {URL} {Protocol Version}
CRLF

{Parameters}.
- Cấu trúc chung của RTSP response là: {Protocol Version} {status code} {reason
phrase}
CRLF
{Parameters}.
7 839,-:-;
- Aggregate control: (Tổng hợp kiểm soát)
Sự 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 máy chủ. Đối
với nguồn cấp dữ liệu âm thanh / video, điều này có nghĩa là Client có thể ra một thông báo

phát hoặc tạm dừng để kiểm soát cả âm thanh và các nguồn cấp dữ liệu video.
- Connection:
Một lớp vận chuyển ảo được thiết lập giữa hai chương trình cho mục đích giao tiếp.
- Container file:
Một tập tin có thể chứa nhiều luồng phương tiện truyền thông thường bao gồm một
bản trình bày khi chơi với nhau. RTSP máy chủ có thể cung cấp kiểm soát tổng hợp về
những tập tin này, mặc dù các khái niệm về một file container không được nhúng trong giao
thức.
- Continuous media:
Dữ liệu mà có một mối quan hệ thời gian giữa nguồn và bộ chứa, các bộ chứa phải tạo
quan hệ thời gian tồn tại nguồn. Ví dụ phổ biến hầu hết các phương tiện truyền thông liên tục
âm thanh và video chuyển động. Phương tiện truyền thông liên tục có thể là thời gian thực
(tương tác), có thời gian "chặt" mối quan hệ giữa nguồn và bộ chứa, hoặc trực tiếp (phát lại),
nơi mà mối quan hệ được chặt chẽ hơn.
- Media initialization:
Datatype / codec khởi tạo cụ thể. Điều này bao gồm nhiều thứ như clockrates, bảng
màu sắc, vv Bất kỳ thông tin giao thông độc lập mà là yêu cầu của một khách hàng để phát
lại của một dòng phương tiện truyền thông xảy ra trong giai đoạn khởi tạo phương tiện
truyền thông của dòng thiết lập.
- Media parameter: Phương tiện truyền thông tham số:
Trang 10
SVTH: Lê Sơn Đồ án: R ea

l T

i m

e

S

t r

e

a m

i n

g

P

ro

t o

c o

l

(

R T

SP)
Tham số cụ thể cho một loại phương tiện truyền thông mà có thể thay đổi trước hoặc
trong quá trình phát lại luồng.
Trang 11
SVTH: Lê Sơn Đồ án: R ea

l T

i m

e

S

t r

e

a m

i n

g

P

ro

t o

c o

l

(

R T

SP)
- Media server:
Máy chủ cung cấp dịch vụ phát lại hoặc ghi âm cho một hoặc nhiều luồng phương tiện truyền
thông. Phương tiện truyền thông luồng khác nhau trong bản mô tả có thể bắt nguồn từ máy
chủ media khác nhau. Một máy chủ phương tiện truyền thông có thể nằm trên cùng một hoặc
một máy chủ khác nhau như server web.
- Media server indirection:
Chuyển hướng của một client media đến một server media khác nhau.
- (Media) stream:
Một Media duy nhất, ví dụ như: một dòng âm thanh hoặc một dòng video cũng như
một bảng duy nhất hoặc một nhóm ứng dụng chia sẻ. Khi sử dụng RTP, một stream bao gồm
tất cả các gói tin RTP và RTCP được tạo ra bởi một nguồn trong một phiên RTP. Điều này
tương đương với định nghĩa của một streamDSM-CC.
- Message:
Các đơn vị cơ bản của RTSP thông tin liên lạc, bao gồm một chuỗi các octet có cấu trúc phù
hợp với cú pháp và được truyền qua một kết nối hoặc một giao thức kết nối.
- Participant:
Một bên tham gia có thể là một máy tính, một bản ghi media hoặc playback server.
- Presentation:
Một tập hợp của một hoặc nhiều luồng biểu diŠn cho client như là một nguồn cấp dữ
liệu media hoàn chỉnh, bằng cách sử dụng bản mô tả trình bày theo quy định dưới đây. ‹ hầu
hết các trường hợp trong bối cảnh RTSP, điều này hàm ý kiểm soát tổng hợp của những
luồng, nhưng không phải.
- Presentation description:
Mô tả trình bày có chứa thông tin về một hoặc nhiều phương tiện truyền thông luồng
trong bản mô tả, chẳng hạn như các thiết lập mã hóa, địa chỉ mạng và thông tin về nội dung.
Các giao thức khác IETF như SDP (RFC 2327 [6]) sử dụng thuật ngữ "session" cho một bài

Trang 12
SVTH: Lê Sơn Đồ án: R ea

l T

i m

e

S

t r

e

a m

i n

g

P

ro

t o

c o

l

(

R T

SP)
thuyết trình trực tiếp. Mô tả trình bày có thể mất một số định dạng khác nhau, bao gồm
nhưng không giới hạn định dạng SDP mô tả phiên.
- Response:
Một đáp ứng RTSP. Nếu đáp ứng HTTP có nghĩa là, được chỉ định một cách rõ ràng.
- Request:
Một yêu cầu RTSP. Nếu một yêu cầu HTTP có nghĩa là, được chỉ định một cách rõ ràng.
- RTSP session:
Một RTSP hoàn thành "giao dịch", ví dụ như: xem một bộ phim. Một phiên giao dịch
thường bao gồm một client thiết lập một cơ chế vận chuyển cho các luồng media liên tục
(SETUP), bắt đầu các dòng khi PLAY hay RECORD, và đóng các luồng với teardown.
- Transport initialization:
Việc thoản thuận các thông tin vận chuyển (ví dụ: port numbers, giao thức vận
chuyển) giữa client và server.
 $3 '-:$3-<83.,8=
RTSP có các thuộc tính sau:
- Extendable (mở rộng):
Những phương pháp mới và các thông số có thể dŠ dàng thêm vào RTSP.
- Easy to parse (DŠ dàng để phân tích):
RTSP có thể được phân tích cú pháp theo tiêu chuẩn HTTP hoặc MIME phân tích cú
pháp.
- Secure(An toàn):
RTSP tái sử dụng cơ chế bảo mật web. Tất cả các cơ chế xác thực HTTP cơ bản như
(RFC 2068 [2, Mục 11.1) và phân loại xác thực (RFC 2069 [8]) là áp dụng trực tiếp. Có thể
tái sử dụng vận chuyển hoặc cơ chế an ninh mạng.

- Transport-independent:
Trang 13
SVTH: Lê Sơn Đồ án: R ea

l T

i m

e

S

t r

e

a m

i n

g

P

ro

t o

c o

l

(

R T

SP)
RTSP có thể sử dụng một giao thức gói tin không đáng tin cậy (UDP) (RFC 768 [9]), một
giao thức gói tin đáng tin cậy (RDP, RFC 1151, không được sử dụng rộng rãi hoặc một luồng
giao thức đáng tin cậy như TCP (RFC 793 [11] ) vì nó thực hiện mức độ tin cậy ứng dụng.
- Multi-server capable:
Mỗi stream media trong bản mô tả thể nằm trên một server khác nhau. client sẽ tự
động thiết lập các phiên kiểm soát đồng thời với các server media khác nhau. Media đồng bộ
hóa được thực hiện ở mức vận chuyển.
- Control of recording devices (kiểm soát các thiết bị ghi):
Giao thức có thể kiểm soát cả hai thiết bị ghi và phát, cũng như các thiết bị có thể thay
thế giữa hai chế độ (VCR).
Suitable for professional applications (thích hợp cho các ứng dụng chuyên nghiệp):
RTSP hỗ trợ frame-level chính xác thông qua các nhãn thời gian SMPTE để cho phép
chỉnh sửa kỹ thuật số từ xa.
- Presentation description neutral:
Giao thức này không áp đặt một bản mô tả trình bày cụ thể hoặc định dạng Metafile và có thể
chuyển tải các loại định dạng để sử dụng. Tuy nhiên, bản mô tả trình bày phải có ít nhất một
RTSP URI.
- Proxy and firewall friendly:
Giao thức này được dŠ dàng xử lý bởi cả hai ứng dụng và lớp vận chuyển (SOCKS
[14]) tường lửa. Tường lửa cần hiểu được phương pháp SETUP để mở một "lỗ thủng" cho
các media stream UDP.
- HTTP-friendly:
RTSP tái sử dụng khái niệm HTTP, do đó kết cấu 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 (Nền tảng cho Internet Content Selection [15,16]) cho liên
kết nhãn với nội dung. Tuy nhiên, RTSP không chỉ thêm phương pháp HTTP từ các phương
tiện truyền thông kiểm soát liên tục yêu cầu máy chủ trong hầu hết các trường hợp.
- Appropriate server control:
Trang 14
SVTH: Lê Sơn Đồ án: R ea

l T

i m

e

S

t r

e

a m

i n

g

P

ro

t o

c o

l

(

R T

SP)
Nếu một client có thể khởi động một stream, nó có khả năng ngừng một stream. Máy chủ
không thể khởi động một luồng cho client, client không thể ngừng một stream.
- Transport negotiation:
Client có thể thương lượng phương thức vận chuyển trước khi thực sự cần phải xử lý một
luồng phương tiện truyền thông liên tục.
> ?@.8A,#$
Không phải tất cả các server media có cùng chức năng, server media sẽ hỗ trợ các yêu cầu
khác.
Ví dụ:
* Một máy chủ chỉ có thể có khả năng phát lại, không hỗ trợ các yêu cầu RECORD.
* Một máy chủ không có khả năng tìm kiếm (vị trí tuyệt đối) chỉ để hỗ trợ các sự kiện trực
tiếp.
* Một số máy chủ có thể không hỗ trợ thiết lập các thông số stream và không hỗ trợ
GET_PARAMETER và SET_PARAMETER.
RTSP có thể được mở rộng theo ba cách, được liệt kê ở đây theo thứ tự về tầm quan trọng
các thay đổi được hỗ trợ:
* Phương pháp hiện nay có thể được mở rộng với các thông số mới, miŠn là các thông số này
có thể được bỏ qua bởi người nhận. Nếu client cần được xác nhận khi một phương pháp mở
rộng không được hỗ trợ, một thẻ tương ứng với phần mở rộng có thể được thêm vào trong
các yêu cầu.

* Các phương pháp mới có thể được thêm vào. Nếu người nhận tin nhắn không hiểu yêu cầu,
nó sẽ trả lời với 501 mã lỗi (Không thực hiện) và người gửi không nên cố gắng sử dụng
phương pháp này một lần nữa. Client cũng có thể sử dụng phương pháp OPTIONS để hỏi về
các phương pháp hỗ trợ bởi máy chủ. Các máy chủ SHOULD liệt kê những phương thức hỗ
trợ bằng cách sử dụng response header công cộng.
* Phiên bản mới của giao thức có thể được xác định, cho phép hầu như mọi phương diện
(ngoại trừ vị trí của số phiên bản giao thức) để thay đổi.
Trang 15
SVTH: Lê Sơn Đồ án: R ea

l T

i m

e

S

t r

e

a m

i n

g

P

ro

t o

c o

l

(

R T

SP)
B !C83+::!<83+.,-
Bản mô tả và luồng phương tiện truyền thông có thể được xác định bởi một URL
RTSP. Mô tả tổng thể và thuộc tính của các phương tiện truyền thông được tạo thành được
định nghĩa bởi file mô tả, định dạng trong số đó là ngoài phạm vi của tiêu chuẩn này. tập tin
trình bày mô tả có thể thu được bằng cách cho khách hàng sử dụng.
HTTP hoặc các phương tiện khác như email và có thể không nhất thiết được lưu trữ trên máy
chủ phương tiện truyền thông.
Đối với mục đích của các đặc điểm kỹ thuật này, một bản mô tả trình bày giả định để
mô tả một hoặc nhiều presentations, trong số đó duy trì một trục thời gian phổ biến. Để đơn
giản trình bày và không mất tính tổng quát, giả định rằng bản mô tả trình bày đúng có chứa
một trình bày. Một bản trình bày có thể chứa một số phương tiện truyền thông luồng.
Các tập tin mô tả trình bày chứa một mô tả của các dòng phương tiện truyền thông
trình bày, bao gồm cả mã ký tự, ngôn ngữ, và các thông số khác cho phép các khách hàng để
lựa chọn sự kết hợp của các phương tiện truyền thông phù hợp.Trong mô tả trình bày, mỗi
stream media đó là cá nhân kiểm soát bởi RTSP được xác định bởi một URL RTSP, mà chỉ
vào việc xử lý máy chủ phương tiện truyền thông rằng các dòng phương tiện truyền thông cụ
thể và tên các luồng được lưu trữ trên máy chủ đó. Một số luồng phương tiện truyền thông có

thể được đặt trên các server khác, ví dụ âm thanh và video có thể được phân chia qua nhiều
máy chủ để chia sẻ tải. Mô tả cũng liệt kê phương pháp vận chuyển máy chủ đa năng.
Bên cạnh các thông số phương tiện truyền thông, địa chỉ đích và cổng mạng cần được
xác định. Một số phương thức hoạt động có thể được phân biệt:
Unicast:
Các phương tiện truyền thông được chuyển đến mã nguồn của theo yêu cầu RTSP, với
số cổng được lựa chọn bởi client. Ngoài ra, các phương tiện truyền thông được truyền tải trên
các luồng đáng tin cậy giống như RTSP.
Trang 16
SVTH: Lê Sơn Đồ án: R ea

l T

i m

e

S

t r

e

a m

i n

g

P

ro

t o

c o

l

(

R T

SP)
Multicast máy chủ chọn địa chỉ:
Các máy chủ phương tiện truyền thông chọn các địa chỉ multicast và cổng. Đây là
trường hợp điển hình cho một truyền trực tiếp hoặc gần phương tiện truyền thông theo yêu
cầu.
Multicast khách hàng lựa chọn địa chỉ:
Nếu máy chủ là để tham gia vào một conference multicast, địa chỉ multicast, port và
key mã hóa, được khởi tạo bởi các media bên ngoài.
D #$#.+.8=
RTSP điều khiển một luồng thông qua một giao thức riêng biệt, độc lập của các kênh
điều khiển.Ví dụ: RTSP điều khiển một kết nối TCP trong khi các luồng dữ liệu thông qua
UDP. Như vậy dữ liệu truyền liên tục ngay cả khi không có yêu cầu RTSP.
Ngoài ra, trong khoảng thời gian tồn tại, một media stream có thể được kiểm soát bởi
RTSP và các kết nối TCP khác.Vì vậy, máy chủ cần duy trì "trạng thái phiên" để có thể
tương ứng RTSP.
Nhiều phương pháp trong RTSP không quan trọng. Tuy nhiên, đóng một vai trò trung
tâm trong việc phân bổ và sử dụng tài nguyên trên máy chủ: SETUP, PLAY, RECORD,

PAUSE, và teardown.
E 8:+.,-=,<F,.!.83$3 '-:=G%H,I1+JCK,'2',+-./'L2'M
RTSP có một vài trùng lặp về tính năng với HTTP. Nó cũng có thể tương tác với
HTTP thực hiện thông qua một trang web. Các đặc điểm kỹ thuật giao thức nhằm mục đích
cho phép các hand-off khác nhau giữa một máy chủ web và máy chủ các phương tiện truyền
thông RTSP. Ví dụ bằng cách sử dụng HTTP hoặc RTSP, làm giảm roundtrips trong trình
duyệt web, nhưng cũng cho phép máy chủ độc lập RTSP và client mà không dựa trên HTTP.
Tuy nhiên, RTSP khác HTTP ở chổ cung cấp dữ liệu diŠn ra out-of-band trong một
giao thức khác. HTTP là một giao thức không cân xứng client và server. Trong RTSP cả hai
media client và media server có thể đưa ra yêu cầu.Trong khi hầu hết các phương tiện truyền
thông thời gian thực sẽ sử dụng RTP là một giao thức vận chuyển, RTSP không bị ràng buộc
RTP.
Trang 17
SVTH: Lê Sơn Đồ án: R ea

l T

i m

e

S

t r

e

a m

i n

g

P

ro

t o

c o

l

(

R T

SP)
 %#N!"#$
$3 '-:$+3+98.83=
#$83=,-
ng dụng HTTP thay thế bởi RTSP.
#$O
"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.
7-P838'8A8.,P,83=
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.
Trang 18
SVTH: Lê Sơn Đồ án: R ea

l T

i m

e

S

t r

e

a m

i n

g

P

ro

t o

c o

l

(

R T

SP)
#8==,-A8.,P,83=
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 )
>#%$?8:+.,C8,98=.+9<=
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
B-39+:$:+;,98
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.
Trang 19
SVTH: Lê Sơn Đồ án: R ea

l T

i m

e

S

t r

e

a m

i n

g

P

ro

t o

c o

l

(

R T

SP)
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-
DQ=-:1.8,98
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 November 8, 1996 at 14h37 and 20 and a quarter seconds
UTC:
19961108T143720.25Z
E!<.,-+=
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:
Trang 20
SVTH: Lê Sơn Đồ án: R ea

l T

i m

e

S

t r

e

a m

i n

g

P

ro

t o

c o

l

(

R T

SP)
Option-tag = 1 * xchar
E8,=.83,8F!<.,-+=F,.
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).
R#$%8==+8
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.
1.9.1 Message Types
1.9.2 Message Headers

1.9 3 Message Body
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):
Trang 21
SVTH: Lê Sơn Đồ án: R ea

l T

i m

e

S

t r

e

a m

i n

g

P

ro

t o

c o

l

(

R T

SP)
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).
S883+:8+A83T,8:A=
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
8I18=.
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
8I18=.O,8
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
Trang 22
SVTH: Lê Sơn Đồ án: R ea

l T

i m

e

S

t r

e

a m

i n

g

P

ro

t o

c o

l

(

R T

SP)
| "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
78=<-=8
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
#.+.1=UO,8
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.
Trang 23
SVTH: Lê Sơn Đồ án: R ea

l T

i m

e

S

t r

e

a m

i n

g

P

ro

t o

c o

l

(

R T

SP)
Status-Code = "100" ; Continue
| "200" ; OK
| "201" ; Created

| "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.
Trang 24
SVTH: Lê Sơn Đồ án: R ea

l T

i m

e

S

t r

| WWW-Authenticate ; Section 12.44
>?.,.;
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
B-8'.,-=
RTSP có thể được truyền theo nhiều cách khác nhau:
Trang 25

Đồ Án Real Time Streaming Protocol (RTSP)

Tài liệu liên quan

Tài liệu bạn tìm kiếm đã sẵn sàng tải về