ĐỀ TÀI :NGHIÊN CỨU GIAO THỨC RTP VÀ XÂY DỰNG ỨNG DỤNG VIDEO STREAMING

ĐẠI HỌC ĐÀ NẴNG

TRƯỜNG ĐẠI HỌC BÁCH KHOA

KHOA CÔNG NGHỆ THÔNG TIN
Tel. (84-511) 736 949, Fax. (84-511) 842 771
Website: itf.ud.edu.vn, E-mail:

LUẬN VĂN TỐT NGHIỆP KỸ SƯ
NGÀNH CÔNG NGHỆ THÔNG TIN
MÃ NGÀNH : 05115

ĐỀ TÀI :
NGHIÊN CỨU GIAO THỨC RTP VÀ XÂY DỰNG ỨNG DỤNG
VIDEO STREAMING
Mã số : 06T1-108
06T1-118
Ngày bảo vệ : 15,16/06/2011

SINH VIÊN : HUỲNH PHƯƠNG ĐỨC
NGUYỄN VĂN HƯNG
LỚP :
06T1
CBHD :
KS.GVC.NGUYỄN THẾ XUÂN LY
ĐÀ NẴNG, 06/2011


LỜI CẢM ƠN
Chúng em xin gửi lời cảm ơn chân thành đến tất cả các Thầy Cô đã giảng dạy chúng
em trong suốt thời gian qua. Cảm ơn thầy KS.GVC.Nguyễn Thế Xuân Ly - người đã

hướng dẫn, gợi mở và đóng góp ý tưởng để chúng em thực hiện đề tài này.
Bên cạnh đó, để hoàn thành đề tài này, chúng em cũng đã nhận được rất nhiều sự
giúp đỡ, những lời động viên quý báu của các bạn bè, các anh chị thân hữu; chúng
em xin hết lòng ghi ơn.
Tuy nhiên, do thời gian hạn hẹp, mặc dù đã nỗ lực hết sức mình, nhưng chắc rằng đồ
án khó tránh khỏi thiếu sót. Chúng em rất mong nhận được sự thông cảm và chỉ bảo
tận tình của quý Thầy cô và các bạn.


LỜI CAM ĐOAN
Tôi xin cam đoan :
1

Những nội dung trong luận văn này là do tôi thực hiện dưới sự hướng dẫn
trực tiếp của thầy KS.GVC.Nguyễn Thế Xuân Ly.

2

Mọi tham khảo dùng trong luận văn đều được trích dẫn rõ ràng tên
tác giả, tên công trình, thời gian, địa điểm công bố.

3

Mọi sao chép không hợp lệ, vi phạm quy chế đào tạo, hay gian trá,
tôi xin chịu hoàn toàn trách nhiệm.
Sinh viên,
Huỳnh Phương Đức
Nguyễn Văn Hưng

MỤC LỤC
CƠ SỞ LÝ THUYẾT..........................................................................................3
.I Khái niệm truyền dòng:.........................................................................................3
.II Quá trình truyền dòng:.........................................................................................4

CÁC GIAO THỨC TRUYỀN TẢI CƠ BẢN...................................................9
.I Giao thức TCP:(Transmision Control Protocol)....................................................9
.I.1. Đặc điểm giao thức TCP:............................................................................9
.I.2. Cấu trúc đơn vị truyền tải TCP:.................................................................10
.I.3. Điều khiển luồng dữ liệu:..........................................................................12
.I.4. Thiết lập và huỷ bỏ liên kết:......................................................................12
Thiết lập liên kết TCP:....................................................................................12
Huỷ bỏ một liên kết:........................................................................................12
.I.5. Truyền và nhận dữ liệu:.............................................................................13
.II Giao thức UDP:(User Datagram Protocol).........................................................13
.II.1. Định tuyến Multicast:..............................................................................14
Khái niệm nhóm Multicast:.............................................................................15
Địa chỉ Multicast:...........................................................................................15

TỔNG QUAN GIAO THỨC THỜI GIAN THỰC RTP(REAL TIME
PROTOCOL)....................................................................................................16
.I Những khái niệm ban đầu:...................................................................................16
.II Ứng dụng của RTP trong hội thảo đa phương tiện:............................................18
.II.1. Hội thảo thoại sử dụng multicast đơn giản (Simple Multicast Audio
Conference):.....................................................................................................18
.II.2. Hội thảo sử dụng thoại và video (Audio and Video Conference):............19

GIAO THỨC TRUYỀN TẢI THỜI GIAN THỰC(RTP:REAL TIME
TRANSPORT PROTOCOL)...........................................................................21
.I Một số khái niệm liên quan đến RTP:..................................................................21

.II Cấu trúc phần tiêu đề gói RTP:...........................................................................25
.III Ghép các phiên truyền RTP:.............................................................................28
.IV Sự thay đổi tiêu đề trong một số trường hợp:....................................................28

GIAO THỨC ĐIỀU KHIỂN RTP (RTCP:REAL TIME CONTROL
PROTOCOL)....................................................................................................30
.I Chức năng và hoạt động của giao thức RTCP:....................................................30
.II Các loại gói tin RTCP:.......................................................................................32
.III Khoảng thời gian truyền các gói RTCP: (RTCP Transmision Interval).............34
.IV Cập nhật số thành viên tham gia phiên truyền:.................................................37
.V Quy định đối với việc gửi và nhận gói tin RTCP:..............................................37
.VI Các bản tin thông báo của người gửi và người nhận:........................................43
.VI.1. Phần đầu:................................................................................................44
i


.VI.2. Phần thứ 2:.............................................................................................45
.VI.3. Phần thứ 3:.............................................................................................46

CÁC BỘ RTP TRANSLATORS VÀ RTP MIXERS.....................................58
.I Khái niệm chung:................................................................................................58
.II Hoạt động của Translators:.................................................................................60
.III Hoạt động của Mixers:......................................................................................62
.IV Các Mixer mắc phân tầng:................................................................................64

MỘT SỐ THUẬT TOÁN CƠ BẢN.................................................................66
.I Phân phối định danh SSRC:................................................................................66
.I.1. Xác suất xung đột:.....................................................................................66
.II Vấn đề bảo mật trong RTP:................................................................................69
.II.1. Khả năng che dấu dữ liệu:........................................................................70

.III Điều khiển tắt nghẽn:........................................................................................70
.IV RTP với các giao thức lớp Network và lớp Transport:......................................71

XÂY DỰNG ỨNG DỤNG VIDEO STREAMING........................................73
.I Phân tích yêu cầu đặt ra:......................................................................................73
.I.1. Thông lượng đường truyền:.......................................................................73
.I.2. Độ trễ:.......................................................................................................73
.I.3. Jitter:.........................................................................................................73
.I.4. Kiểm soát và cân bằng lưu lượng:.............................................................73
Kiểm soát lưu lượng:......................................................................................73
Cân bằng lưu lượng:.......................................................................................74
Các phương pháp điều khiển lưu lượng dòng video:......................................74
Thực hiện:.......................................................................................................74
.II Kết quả:..............................................................................................................75
[1] Thinh PQ Nguyen and Avideh Zakhor..............................................................82
Berkeley, CA, USA. DISTRIBUTED VIDEO STREAMING OVER INTERNET,
10 tr......................................................................................................................... 82
[2] Eric Setton, Bernd Girod. Peer-to-Peer Video Streaming. 2007 Springer
Science+Business Media, LLC, trang 5-18,trang 87-93..........................................82
[3] Công nghệ ANT................................................................................................82
[4] website : /> />s=3344d0f88a5a349f91b7e448b0b14a16&............................................................82
ross.html. 82

ii


CHƯƠNG 1

CƠ SỞ LÝ THUYẾT
Có rất nhiều ứng dụng hiện nay đòi hỏi tính thời gian thực (real time). Trong các dịch vụ

truyền hình qua mạng, hội thảo trực tuyến, chat hình, chat tiếng…mỗi ứng dụng có những
đặc điểm riêng của nó, tuy nhiên có một số điều chung nhất mà các dịch vụ này đều yêu cầu
đó là việc truyền dữ liệu theo dòng (streaming). Do vậy chúng ta sẽ bắt đầu với việc tìm hiểu
về khái niệm truyền dòng.

.I

Khái niệm truyền dòng:

Khái niệm truyền dòng có thể hiểu là khi nội dung của audio hay video được
truyền tới nơi nhận, nơi nhận có thể thể hiện được ngay trong quá trình truyền mà
không cần phải đợi đến khi toàn bộ nội dung video được truyền xong. Cơ chế này
hoàn toàn khác với cơ chế download file của các giao thức HTTP hay FTP.
Truyền dòng cho phép chúng ta thể hiện các dòng video thời gian thực mà không
phụ thuộc vào độ dài của video. Điều này rất có ý nghĩa khi truyền các file video có
kích thước lớn hay các dòng video có độ dài không xác định. Khi đó, các giao thức
khác như FTP hay HTTP sẽ không thể sử dụng được.
Chúng ta có thể bắt gặp rất nhiều trường hợp sử dụng cơ chế truyền dòng như các
chương trình truyền hình trực tiếp, hội thảo qua mạng. Với khả năng truyền tải nội
dung video, audio thông qua mạng, chúng ta có một phương pháp giao tiếp và truy
nhập thông tin mới.
Với góc nhìn bao quát, truyền dòng là một phương pháp truyền thông tin liên tục,
trong đó nội dung video được truyền đi theo thời gian thể hiện của nội dung video đó.
Bên nhận khi nhận dòng thông tin nội dung video sẽ có thể thể hiện ngay nội dung của
video theo thời gian. Khả năng này rất có ý nghĩa đối với các loại dữ liệu phụ thuộc
thời gian như video, audio, bởi vì để đảm bảo chất lượng cảm thụ video thì phải đảm
bảo được mối quan hệ về mặt thời gian giữa các khung hình.
Để có thể hình dung một cách đơn giản về cơ chế truyền dòng thời gian thực,
chúng ta lấy một ví dụ như sau. Giả thiết có hai máy được kết nối với nhau, trong đó
một máy đóng vai trò là máy truyền và một máy đóng vai trò là máy nhận. Bên truyền

được trang bị camera để thu hình giảng viên giảng bài và dữ liệu video thu được được
truyền tới máy nhận. Bên nhận có nhiệm vụ nhận dòng dữ liệu từ bên truyền gửi tới và
thể hiện lên thiết bị ra như TV hay màn hình máy tính. Khi đó với việc sử dụng cơ chế
truyền dòng thời gian thực, các hình ảnh của giảng viên mà bên nhận thể hiện sẽ phản
ánh một cách tức thời (về mặt lí thuyết) những gì đang xảy ra đối với giảng viên ở bên
truyền. Còn với các bài giảng được lưu trữ trước, truyền dòng thời gian thực sẽ đảm

Huỳnh Phương Đức-Nguyễn Văn Hưng, LỚP 06T1

3


bảo việc thể hiện của video tương đương như khi nó được thể hiện trên máy truyền.
Khi đó, môi trường mạng là trong suốt đối với người sử dụng, người sử dụng có cảm
giác việc thể hiện đoạn video như là được thực hiện ngay trên máy cục bộ.

.II Quá trình truyền dòng:
Truyền dòng đối với video hay audio phải trải qua nhiều công đoạn với từng nhiệm
vụ riêng để đi đến kết quả cuối cùng là đạt được khả năng thể hiện ngay ở bên nhận.

Giải
Giảinén
nénvideo/audio
video/audio
Dòng
video/audio
Lấy
Lấymẫu
mẫu

Khôi
Khôiphục
phụcdữ
dữliệu
liệuvàvà
đồng
bộ
đồng bộ
Network

RTP
Packets

Hình 1. Quá trình truyền dòng video/audio
Để có thể tìm hiểu sâu được cơ chế truyền dòng, chúng ta cần đi sâu vào quá trình
mà thông tin được truyền đi thông qua môi trường mạng. Bất cứ một nội dung video
hay audio nào được truyền đi dưới dạng truyền dòng đều phải trải qua các bước sau:
Bước 1 - Mã hoá:
Việc mã hoá video, mà cụ thể là nén video là một công đoạn không bắt buộc
nhưng rất cần thiết. Với các loại dữ liệu video thô như dữ liệu thu từ camera, thì việc
lưu trữ hay truyền video không nén sẽ phải trả giá cao, đôi khi là điều không thể. Ta
lấy ví dụ với một định dạng tiêu biểu thường được sử dụng trong các ứng dụng hội
nghị từ xa bằng video là định dạng CIF (Common Intermediate Format). CIF sử dụng
độ phân giải 352 pixel mỗi dòng và 288 dòng tất cả. Một ảnh không nén cho một
frame hình (chế độ 352x288x16bpp) chiếm 202752 byte. Việc ghi video không nén
với tốc độ 15 hình một giây sẽ cần xấp xỉ 3 MB một giây và nếu truyền qua mạng thì

Huỳnh Phương Đức-Nguyễn Văn Hưng, LỚP 06T1

4

Nghiên cứu giao thức RTP và xây dựng ứng dụng Video streaming

băng thông cần thiết cho một dòng video không nén là 24 Mbps. Từ ví dụ trên đây, ta
thấy việc nén video gần như là không thể thiếu được nếu các dòng video được truyền
trên môi trường mạng tốc độ thấp. Bảng sau cho biết độ nén cần thiết đối với từng môi
trường mạng khác nhau:
Dạng kết
nối

Bit Rate

Tỉ lệ
nén

OC3

155 Mbps

1:1

T3

42 Mbps

4:1

Ethernet

10 Mbps

17:1

T1

1.5 Mbps

110:1

ISDN

128 Kbps

1300:1

Modem

56 Kbps

3000:1

Bảng 1. Băng thông mạng và tỉ lệ nén yêu cầu
Có thể sử dụng nhiều chuẩn nén khác nhau cho việc nén video. Tuỳ theo yêu cầu
chất lượng và băng thông, mà ta có thể lựa chọn được phương pháp nén thích hợp.
Với việc áp dụng một chuẩn nén cho dữ liệu video, không gian lưu trữ cần thiết cũng
như băng thông mạng yêu cầu cho dòng video giảm đột ngột. Ví như đối với dòng
video ở trên, nếu sử dụng chuẩn nén H.263 thì băng thông yêu cầu cho việc truyền
dòng video này chỉ vào khoảng 140 Kbps và không gian lưu trữ cần thiết cho một
ngày với 24 giờ vào khoảng 1.4 MB. Hiện phổ biến hai họ chuẩn nén, là họ CCITT

với các chuẩn dạng H.26x, H.36x và họ ISO MPEG với các chuẩn MPEG-1, MPEG2, MPEG-4, MPEG-7. Sự phát triển của các chuẩn nén có thể tham khảo trong sơ đồ
dưới đây:

5


Nghiên cứu giao thức RTP và xây dựng ứng dụng Video streaming

H.261 - Một kĩ thuật với tốc độ dòng
bit nhỏ, được đưa ra vào năm 1984 bởi
ITU sử dụng cho các dịch vụ audiovisual.
MPEG-1 - Chuẩn ISO, ứng dụng
trong ngành công nghiệp quảng bá.
MPEG-1 được tạo ra như là một sự sửa
đổi của H.261 cho việc chuyển video vào
đĩa CD với tốc độ dòng bit thấp.
MPEG-2 - Được phát triển cho việc
quảng bá video chất lượng cao bằng cách
sử dụng tỉ lệ nén thấp.
H.263 - Một sửa đổi phỏng theo
MPEG-2 với mục đích thu được độ nén
cao trong khi vẫn đảm bảo chất lượng
hình ảnh cao. H.263+ và H.263++ là các
phiên bản mở rộng của H.263.
MPEG-4 - Được phát triến song song
với H.263 như là một phương pháp thay
thế cho MPEG-1 với tốc độ dòng bit thấp.
H.323 - Một hệ thống hoàn hảo cho
việc truyền thông multimedia, trong đó
Hình 2. Sự phát triển của

các phần
chuẩn
nén.được thực hiện trên cơ
thành
video
sở H.261/263.
JPEG-2000 - Chuẩn JPEG mới nhất,
dựa trên cơ sở DWT (Discrete Wavelet
Việc lấy mẫu thực chất là việc chia nhỏ nội dung của video hay audio ra thành các
Transform), ban đầu được phát triển cho
khối nhỏ thích hợp để có thể truyền đi trong môi trường mạng. Đối với các dữ liệu
việc nén ảnh tĩnh, hiện nay được áp dụng
audio, việc lấy mẫu được thực hiện theo thời gian. Tương ứng sau một khoảng thời
cho cả video.
gian bằng chu kì lấy mẫu phần dữ liệu audio tương ứng trong khoảng thời gian đó sẽ
H.263,
hiện
chưa
được sử dụng để truyền đi.Với các dữ liệu video,H.264
ngoài- Mở
việcrộng
lấy mẫu
theo
thời
gian
được
phát
triển
còn có việc lấy mẫu theo không gian. Việc lấy mẫu theo thời gian tương ứng với thời
gian thể hiện của các khung hình và việc lấy mẫu theo không gian sẽ được thực hiện

bằng cách chia nhỏ các khung hình thành các phần với kích thước thích hợp đối với
việc truyền đi.
Bước 2 - Lấy mẫu:

Khi lấy mẫu, các mẫu phải chứa đựng đầy đủ các thông tin dùng cho việc khôi
phục lại dữ liệu video hay audio về cả mặt không gian cũng như thời gian khi bên

6


Nghiên cứu giao thức RTP và xây dựng ứng dụng Video streaming

nhận nhận được các mẫu này. Với việc sử dụng một giao thức như giao thức truyền
thông thời gian thực như RTP, quá trình lấy mẫu sẽ được tiến hành tự động.
Bước 3 - Truyền các mẫu qua mạng:
Việc truyền các mẫu dữ liệu video có thể được thực hiện một cách trực tiếp thông
qua các giao diện của môi trường mạng như Socket hay được thực hiện thông qua một
giao thức cấp cao ở tầng ứng dụng như RTP. Thông thường người ta sẽ chọn giải pháp
thứ hai, tức là sử dụng một giao thức truyền dòng thời gian thực cho việc truyền các
mẫu nếu như giao thức đó được hỗ trợ trên nền phần cứng cũng như phần mềm.
Việc sử dụng một giao thức truyền dòng thời gian thực có nhiều ưu điểm. Ưu điểm
thứ nhất là tính hiệu quả, bởi vì các giao thức truyền thông thời gian thực được thiết
kế cho việc truyền các loại dữ liệu động, như dữ liệu video chẳng hạn, khi đó tính thời
gian thực sẽ được chú trọng hơn là tính chính xác về mặt dữ liệu. Ví dụ như đối với
giao thức RTP, giao thức truyền thông lớp dưới thường được sử dụng là UDP (User
Datagram Protocol) là giao thức với độ tin cậy thấp nhưng có tốc độ truyền dữ liệu
cao hơn các giao thức với độ tin cậy cao như TCP.
Ưu điểm thứ hai là các giao thức thời gian thực hỗ trợ mạnh việc đồng bộ các dòng
dữ liệu từ các nguồn khác nhau nhưng có quan hệ với nhau về mặt thời gian thực. Ví
dụ như đối với việc truyền âm thanh và hình ảnh của cùng một sự vật, khi đó bên nhận

khi thể hiện phải đảm bảo yêu cầu là âm thanh phải phù hợp với hình ảnh.
Ngoài ra, các giao thức điều khiển còn cung cấp các dịch vụ cho phép quản lí các
thành viên tham gia và điều khiển chất lượng của việc phân phối dữ liệu.
Với việc sử dụng một giao thức truyền thông thời gian thực cho việc truyền, khi đó
các mẫu sẽ được đóng gói thành các gói tin. Các gói tin sẽ mang đầy đủ các thông tin
như nhãn thời gian, số thứ tự của gói tin và các thông tin khác đủ dùng cho việc khôi
phục dữ liệu và đồng bộ các dòng khi bên nhận tiến hành nhận và thể hiện nội dung
của video hay audio. Thông qua các giao thức lớp dưới, các gói tin sẽ được truyền đi
trong môi trường mạng.
Bước 4 - Nhận và khôi phục dữ liệu và đồng bộ các dòng:
Đây là quá trình ngược với bước thứ ba, được thực hiện ở bên nhận khi dữ liệu
dưới dạng các gói tin được truyền đến. Các gói tin được truyền đến có thể là của nhiều
dòng tương ứng với nhiều nguồn dữ liệu khác nhau và cũng có thể thứ tự các gói tin
nhận được không giống như khi chúng được gửi đi. Khi đó bên nhận phải căn cứ vào
các thông tin được ghi trong từng gói tin để có thể xác định được vị trí về mặt không
gian và thời gian của các mẫu dữ liệu mà gói tin mang theo. Việc xác định được vị trí
của các mẫu dữ liệu trong gói tin giúp cho việc khôi phục lại nội dung của video hay
audio một cách chính xác nhất. Với việc truyền các dòng đơn lẻ không có quan hệ với
nhau về mặt thời gian, thì nội dung của audio hay video vừa được khôi phục có thể

7


Nghiên cứu giao thức RTP và xây dựng ứng dụng Video streaming

đuợc sử dụng để trình diễn. Còn trong trường hợp có nhiều dòng khác nhau có quan
hệ với nhau về mặt thời gian thực thì cần phải đồng bộ các dòng về mặt thời gian.
Việc đồng bộ các dòng chỉ cần thiết khi các dòng có quan hệ với nhau về mặt thời
gian, chẳng hạn như việc đồng bộ hình với tiếng khi truyền video, khi đó thời gian thể
hiện của các dòng phải được tính toán sao cho phù hợp với nhau. Việc đồng bộ là một

công việc phức tạp, thường được thực hiện tự động bởi các giao thức truyền thông
thời gian thực như RTP. Khi đó, mặc dù thứ tự các gói tin nhận được có thể không
giống như thứ tự khi được gửi, thậm chí có một số gói tin bị mất nhưng giao thức vẫn
phải đảm bảo tính đồng bộ cho các dòng khi được thể hiện ở nơi nhận
Bước 5 - Giải nén:
Bước này sẽ tiến hành giải nén dòng video/audio với chuẩn nén được sử dụng khi
nén. Dữ liệu sau khi giải nén có thể được thể hiện ra các thiết bị ra hay được ghi ra
file.

8


Nghiên cứu giao thức RTP và xây dựng ứng dụng Video streaming

CHƯƠNG 2

CÁC GIAO THỨC TRUYỀN TẢI CƠ BẢN
Trong chương trước chúng ta đã tìm hiểu qua khái niệm truyền dòng và phần nào đã hiểu một
số yêu cầu cơ bản của truyền dòng. Chúng ta cũng đã đề cập đến việc sử dụng giao thức RTP
cho việc truyền dòng dữ liệu thời gian thực. Vậy tại sao ta lại có sự lựa chọn đấy? Trong phần
này chúng ta sẽ đi lý giải sâu hơn việc chọn lựa này, thông qua việc tìm hiểu sơ bộ về các
giao thức lớp truyền tải: TCP, UDP cùng với khái niệm truyền đa điểm multicast.

.I

Giao thức TCP:(Transmision Control Protocol)

TCP là một giao thức kiểu có liên kết (Connection – Oriented), tức là phải có giai
đoạn thiết lập liên kết giữa một cặp thực thể TCP trước khi truyền dữ liệu.
Là một giao thức ở tầng giao vận TCP nhận thông tin từ các lớp trên chia nó thành

nhiều đoạn nếu cần thiết. Mỗi gói dữ liệu được chuyển tới giao thức lớp mạng (thường
là IP) để truyền và định tuyến. Bộ xử lý TCP của nó nhận thông báo đã nhận từng gói,
nếu nó nhận thành công, các gói dữ liệu không có thông báo sẽ được truyền lại. TCP
của nơi nhận lắp ráp lại thông tin và chuyển nó tới tầng cao hơn khi nó nhận được
toàn bộ.
Trước khi các gói dữ liệu được gửi tới máy đích nơi gửi và nơi nhận phải thương
lượng để thiết lập một kết nối logic tạm thời. Kết nối này về đặc trưng sẽ ở trạng thái
mở trong suốt phiên truyền.

.I.1.

Đặc điểm giao thức TCP:

Trong bộ giao thức TCP/IP TCP là giao thức được phát triển như là cách để kết nối
các mạng máy tính khác nhau về các phương pháp truyền dẫn và hệ điều hành. TCP
thiết lập kết nối hai đường giữa hai hệ thống cần trao đổi thông tin với nhau, thông tin
trao đổi giữa hai hệ thống được chia thành các gói. TCP có những đặc điểm sau:
Sự bắt tay: Hai hệ thống cần kết nối với nhau cần phải thực hiện một loạt các sự
bắt tay để trao đổi những thông tin về việc chúng muốn kết nối. Quá trình bắt tay đảm
bảo ngăn chặn sự tràn và mất mát dữ liệu khi truyền.
Xác nhận: Trong phiên truyền thông tin, hệ thống nhận dữ liệu cần phải gửi các
xác nhận cho hệ thống phát để xác nhận rằng nó đã nhận được dữ liệu.
Trật tự: Các gói tin có thể đến đích không theo thứ tự sắp xếp của dòng dữ liệu
liên tục bởi các gói tin đi từ cùng một nguồn tin theo những đường dẫn khác nhau để
đi tới cùng một đích. Vì vậy thứ tự đúng của các gói tin phải được đảm bảo sắp xếp lại
tại hệ thống nhận.
Phát lại: Khi phát hiện gói tin bị lỗi thì nơi gửi chỉ phát lại những gói tin bị lỗi
nhằm để tránh loại bỏ toàn bộ dòng dữ liệu.

9

Nghiên cứu giao thức RTP và xây dựng ứng dụng Video streaming

Sending

Receiving

Application

Application

Presentation

Presentation
TCP End to End Commmunication

Secssion

Secssion

TCP

Router

Router

TCP

IP

IP

IP

IP

Dadalink

Dadalink

Dadalink

Dadalink

Physical

Physical

Physical

Physical

Subnet

Subnet

Hình 3. Hoạt động của giao thức TCP trong việc cung cấp kết nối.

.I.2.

Cấu trúc đơn vị truyền tải TCP:

Đơn vị dữ liệu sử dụng trong giao thức TCP được gọi là Segment. Khuôn dạng của
Segment được mô tả như hình sau:
Bit 0

15 16

31

Sourse Port

Destination Port
Sequence Number
Acknowledgment Number
Data Reserved U A P R S F
Offset
(6 bits) R C S S Y I
Window (16 bits)
(4 bits)
G K H T N N
Checksum
Urgent pointer
Option
Padding
TCPdata

Hình 4.Khuôn dạng TCP Segment.
Các tham số của khuôn dạng trên có ý nghĩa như sau:

Source Port (16 bits): Số hiệu của cổng nguồn.

10


Nghiên cứu giao thức RTP và xây dựng ứng dụng Video streaming

Destination Port (16 bits): Số hiệu cổng của trạm đích. Số hiệu này là địa chỉ thâm
nhập dịch vụ lớp giao vận (CCISAP Addess) cho biết dịch vụ mà TCP cung cấp là
dịch vụ gì. TCP có số lượng cổng trong khoảng 0÷ 216-1 tuy nhiên các cổng nằm trong
khoảng từ 0÷ 1023 là được biết nhiều nhất vì nó được sử dụng cho việc truy cập các
dịch vụ tiêu chuẩn, ví dụ 23 là dịch vụ Telnet, 25 là dịch vụ mail . . . .
Sequence Number (32 bits): Số hiệu của byte đầu tiên của Segment trừ khi bit
SYN được thiết lập. Nếu bit SYN được thiết lập thì Sequence Number là số hiệu tuần
tự khởi đầu (ISN) và byte dữ liệu đầu tiên là ISN+1.
Acknowledgment Number (32 bits): Số hiệu của Segment tiếp theo mà trạm nguồn
đang chờ để nhận. Ngầm ý báo đã nhận tốt các Segment mà trạm đích đã gửi cho trạm
nguồn.
Data offset (4bits): Số lượng từ 32 bit trong TCP header (Tham số này chỉ ra vùng
bắt đầu của vùng dữ liệu).
Reserved (6 bits): Dành để dùng trong tương lai.
Control bits: Các bits điều khiển. Nếu tính từ trái sang phải:
URG: Vùng con trỏ khẩn có hiệu lực.
ACK: Vùng báo nhận (ACK number) có hiệu lực.
PSH: Chức năng PUSH.
RST: Khởi động lại (reset) liên kết.
SYN: Đồng bộ các số liệu tuần tự (sequence number).
FIN: Không còn dữ liệu từ trạm nguồn.
Window (16bits): Cấp phát credit để kiểm soát luồng dữ liệu (cơ chế cửa sổ). Đây
chính là số lượng các byte dữ liệu bắt đầu từ byte được chỉ ra trong vùng ACK

number, mà trạm nguồn đã sẵn sàng để nhận.
Checksum (16bits): Mã kiểm soát lỗi (theo phương pháp CRC) cho toàn bộ
Segment.
Urgent Pointer (16 bits): Con trỏ này trỏ tới số liệu tuần tự của byte đi theo sau dữ
liệu khẩn, cho phép bên nhận biết được độ dài của dữ liệu khẩn. Vùng này chỉ có hiệu
lực khi bit URG được thiết lập.
Option (độ dài thay đổi): Khai báo các option của TCP, trong đó có độ dài tối đa
của vùng TCP data trong một Segment.
Padding (độ dài thay đổi): Phần chèn thêm vào Header để bảo đảm phần Header
luôn kết thúc ở một mốc 32 bits. Phần thêm này gồm toàn số 0.
Việc kết hợp địa chỉ IP của một máy trạm và số cổng được sử dụng tạo thành một
Socket. Các máy gửi và nhận đều có Socket riêng. Số Socket là duy nhất trên mạng.
11


Nghiên cứu giao thức RTP và xây dựng ứng dụng Video streaming

.I.3.

Điều khiển luồng dữ liệu:

Trong việc điều khiển luồng dữ liệu phương pháp hay sử dụng là dùng phương
pháp cửa sổ trượt. Phương pháp này giúp cho việc nhận luồng dữ liệu hiệu quả hơn.
Phương pháp cửa sổ trượt cho phép nơi gửi (Sender) có thể gửi đi nhiều gói tin rồi
sau đó mới đợi tín hiệu báo nhận ACK (Acknowledgement) của nơi nhận(Receiver).
Với phương pháp cửa sổ trượt khi cần truyền các gói tin, giao thức sẽ đặt một cửa sổ
có kích cố định lên các gói tin. Những gói tin nào nằm trong vùng cửa sổ ở một thời
điểm nhất định sẽ được truyền đi.

.I.4.

Thiết lập và huỷ bỏ liên kết:

Như ta đã biết TCP là một giao thức kiểu có liên kết, tức là cần phải có giai đoạn
thiết lập một liên kết giữa một cặp thực thể TCP trước khi truyền dữ liệu và huỷ bỏ
liên kết khi không còn nhu cầu trao đổi dữ liệu nữa.

Thiết lập liên kết TCP:
Một liên kết có thể được thiết lập theo một trong hai cách chủ động (active) và bị
động (passive). Nếu liên kết được thiết lập theo cách bị động thì đầu tiên TCP tại trạm
muốn thiết lập liên kết sẽ nghe và chờ yêu cầu liên kết từ một trạm khác. Tuỳ trường
hợp của lời gọi hàm mà người sử dụng phải chỉ ra cổng yêu cầu kết nối hoặc có thể
kết nối với một cổng bất kỳ.
Với phương thức chủ động thì người sử dụng yêu cầu TCP thử thiết lập một liên
kết với một Socket nào đó với một mức ưu tiên và độ an toàn nhất định. Nếu trạm ở
xa kia đáp lại bằng một hàm Passive open tương hợp hoặc đã gửi một active open
tương hợp thì liên kết sẽ được thiết lập.Nếu liên kết được thiết lập thành công thì hàm
Open success primitive được dùng để thông báo cho người sử dụng biết (cũng được sử
dụng trong trường hợp Passive Open) còn nếu thất bại thì hàm Open failure primitive
được dùng để thông báo.

Huỷ bỏ một liên kết:
Khi không còn nhu cầu trao đổi dữ liệu nữa thì liên kết TCP có thể được huỷ bỏ.
Liên kết có thể được huỷ bỏ theo hai cách:
Huỷ bỏ một cách bất thường.
Huỷ bỏ một cách bình thường.
Liên kết được huỷ bỏ một cách bình thường khi toàn bộ dữ liệu đã được truyền
hết.Tức là hai bên không còn nhu cầu trao đổi dữ liệu nữa.
Liên kết có thể bị huỷ bỏ một cách bất thường vì một lý do nào đó (do người sử
dụng hoặc do TCP đóng liên kết do không thể duy trì được liên kết). Toàn bộ dữ liệu

đang truyền có thể bị mất.
12


Nghiên cứu giao thức RTP và xây dựng ứng dụng Video streaming

.I.5.

Truyền và nhận dữ liệu:

Sau khi liên kết được thiết lập giữa một cặp thực thể TCP thì có thể tiến hành việc
truyền dữ liệu. Với liên kết TCP dữ liệu có thể được truyền theo cả hai hướng.
Khi nhận được một khối dữ liệu cần chuyển đi từ người sử dụng, TCP sẽ lưu giữ
nó tại bộ đệm gửi. Nếu cờ PUSH được dựng thì toàn bộ dữ liệu trong bộ đệm sẽ được
gửi đi hết dưới dạng các TCP Sgment. Còn nếu cờ PUSH không được dựng thì toàn
bộ dữ liệu vẫn được lưu giữ trong bộ đệm để chờ gửi đi khi có cơ hội thích hợp.
Tại bên nhận, dữ liệu gửi đến sẽ được lưu giữ trong bộ đệm nhận. Nếu dữ liệu đệm
được đánh dấu bởi cờ PUSH thì toàn bộ dữ liệu trong bộ đệm nhận sẽ được gửi lên
cho người sử dụng. Còn nếu dữ liệu không được đánh dấu với cờ PUSH thì chúng vẫn
được lưu trong bộ đệm. Nếu dữ liệu khẩn cần phải chuyển gấp thì cờ URGENT được
dùng và đánh dấu dữ liệu bằng bit URG để báo rằng dữ liệu khẩn cần được chuyển
gấp.

.II Giao thức UDP:(User Datagram Protocol)
UDP (User Datagram Protocol) là một giao thức kiểu không kết nối, được sử dụng
trong một số yêu cầu ứng dụng thay thế cho TCP. Tương tự như giao thức IP, UDP
không thực hiện các giai đoạn thiết lập và huỷ bỏ liên kết, không có các cơ chế báo
nhận (Acknowledgement) như trong TCP. UDP cung cấp các dịch vụ giao vận không
đáng tin cậy. Dữ liệu có thể bị mất, bị lỗi hay bị truyền luẩn quẩn trên mạng mà không
hề có thông báo lỗi đến nơi gửi hoặc nơi nhận. Do thực hiện ít chức năng hơn TCP

nên UDP chạy nhanh hơn, nó thường được sử dụng trong các dịch vụ không đòi hỏi
độ tin cậy cao. Đơn vị dữ liệu dùng trong giao thúc UDP là UDP Datagram. Khuôn
dạng của một UDP Datagram gồm hai phần: Phần tiêu đề (Header) chứa các thông tin
điều khiển và phần Data chứa dữ liệu.
Khuôn dạng của UDP Datagram cụ thể như hình 2.5.

UDP Source Port

UDP Destination Port

UDP Message Length

UDP Checksum
Data

... ...
Hình 5.Khuôn dạng UDP Datagram
Trong đó ý nghĩa của các trường là:
UDP Source Port (16 bits): Cho biết địa chỉ cổng của trạm nguồn. Nếu nó không
được chỉ ra thì trường này được thiết lập là 0.
13


Nghiên cứu giao thức RTP và xây dựng ứng dụng Video streaming

UDP Destination Port (16 bits): Cho biết địa chỉ cổng của trạm đích.
UDP Message Length (16 bits): Cho biết kích thước của một UDP Datagram (kể
cả phần Header). Kích thước tối thiểu của một UDP Datagram là 8 bytes (chỉ có phần
Header, không có phần dữ liệu).
UDP Checksum (16 bits): Là mã kiểm soát lỗi theo phương pháp CRC.

Lớp UDP được đặt trên lớp IP, tức là UDP Datagram khi chuyển xuống tầng dưới
sẽ được đặt vào IP Datagram để truyền trên liên mạng. IP Datagram này được ghép
vào một khung tin rồi được gửi tới liên mạng đến trạm đích. Tại trạm đích các PDU
được gửi từ dưới lên trên, qua mỗi tầng phần Header của PDU được gỡ bỏ và cuối
cùng chỉ còn lại phần dữ liệu như ban đầu được chuyển cho người sử dụng.

.II.1. Định tuyến Multicast:
IP Multicast là một kỹ thuật duy trì dải thông bằng cách làm giảm lưu lượng thông
qua việc phân phát đồng thời một luồng dữ liệu tới hang ngàn người bên nhận. Các
ứng dụng sử dụng ưu điểm của Multicast như là hội nghị video, truyền thông theo
nhóm, lớp học từ xa, hoặc là để phân phối các phần mềm, các chỉ số chứng khoán và
tin tức.

Hình 6 Truyền Multicast

14


Nghiên cứu giao thức RTP và xây dựng ứng dụng Video streaming

IP Multicast thực hiện phân phối nguồn thông tin tới rất nhiều các bên nhận mà
không cần thêm bất kỳ thông tin gì vào trong nguồn hay các bên nhận trong khi chỉ sử
dụng một mức dải thông tối thiểu. Các gói multicast được tái tạo lại bên trong các
Router mà đã kích hoạt khả năng PIM (Protocol Independent Multicast) và các giao
thức hỗ trợ multicast khác đưa đến kết quả là nó tạo ra khả năng phát chuyển dữ liệu
tới nhiều thành viên một cách hiệu quả nhất. Tất cả mọi con đường đều yêu cầu nguồn
phải gửi nhiều hơn một bản copy của dữ liệu. Một vài cách thì yêu cầu nguồn gửi cho
mỗi một bên nhận một bản copy độc lập. Nếu như có hàng ngàn bên nhận, việc sử
dụng IP Multicast là rất có lợi. Với các ứng dụng yêu cầu băng thông cao như là
MPEG video, thì nó có thể yêu cầu một phần lớn dải thông đường truyền cho một

luồng đơn. Trong những ứng dụng này, cách duy nhất để gửi dữ liệu tới hang ngàn
đích một cách đồng thời là sử dụng IP Multicast. Hình dưới đây sẽ cho chúng ta biết
làm thế nào mà một nguồn gửi dữ liệu tới nhiều đích sử dụng IP Multicast.

Khái niệm nhóm Multicast:
Multicast dựa trên khái niệm của nhóm. Một nhóm tuỳ ý của các bên nhận biểu
diễn một sự quan tâm đến việc nhận một luồng dữ liệu. Nhóm này không có bất cứ
một ranh giới rõ ràng về mặt vật lý hay địa lý. Các thành viên (hosts) của nhóm này có
thể nằm ở bất cứ nơi nào trên Internet. Các thành viên này có cùng sở thích là nhận
một luồng dữ liệu phát tới một nhóm đơn mà để nhận được luồng thông tin này thì
buộc phải tham gia vào nhóm sử dụng giao thức IGMP. Các máy này phải là thành
viên của nhóm thì mới nhận được luồng dữ liệu mà họ quan tâm.

Địa chỉ Multicast:
Địa chỉ Multicast chỉ rõ một nhóm tuỳ ý các máy trạm theo IP mà các máy đó
tham gia vào nhóm này để nhận dữ liệu gửi tới nhóm.
Trong IP multicast thì địa chỉ multicast là địa chỉ nhóm D, có cấu trúc:

Hình 7.Địa chỉ multicast.
Bốn bít đầu tiên chứa 1110 và xác định đây là địa chỉ multicast. Phần còn lại, 28
bit, xác định nhóm multicast cụ thể. Không còn cấu trúc nào nữa trong nhóm các bit.
Cụ thể, vùng group không được phân chia thành các bit để xác định nguồn gốc hay
đơn vị sở hữu của nhóm, nó cũng không chứa thông tin quản trị như là các thành viên
của nhóm có ở trên một mạng vật lý không.

15


Nghiên cứu giao thức RTP và xây dựng ứng dụng Video streaming

CHƯƠNG 3

TỔNG QUAN GIAO THỨC THỜI GIAN
THỰC RTP(REAL TIME PROTOCOL)
Qua những nhận xét ở chương 2, chúng ta đã thấy được, việc truyền thông đa phương tiện,
thời gian thực đòi hỏi sự có mặt của một giao thức mới, dựa trên cơ sở giao thức UDP. Đó
chính là giao thức RTP. Trong phần này ta sẽ tìm hiểu những điều tổng quan nhất về giao
thức này.

.I

Những khái niệm ban đầu:

RTP là một giao thức chuẩn dùng cho việc truyền các dữ liệu thời gian thực như
video, audio. Nó có thể được sử dụng trong media-on-demand cũng như trong các
dịch vụ tương tác khác như điện thoại internet…giao thức RTP bao gồm hai phần, dữ
liệu và điều khiển(RTCP).

Hình 8. Mô hình tổng quát về giao thức RTP.
Giao thức RTP (Real-time transport protocol), cung cấp các hàm phục vụ việc
truyền tải dữ liệu “end to end” cho các ứng dụng thời gian thực, qua các mạng
multicast hay qua mạng unicast. Các dịch vụ này bao gồm:
Sự phân loại tải: payload type identification.
Đánh số thứ tự: sequence numbering.
Đánh dấu thời gian phát, đồng bộ hoá:

16


Nghiên cứu giao thức RTP và xây dựng ứng dụng Video streaming

Hình 9. Nhãn thời gian và sự đồng bộ.
Theo dõi quá trình truyền tải: delivery monitoring.

Hình 10. Kiểm soát quá trình phân phối dữ liệu.
Để hỗ trợ cho RTP là giao thức điều khiển RTCP. Giao thức này nhằm đảm bảo
cho việc truyền dữ liệu, cho phép theo dõi được quá trình truyền tải trên một mạng
multicast. Ngoài ra nó còn cung cấp các dịch vụ, chức năng điều khiển và nhận dạng.
Cả RTP và RTCP đều được thiết kế để có thể cài đặt một cách độc lập với các giao
thức lớp Network và lớp Transport.
Các ứng dụng RTP hoạt động phía trên của chồng giao thức UDP, với vai trò điều
chế và cung cấp các dịch vụ kiểm soát lỗi. Tuy nhiên RTP cũng có thể sử dụng kết hợp
với các chồng giao thức dưới lớp mạng hay dưới lớp giao vận. RTP hỗ trợ truyền tải
dữ liệu tới đa điểm theo cơ chế Mutilcast.
RTP bản thân nó không hề cung cấp một cơ chế nào nhằm đảm bảo về mặt thời
gian, cũng như sự đảm bảo về chất lượng dịch vụ(QoS) của các ứng dụng thời gian
thực. Nhưng điều này vẫn được đảm bảo dựa trên các dịch vụ lớp dưới.
Cũng như vậy RTP không đảm bảo độ tin cậy hay thứ tự của các gói tin. Nhưng
các cơ chế đảm bảo độ tin cậy và việc đảm bảo thứ tự các gói tin nhận được sẽ được
đảm bảo dưới các cơ chế của lớp mạng. Số thứ tự được đánh trong khung RTP cho
phép bên nhận có thể khôi phục lại thứ tự gói phía gởi, nhưng có thể nó cũng được
dùng để định vị gói tin như trong quá trình giải mã tín hiệu Video. Khi đó thì việc giải
mã tín hiệu Video theo thứ tự là không nhất thiết.
Tuy mục đích đầu tiên của giao thức RTP là nhằm đảm bảo cho các ứng dụng
multimedia conference. Tuy nhiên các ứng dụng truyền dòng, các chương trình mô
17


Nghiên cứu giao thức RTP và xây dựng ứng dụng Video streaming

phỏng phân tán, các ứng dụng trong điều khiển, đo lường cũng nhanh chóng tìm thấy
sự thích ứng của RTP.
Khi đề cập đến giao thức RTP là chúng ta đề cập đến hai vấn đề:
Giao thức truyền tải thời gian thực (real-time transport protocol): Với chức năng
truyền tải các dữ liệu có thuộc tính thời gian thực.
Giao thức điều khiển RTCP: Với chức năng giám sát chất lượng dịch vụ và truyền
các thông tin về những phiên truyền. RTCP giúp cho việc điều khiển các phiên.

.II Ứng dụng của RTP trong hội thảo đa phương tiện:
Để tìm hiểu các ứng dụng của RTP ta xét trong trường hợp cụ thể, hội thảo đa
phương tiện. Đây là trường hợp rất điển hình, có thể đại diện cho các ứng dụng truyền
dòng thời gian thực.

Hình 11 .Vị trí RTP trong các ứng dụng multimedia

.II.1.

Hội thảo thoại sử dụng multicast đơn giản (Simple
Multicast Audio Conference):

Nhóm làm việc của IETF đưa ra ý kiến việc sử dụng dịch vụ IP multicast cho việc
truyền tín hiệu thoại trên mạng Internet. Quan điểm chính là kết hợp việc truyền
Mutilcast và sử dụng đồng thời hai cổng truyền dữ liệu. Trong đó một cổng sẽ dùng để
truyền các dữ liệu thoại cụ thể, cổng còn lại sẽ sử dụng để truyền tín hiệu điều khiển
RTCP. Trong trường hợp cần yêu cầu bảo mật thì dữ liệu trước khi truyền qua hai
cổng này sẽ được mã hoá theo chuẩn, các khoá mã cũng sẽ được sinh ra và truyền kèm
theo.
Mỗi thành viên tham gia hội thoại sẽ gởi dữ liệu thoại theo từng đoạn. Những đoạn
dữ liệu sẽ được gắn thêm phần RTP header. Sau đó cả phần RTP header và phần dữ
liệu sẽ được đóng vào gói UDP. Phần RTP header sẽ xác định loại mã hoá tín hiệu

thoại (PCM, ADPCM…..) được mang trong phần dữ liệu, vì vậy kiểu mã hoá tín hiệu

18


Nghiên cứu giao thức RTP và xây dựng ứng dụng Video streaming

thoại của những thành viên tham gia có thể thay đổi trong quá trình hội đàm. Điều này
rất có ý nghĩa, đặc biệt với những thành viên sử dụng đường truyền tốc độ thấp hay
trong trường hợp mạng bị nghẽn.
Việc truyền các gói tin trên mạng rất có thể bị thất lạc, mất thứ tự các gói tin hay
xảy ra Jitter. Để giải quyết vấn đề này, phần RTP header có chứa thông tin về thời gian
và số thứ tự của các gói tin. Do đó phía nhận có thể dựa vào đó để khôi phục lại về
mặt thời gian. Trong trường hợp này, mỗi thành viên sẽ liên tục truyền đi các gói tin
với chu kỳ 20ms. Việc khôi phục thời gian sẽ giúp cho bên nhận có thể phân biệt được
các nguồn tin khác nhau trong quá trình hội thoại.
Số thứ tự của các gói tin có thể dùng để nhận biết số lượng các gói tin bị thất lạc
của mỗi nguồn, kể từ khi họ tham gia hội thoại. Việc này giúp chúng ta có thể đánh
giá chất lượng mạng của từng thành viện. Trong quá trình hội thoại, những bản tin
thông báo có kèm theo định danh của từng thành viên sẽ được chuyển qua cổng điều
sử dụng RTCP. Những thông báo này sẽ xác định các gói tin do mỗi thành viên gởi đi
được nhận có tốt không. Dựa vào đó ta có thể điều chỉnh bộ mã hoá động.
Ngoài ra việc định danh thành viên cũng như các thông tin xác định khác có thể
được sử dụng để điều khiển giới hạn băng thông của từng thành viên.
Khi một thành viên rời khỏi hội thoại, họ sẽ gởi một gói tin RTCP Bye để thông
báo.

.II.2.

Hội thảo sử dụng thoại và video (Audio and Video

Conference):

Hình 12.RTP trong hội thảo sử dụng cả video/audio.
Trong trường hợp ta sử dụng đồng thời cả âm thanh và hình ảnh trong hội thảo, ta
sẽ sử dụng đồng thời hai cặp RTP/RTCP. Việc truyền tín hiệu tiếng và tín hiệu hình là
19


Nghiên cứu giao thức RTP và xây dựng ứng dụng Video streaming

hoàn toàn độc lập. Không hề có sự kết nối trực tiếp nào giữa hai quá trình này. Tuy
nhiên nếu mỗi thành viên tham gia, sử dụng 1 định danh cho cả hai tiến trình này thì
phía nhận vẫn hoàn toàn có thể ghép lại được từng cặp audio/video.
Với việc truyền tách biệt này, cho phép một thành viên tham gia hội thảo thiết lập
cơ chế chỉ nhận một luồng Audio hoặc Video. Việc mất đồng bộ của tín hiệu hình và
tiếng sẽ được giải quyết dựa vào thông tin định thời trong các gói tin RTCP của hai
luồng.
Trên đây chúng ta đã giả định tất cả các thành viên đều cùng nhận 1 dạng format
cho các dữ liệu Media. Điều này không thể được trong trường hợp có thành viên sử
dụng đường truyền tốc độ thấp, các thành viên khác lại sử dụng đường truyền có tốc
độ cao. Khi đó ta không thể bắt tất cả các thành viên cùng sử dụng truyền ở tốc độ
thấp, chất lượng tín hiệu thấp.
Khi đó ta có thể sử dụng bộ trộn RTP-level mixer, đặt gần nơi có băng thông hẹp.
Bộ này sẽ tái đồng bộ các gói tin thoại, khôi phục lại chu kỳ 20ms của phía gởi. Sau
đó truyền lại dòng audio với tốc độ bit phù hợp với đường truyền. Việc truyền lại này
có thể sử dụng truyền Unicast cho một người nhận đơn, hoặc Multicast cho một nhóm
người nhận. Phần RTP header sẽ đảm nhiệm việc định danh lại người gởi phía nhận.
RTP-level còn có thể sử dụng để thay đổi độ phân giải của tín hiệu Video cho phù hợp
với từng thành viên tham gia.
Ngoài ra chúng ta còn kể đến trường hợp, một thành viên sử dụng đường truyền

tốc độ cao, nhưng họ lại không thể nhận trực tiếp các gói IP multicast. Khi đó ta sẽ
phải cài đặt 2 bộ RTP-level mixer. Một được đặt phía trước firewall, một phía sau
firewall.

20


Nghiên cứu giao thức RTP và xây dựng ứng dụng Video streaming

CHƯƠNG 4

GIAO THỨC TRUYỀN TẢI THỜI GIAN
THỰC(RTP:REAL TIME TRANSPORT
PROTOCOL)
Qua các chương trước chúng ta đã nắm được khái niệm cơ bản thế nào là giao thức RTP, sự
cần thiết của nó trong những ứng dụng thời gian thực. Chúng ta đã biết nói về giao thức RTP
là đề cập đến 2 khái niệm giao thức truyền tải thời gian thực RTP và giao thức điều khiển
RTCP. Trong phần này chúng ta sẽ đi vào tìm hiểu cụ thể giao thức truyền tải thời gian thực.

.I

Một số khái niệm liên quan đến RTP:

Trước khi đi vào tìm hiểu cụ thể về giao thức RTP, chúng ta cần phải nắm được
một số khái niệm cơ bản sau đây:
RTP payload: Đây là phần dữ liệu được truyền trong các gói RTP. Đây có thể là
các mẫu tín hiệu thoại hoặc dữ liệu Video đã được nén. Việc phân định dạng dữ liệu
(được chỉ định bởi phần payload type) sẽ được để cập đến ở phần sau.
RTP packet: Là gói dữ liệu RTP, bao gồm phần cố định RTP header, phần danh
sách các nguồn phân tán (có thể rỗng), phần RTP payload. Một số giao thức tầng dưới

có thể yêu cầu phải đóng gói lại các gói RTP. Thông thường 1 gói lớp dưới chứa 1 gói
RTP. Tuy nhiên cũng có trường hợp nhiều gói RTP được đóng vào một gói, điều này
hoàn toàn phụ thuộc cách đóng gói của lớp dưới.
RTCP packet: Đây là gói tin điều khiển RTCP, có phần tiêu đề cố định gần giống
gói RTP. Tiếp theo đến phần có cấu trúc, dạng của cấu trúc sẽ tuỳ thuộc vào loại gói
RTCP. Thông thường một số gói RTCP sẽ được ghép chung trong một gói của lớp
dưới. Điều này có thể thực hiện được do các gói RTCP có phần tiêu đề cố định.
Port: Cổng địa chỉ UDP được sử dụng. Đây là khái niệm trừu tượng mà các giao
thức truyền tải sử dụng để phân biệt các phiên truyền. Với giao thức TCP/IP nó là số
nguyên dương 16Bit. RTP dựa trên các cơ chế tương tự sự phân cổng được cung cấp
bởi giao thức lớp dưới để gởi đồng thời các gói dữ liệu RTP và gói tin điều khiển
RTCP trong mỗi phiên truyền.
Transport address: Địa chỉ này phục vụ cho việc vận chuyển dữ liệu. Nó là sự kết
hợp giữa địa chỉ mạng và các cổng được định nghĩa ở tầng giao vận. Ví dụ như sự kết
hợp giữa địa chỉ IP với một cổng UDP nhất định. Các gói tin sẽ được truyền từ địa chỉ
Transport address nguồn tới địa chỉ Transport address đích.
RTP media type: Đây là một tập các loại tải có cùng một số tính chất được mang
trong phiên truyền RTP. Trong hội thảo đa phương tiện ta có thể có hai loại RTP
media type là video-MPEG2 và audio-PCMA.
21


Nghiên cứu giao thức RTP và xây dựng ứng dụng Video streaming

RTP session: Một phiên RTP có thể có sự tham gia của một tập các thành viên
cùng trao đổi thông tin. Mỗi thành viên được xác định dựa trên cặp địa chỉ nguồn (một
dùng truyền gói RTP, một dùng truyền gói RTCP). Cặp địa chỉ đích có thể là chung
cho tất cả các thành viên còn lại (trong trường hợp truyền đa điểm multicast) hoặc
riêng biệt cho từng thành viên (trong trường hợp truyền điểm điểm unicast). Trong
một phiên truyền Multimedia, các tín hiệu thành phần (video/audio) được truyền theo

một cặp cổng riêng.

Hình 13. Mô hình phiên RTP.
Synchronization source (SSRC): nguồn phát dòng các gói RTP, được định danh
bởi 32-bit SSRC trong phần header của gói RTP. Nó có giá trị hoàn toàn độc lập với
địa chỉ mạng. Các gói dữ liệu được phát từ một nguồn được gắn thời gian và số thứ tự
một cách thống nhất. Do đó phía nhận sẽ dựa trên SSRC để khôi phục lại tín hiệu. Giá
trị của định danh SSRC của mỗi nguồn RTP là đơn trị trên toàn mạng, nó được khởi
tạo một cách ngẫu nhiên.

22