Truyen dong du lieu thoi gian thuc real time streaming - Tại 123doc

Nghiên cứu và ứng dụng giao thức RTP.

Mục Tran

gMục lục. 1Lời nói đầu. 3

CHƯƠNG 0:TRUYỀN DÒNG DỮ LIỆU THỜI GIAN THỰC.

0.1. Khái niệm truyền dòng. 40.2. Quá trình truyền dòng. 5

CHƯƠNG I: LỰA CHỌN CÁC GIAO THỨC PHÙ HỢP VỚI CÁC ỨNG DỤNG THỜI GIAN THỰC.

1.1. Giao thức TCP: ( Transmision Control

Protocol).

11

1.2. Giao thức UDP: (User Datagram

Protocol).

16

1.3. Định tuyến multicast. 171.4. Giao thức nào có thể đáp ứng được yêu

cầu thời gian thực?

19

CHƯƠNG II: TỔNG QUAN GIAO THỨC THỜI GIAN THỰC RTP(REAL TIME PROTOCOL).

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

3.2 ứng dụng của RTP trong hội thảo đa

phương tiện.

24

CHƯƠNG III: GIAO THỨC TRUYỀN TẢI THỜI GIAN THỰC(REAL TIME TRANSPORT PROTOCOL).

3.1. Một số khái niệm liên quan đến RTP. 283.2. Cấu trúc phần tiêu đề gói RTP. 323.3 Ghép các phiên truyền RTP. 36

1


3.4. Sự thay đổi phần tiêu đề trong một số

trường hợp.

37

CHƯƠNG IV: GIAO THỨC ĐIỀU KHIỂN RTP(RTCP: RTP CONTROL PROTOCOL).

4.1 Chức năng và hoạt động của RTCP. 394.2. Các loại gói tin RTCP. 414.3 Khoảng thời gian truyền các gói RTCP. 444.4 Cập nhật số thành viên tham gia phiên

truyền.

47

4.5 Qui định đối với việc gởi và nhận các

gói RTCP.

48

4.6. Các bản tin thông báo của người gởi và

người nhận.

54

4.7 Gói tin mô tả các thông tin của nguồn. 644.8. Gói BYE. 704.9. Gói APP. 71

CHƯƠNG V: CÁC BỘ RTP TRANSLATORS VÀ RTP MIXERS .

5.1. Khái niệm chung. 735.2. Hoạt động của bộ Translators. 765.3. Hoạt động của Mixers. 785.4. Các “mixer” mắc phân tầng. 80

PHẦN VI: MỘT SỐ THUẬT TOÁN CẦN CHÚ Ý.

6.1. Phân phối các định danh SSRC. 826.2 Vấn đề bảo mật trong RTP. 86

2


6.3. Điều khiển tắc nghẽn. 876.4. RTP với các giao thức lớp mạng và lớp

giao vận.

88

CHƯƠNG VII: ỨNG DỤNG LÝ THUYẾT VÀO THỰC TẾ.

7.1 Phân tích yêu cầu đặt ra. 907.2. thực hiện. 927.3. Kết quả. 93

Phụ lục. 96Kết luận. 99Tài liệu tham khảo. 100

LỜI NÓI ĐẦU

Hiện nay, mạng máy tính không còn là khái niệm

xa lạ gì. sau hơn 40 năm phát triển, mạng máy

tính, giờ đây mạng máy tính đã trải rộng trên toàn

cầu, với chất lượng đường truyền có chất lượng

cao. Ngoài ra tính bảo mật, độ tin cậy trên mạng

cũng ngày càng được củng cố. Những ứng dụng trên

mạng đang ngày càng phong phú. Chính những sự phát

triển này làm nảy sinh một vấn đề, đó là truyền

3


thông đa phương tiện trên mạng. Yếu tố rất quan

trọng, có mặt trong rất nhiều lĩnh vực. Trong các

buổi hội thảo trực tuyến, trong đào tạo từ xa trên

mạng, trong dịch vụ video/audio theo yêu cầu….Tuy

nhiên sự phát triển của truyền thông đa phương

tiện đòi hỏi tính thời gian thực rất cao, chùm

giao thức TCP/IP hiện đang được sử dụng rất phổ

biến không thể đáp ứng được yêu cầu này. Do vậy,

đòi hỏi các chuyên gia mạng phải tìm ra một giải

pháp mới, một giao thức mới có thể đáp ứng được

việc truyền tải dữ liệu thời gian thực trên mạng.

Hiện nay, giao thức RTP đã và đang chứng tỏ những

ưu điểm của mình trong việc đáp ứng các ứng dụng

thời gian thực.

Tại Việt Nam, các ứng dụng thời gian thực còn

chưa phát triển, nhưng với như cầu cấp thiết của

thực tế, trong thời gian tới chắc chắn các ứng

dụng thời gian thực sẽ phát triển mạnh mẽ.

Đây cũng là một trong những lý do chính để em

chọn lựa đề tài này.

4


CHƯƠNG 0: TRUYỀN DÒNG DỮ LIỆU THỜI GIAN THỰC

(REAL TIME STREAMING)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.

0.1. 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ó

5


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

6


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 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ộ.

0.2. 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.

7


Hình 0.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

Giải nén video/audio

RTP Packets

Lấy mẫu Khôi phục dữ liệu và đồng

bộNetwork

Dòng video/aud

io

8


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ì 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énOC3 155 Mbps 1:1T3 42 Mbps 4:1Ethernet 10 Mbps 17:1T1 1.5 Mbps 110:1ISDN 128 Kbps 1300:1Modem 56 Kbps 3000:1

B¶ng 0-2: B¨ng th«ng m¹ng vµ tØ lÖ nÐn yªu cÇu

9


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 lu

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 lu 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 chuÈn d¹ng H.26x, H.36x vµ hä ISO MPEG

víi çc chuÈn MPEG-1, MPEG-2, MPEG-4, MPEG-7. Sù ph¸t

triÓn cña çc chuÈn nÐn cã thÓ tham kh¶o trong s¬ ®å d-

íi ®©y:

10

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ụ audio-visual.

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 đó thành phần video được thực hiện trên cơ sở H.261/263.

JPEG-2000 - Chuẩn JPEG mới nhất, dựa trên cơ sở DWT (Discrete Wavelet Transform), ban đầu được phát triển cho việc nén ảnh tĩnh, hiện nay được áp dụng cho cả video.

H.264 - Mở rộng H.263, hiện chưa được phát triển


H×nh 0.3: sù ph¸t triÓn cña çc chuÈn nÐn.

Bíc 2 - LÊy mÉu:

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 khèi nhá thÝch hîp ®Ó cã

thÓ truyÒn ®i trong m«i trêng m¹ng. §èi víi çc d÷ liÖu

audio, viÖc lÊy mÉu ®îc thùc hiÖn theo thêi gian. T¬ng

11

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ụ audio-visual.

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 đó thành phần video được thực hiện trên cơ sở H.261/263.

JPEG-2000 - Chuẩn JPEG mới nhất, dựa trên cơ sở DWT (Discrete Wavelet Transform), ban đầu được phát triển cho việc nén ảnh tĩnh, hiện nay được áp dụng cho cả video.

H.264 - Mở rộng H.263, hiện chưa được phát triển


øng sau mét kho¶ng thêi 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Ï ®îc

sö dông ®Ó truyÒn ®i.Víi çc d÷ liÖu video, ngoµi viÖc

lÊy mÉu theo thêi gian 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 khung h×nh vµ viÖc lÊy mÉu theo

kh«ng gian sÏ ®îc thùc hiÖn b»ng çch chia nhá çc

khung h×nh thµnh çc phÇn víi kÝch thíc thÝch hîp ®èi

víi viÖc truyÒn ®i.

Khi lÊy mÉu, çc mÉu ph¶i chøa ®ùng ®Çy ®ñ ç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 nhËn

nhËn ®î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 mÉu qua m¹ng:

ViÖc truyÒn çc mÉu d÷ liÖu video cã thÓ ®îc thùc

hiÖn mét çch trùc tiÕp th«ng qua ç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 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.

12


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 giao thøc truyÒn th«ng thêi gian thùc ®îc thiÕt

kÕ cho viÖc truyÒn ç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 nhng cã tèc ®é truyÒn d÷

liÖu cao h¬n çc giao thøc víi ®é tin cËy cao nh TCP.

¦u ®iÓm thø hai lµ çc giao thøc thêi gian thùc hç

trî m¹nh viÖc ®ång bé çc dßng d÷ liÖu tõ çc nguån

kh¸c nhau nhng 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 giao thøc ®iÒu khiÓn cßn cung cÊp çc

dÞch vô cho phÐp qu¶n lÝ ç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 mÉu sÏ ®îc ®ãng gãi

thµnh çc gãi tin. Çc gãi tin sÏ mang ®Çy ®ñ çc th«ng

tin nh nh·n thêi gian, sè thø tù cña gãi tin vµ çc

th«ng tin kh¸c ®ñ dïng cho viÖc kh«i phôc d÷ liÖu vµ

13


®ång bé ç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 giao

thøc líp díi, ç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

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 gãi tin ®îc truyÒn

®Õn. Ç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 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

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 mÉu

d÷ liÖu mµ gãi tin mang theo. ViÖc x¸c ®Þnh ®îc vÞ trÝ

cña ç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 çch chÝnh

x¸c nhÊt. Víi viÖc truyÒn çc dßng ®¬n lÎ kh«ng cã quan

hÖ víi nhau vÒ m¨th thêi gian, th× néi dung cña audio

hay video võa ®îc kh«i phôc cã thÓ ®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ã cã quan hÖ víi nhau vÒ mÆt thêi gian thùc th× cÇn

ph¶i ®ång bé çc dßng vÒ mÆt thêi gian.

14


ViÖc ®ång bé çc dßng chØ cÇn thiÕt khi ç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 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 giao thøc

truyÒn th«ng thêi gian thùc nh RTP. Khi ®ã, mÆc dï thø

tù ç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 nhng

giao thøc vÉn ph¶i ®¶m b¶o tÝnh ®ång bé cho ç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 thiÕt bÞ ra hay ®îc ghi ra

file.

CHƯƠNG I: LỰA CHỌN CÁC GIAO THỨC PHÙ HỢP VỚI

CÁC ỨNG DỤNG THỜI GIAN THỰC

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ử

15


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.

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ử 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.

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

16


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 trặ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.

17


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.

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

1.1.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:

18

Bit 015 16

31Sourse Port Destination Port

Sequence NumberAcknowledgment Number

DataOffset(4

bits)

Reserved(6

bits)

URG

ACK

PSH

RST

SYN

FIN

Window (16 bits)

Checksum Urgent poier


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ổn

g nguồn.

- 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 0216-1 tuy nhiên các cổng nằm trong khoảng

từ 01023 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à

19


số hiệu tuần tự khởi đầu (ISN) và Byte dữ liệu đầu

tiên là ISN+1. Tham số này có vai trò như tham số

N(S) trong HDLC.

- Acknowledgment Number (32 bits): Số hiệu của

Segment tiếp theo mà trạm nguồn dang chờ để nhận.

Ngầm ý báo đã nhận tốt các Segment mà trạm trạm

đích đã gửi cho trạm nguồn. Tham số này có vai trò

như tham số N(R) trong HDLC.

- 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ỉ

20


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.

1.1.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

21


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.

1.1.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 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ì

22


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.

1.1.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ờ

PUST được dựng thì toàn bộ dữ liệu trong bộ đệm sẽ được

23


gửi đi hết dưới dạng các TCP Sgment. Còn nếu cờ PUST

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ờ PUST

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ờ PUST 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.

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 vậy cao. Đơn vị

dữ liệu dùng trong giao thúc UDP là UDP Datagram. Khuôn

24


dạng của một UDP Datagrram 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 PortUDP Message Length UDP Checksum

Data ... ...

Hình 1.3: Khuôn dạng UDP Datagram

Trong đó ý nghĩa của các trườnglà:

- 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.

- 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 để

25


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.

ĐỊ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.

26


Hình 1.4: Truyền Multicast

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 them bất 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ó hang 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

27


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õ rang 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:

28


Hình1.5: đị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.

1.4 GIAO THỨC NÀO CÓ THỂ ĐÁP ỨNG ĐƯỢC YÊU CẦU THỜI

GIAN THỰC?

Trong những ứng dụng truyền thông đa phương tiện, yêu

cầu đảm bảo khắt khe về thời gian thực (không cho phép

có thời gian trễ lớn, jitter). Việc các gói tin đến

không liên tục, đều đặn làm cho chất lượng hình ảnh,

hoặc âm thanh thu được thấp. Rất có thể gây ra vấp

hình, méo tiếng. Để đáp ứng được những yêu cầu này, một

giao thức thời gian thực cần có các yếu tố:

- Hộ trợ việc định tuyến muticast: Với các ứng dụng

tryền thông đa phương tiện đòi hỏi thời gian thực,

có sự phân phối giống dữ liệu từ một nguồn tới

nhiều đầu cuối nhận dữ liệu thì việc hỗ trợ

multicast là rất cần thiết. Đây là một yêu cầu rất

quan trọng. Khi đó, sẽ tồn tại 1 nguồn phát và rất

nhiều nguồn thu, một máy chủ xuất luồng dữ liệu

29


thời gian thực đến rất nhiều máy khách. Nếu ta sử

dụng truyền unicast, tải trọng tác động lên máy chủ

rất lớn. Trong khi đó, nếu mạng có hỗ trợ truyền

multicast, ta chỉ việc xuất một luồng duy nhất từ

máy chủ tới một địa chỉ multicast. Sau đó tại các

nút mạng, luồng dữ liệu sẽ được nhân lên và chuyển

tiếp tới những địa chỉ đích.

Hình 1.6:Sử dụng Multicast trong truyền dữ liệu đa phương tiện.

- Chấp nhận một số gói tin bị lỗi: Không thể đợi để

truyền lại các gói, đoạn, gam dữ liệu bị thất lạc.

Việc truyền lại các dữ liệu bị thất lạc hoặc bị lỗi

sẽ chiếm khá nhiều thời gian. Nó sẽ làm tăng lượng

tải trên đường truyền đồng thời kéo dài thời gian

trễ của các gói tin.

- Cần kết hợp với một thông số về thời gian (nhãn

thời gian) kèm theo gói dữ liệu: Với các tín hiệu

thời gian thực, đặc biệt là tín hiệu video, việc

30


khôi phục đồng bộ tại phía thu là rất quan trọng,

do đó đòi hỏi nhãn thời gian kèm theo để phục vụ

cho việc tái tạo lại dữ liệu tại nơi nhận. Đặc

biệt, khi tín hiệu video được mã hoá theo từng

khung hình, mỗi khung hình được vận chuyển trong

nhiều gói RTP. Khi đó nhãn thời gian sẽ giúp ta

phân định từng nhóm gói tin tương ứng với một hình

một cách dễ dàng.

Trong những giao thức ở lớp vận chuyển thì giao thức

nào có thể đáp ứng được yêu cầu trên:

TCP:

Đây 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.

Trong khi truyền dữ liệu giao thức TCP phải đảm bảo các

cơ chế xác nhận việc gởi dữ liệu, đảm bảo xắp xếp đúng

thứ tự các gói tin tại bên nhận, phát lại các gói tin

bị lỗi hoặc thất lạc. Do việc phải đảm bảo những cơ chế

này gây lên thời gian trễ lớn, nên giao thức TCP không

thể dùng được trong những ứng dụng thời gian thực.

Ngoài ra với tính chất vốn có của mình, TCP là giao

thức được sử dụng để truyền dữ liệu theo kiểu điểm tới

điểm, hay nói cách khác TCP chỉ được dùng cho truyền

unicast, không thể sử dụng cho truyền multicast.

31


Với những đặc điểm trên, TCP không nên được sử dụng

trong việc truyền dữ liệu mang tính thời gian thực.

UDP:

Đây 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 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.

Ngoài ra, giao thức UDP còn có thể sử dụng cho truyền

multicast.

Do vậy UDP có thể được sử dụng để truyền các dữ liệu

thời gian thực. Tuy nhiên để đảm bảo đáp ứng được các

yêu cầu của các ứng dụng thời gian thực, giao thức UDP

phải được kết hợp với một giao thức lớp trên, đó là

giao thức RTP.

32


CHƯƠNG II: TỔNG QUAN GIAO THỨC THỜI GIAN THỰC RTP

(REAL TIME PROTOCOL)Qua những nhận xét ở chương II, 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.

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).

33


Hình 2.1: 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á:

34


Hình 2.2:Nhãn thời gian và sự đ ồng bộ.

- Theo dõi quá trình truyền tải: delivery

monitoring.

Hình 2.3: 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ụ cac

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 mạng và lớp giao vận.

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

35


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ô 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ự ứ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 RCTP: 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ề

36


những phiên truyền. RTCP giúp cho việc điều khiển

các phiên.

2.2 ứ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 2.4: Vị trí RTP trong các ứng dụng multimedia

2.2.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 RCTP. Trong trường hợp cần yêu cầu

37


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 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 hoặc 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 đượ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

38


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.

2.2.2 Hội thảo sử dụng thoại và video (Audio andVideo Conference):

Hình 2.5: 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

39


cặp RTP/RTCP. Việc truyền tín hiệu tiếng và tín hiệu

hình là 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

40


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.

41


CHƯƠNG III: 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.

3.1. 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

42


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 RCTP 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. Khái niệm Port tương đương với khái

niệm TSEL (transport selectors) trong mô hình OSI. 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.

43


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. Cụ thể hơn về

các loại RTP được trình bày trong phụ lục 3.

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 RCTP).

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

Mutilmedia, các tín hiệu thành phần (video/audio) được

truyền theo một cặp cổng riêng.

44


Hình 3.1: 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 (xem chương 7).

Hình 3.2: Minh hoạ các nguồn đồng bộ SSRC.

Mixer (bộ trộn): Đây là một hệ thống trung gian,

có thể nhận các gói RTP từ một hoặc nhiều nguồn đồng bộ

khác nhau. Do đó dạng của dữ liệu thu được có thể khác

nhau. Mixer sẽ kết hợp các gói có cùng dạng rồi chuyển

tiếp trong 1 gói RTP mới. Khi đó thời gian được gắn

45


theo các gói tin sẽ bị mất đồng bộ, nên mixer sẽ thay

đổi lại các nhãn thời gian cho thích hợp cho mỗi luồng

ra. Mixer khi hoạt động có vai trò như một nguồn đồng

bộ.

Hình 3.3: hoạt động của Mixer.

Contributing source (CSRC): Khi dòng các gói RTP được

tổng hợp nhờ bộ Mixer. Bộ Mixer sẽ chèn một danh sách

CSRC chứa các định danh SSRC của các nguồn đã được

tổng hợp. Việc này giúp cho bên nhận có thể dễ dàng

phân tách địa chỉ SSRC tương ứng với từng nguồn gởi.

46


Hình 3.4: Minh hoạ việc chèn danh sách CSRC khi đi qua bộ Mixer.

End system: Mỗi ứng dụng mà sinh ra dữ liệu để

truyền đi trong những gói RTP, hoặc nhận những dữ liệu

này để xử lý được gọi là hệ thống cuối RTP (End

system). Một hệ thống cuối này có thể tương đương với

một hay nhiều nguồn đồng bộ trong một RTP session, tuỳ

thuộc vào số định danh SSRC mà nó sử dụng.

Translator: Đây là một hệ thống trung gian có nhiệm

vụ chuyển tiếp các gói RTP mà không làm thay đổi giá

trị của SSRC.

Hình 3.5: Ttranslator.Non-RTP means: Dùng để chỉ các giao thức hay các cơ

chế được sử dụng kết hợp với RTP để tạo ra những dịch

vụ cụ thể, khả dụng.

TimeStamp: Được sử dụng theo qui định giao thức thời

gian mạng (Network Time Protocol), thời gian tính bằng

số giây kể từ 0h UTC ngày 1-1-1900. Giá trị này được

47


biểu diễn bằng 64 Bits. 32 Bits đầu biểu diễn phần

nguyên, 32 Bits sau biểu diễn phần thập phân. Tuy nhiên

trong một số trường hợp, người ta chỉ dùng 32 Bits

giữa, khi đó sẽ cần có sự phân biệt giữa 16Bits cao của

phần nguyên và 16Bits cao của phần thập phân. Với cách

đánh thời gian theo NTP, đến năm 2036 nó sẽ quay trở

lại giá trị zero. Tuy nhiên với các ứng dụng thời gian

thực, chúng ta chỉ cần xét khoảng thời gian chênh lệch

do đó với chu kỳ như vậy là hoàn toàn thoả mãn.

3.2. CẤU TRÚC PHẦN TIÊU ĐỀ GÓI RTP:

Cấu trúc khung phần tiêu đề gói RTP như hình vẽ:

000

1

0

2

0

3

0

4

0

5

0

6

0

7

0

8

0

9

1

0

1

1

1

2

1

3

1

4

1

5

1

6

1

7

1

8

1

9

2

0

2

1

2

2

2

3

2

4

2

5

2

6

2

7

2

8

2

9

3

031

Ver P X CC M PT Sequence Number

Timestamp

SSRC

CSRC [0..15] :::

Hình 3.6: Cấu trúc phần header gói RTP.

Trong phần tiêu đề của gói RTP 12 Octets đầu tiên là cố

định cho mọi gói RTP. Còn danh sách CSRC chỉ 48ing vào

khi ta cho qua bộ Mixer. Bây giờ ta sẽ phân tích 48ing

năng cụ thể của 48ing trường:

1. version (V): 2 bits

48

http://www.networksorcery.com/enp/protocol/rtp.htm#Ver,%20Version

http://www.networksorcery.com/enp/protocol/rtp.htm#CSRC,%20Contributing%20source

http://www.networksorcery.com/enp/protocol/rtp.htm#SSRC,%20Synchronization%20source

http://www.networksorcery.com/enp/protocol/rtp.htm#Timestamp

http://www.networksorcery.com/enp/protocol/rtp.htm#Sequence%20Number

http://www.networksorcery.com/enp/protocol/rtp.htm#PT,%20Payload%20Type

http://www.networksorcery.com/enp/protocol/rtp.htm#M,%20Marker

http://www.networksorcery.com/enp/protocol/rtp.htm#CC,%20CSRC%20count

http://www.networksorcery.com/enp/protocol/rtp.htm#X,%20Extension

http://www.networksorcery.com/enp/protocol/rtp.htm#P,%20Padding


Trường này 49ing để xác định Verson của RTP. Hiện

nay trong truyền Video và Audio RTP đang sử dụng

Verson 2. Verson 1 là Verson được sử dụng đầu tiên. Còn

Verson 0 chỉ là giao thức 49ing cài đặt thêm các 49ing

năng cho Audio.

2. padding (P): 1 bit

Nừu bit đệm này được đặt giá trị 1, báo rằng gói

tin có chứa 1 số byte điều kiện phụ ở phần cuối (cuối

phần payload). Byte cuối cùng trong các byte đệm sẽ

chứa số các byte đệm đã được thêm, kể cả chính byte đó.

Các byte đệm này có thể được 49ing để mã hoá mật gói

tin, hoặc 49ing trong trường hợp đóng gói nhiều gói RTP

trong 1 gói của lớp dưới.

3. extension (X): 1 bit

Khi bit này được gán giá trị 1 tức là sau phần tiêu

đề cố định sẽ là phần tiêu đề mở rộng. Việc mở rộng

thêm phần tiêu đề nhằm tăng thêm lượng thông tin cho

gói RTP khi cần thiết.

4. CSRC count (CC): 4 bits

Phần này chứa số lượng các bộ nhận dạng CSRC sẽ

được thêm vào sau phần tiêu đề cố định. Dùng để xác

định số các phần tử 32 bit được chứa trong phần CSRC.

5. Marker (M): 1 bit

49


Bit này được 50ing với mục đích báo hiệu. Ta có thể

50ing nó để làm sự kiện báo hiệu khung trong trường hợp

ta truyền các gói tin thành dòng. Bit này có thể được

sử dụng hoặc không. Nừu không sử dụng ta có thể thay

đổi số lượng bit trong trường payload type.

6. Payload type (PT): 7 bits

Trường này 50ing để xác định dạng 50ing50t của phần

tải để chọn lựa các ứng dụng phù hợp. Giá trị của phần

định dạng tải này có thể cố định trong một phiên RTP

nếu ta sử dụng phương pháp mã hoá tĩnh. Nó sẽ có giá

trị biến đổi nếu như trong phiên RTP đó ta sử dụng cơ

chế định dạng động.

Một nguồn RTP có thể thay đổi định dạng tải trong

một phiên truyền, tuy nhiên ta không nên 50ing 1 phiên

RTP để truyền đồng thời các luồng media có định dạng

khác nhau, theo khuyến cáo của RFC1890.

Về phía nhận, nếu nhận được gói RTP có định dạng

tải mà nó không hiểu, gói này sẽ phải được bỏ qua.

Có một số loại tải như:

Audio:

PCM A-law

PCM m-law

GSM

Video:

50


CelB

JPEG

H.261

MPEG

Cụ thể hơn về định dạng và các hằng số tương ứng

của PT được trình bày trong phụ lục 3.

7. Sequence number: 16 bits

Số thứ tự được đánh tăng dần theo số lượng các gói

RTP được phát đi. Phía nhận sẽ sử dụng số thứ tự này để

khôi phục lại trật tự các gói, hoặc 51ing để phát hiện

số lượng gói đã bị mất.

Việc khởi tạo các giá trị này nên được thực hiện

theo cơ chế ngẫu nhiên, nhằm tăng tính bảo mật, bởi nó

có thể được kết hợp với khoá mã. Chúng ta sẽ đề cập rõ

hơn ở phần sau.

8. Timestamp: 32 bits

Nhãn thời gian được tính theo thời điểm lấy mẫu

của byte đầu tiên trong gói RTP. Thời gian được sử

dụng theo chuẩn thời gian NTP.

Nhãn thời gian phải được lấy từ đồng hồ nhịp

chuẩn, có độ chính xác cao, nhằm đảm bảo cho việc

kiểm tra đồng bộ và xác định độ Jitter giữa các gói

tin khi đến đích. Điều này rất quan trọng, nếu ta

51


truyền tín hiệu Video thì Jitter có thể gây ra hiện

tượng vấp hình.

Tần số nhịp của nhãn thời gian phụ thuộc vào 52ing

trường hợp cụ thể, thường do loại định dạng tải quyết

định. Với ứng dụng thoại, ta lấy mẫu với tần số 8

KHz. Các gói tin sẽ được truyền đi theo 52ing khối

sau mỗi khoảng thời gian 20ms, tương ứng với 160 mẫu,

. Do vậy mỗi nhãn thời gian liên tiếp sẽ có giá trị

cách nhau 160 đơn vị, không cần quan tâm gói dữ liệu

trước có được nhận hay không.

Tương tự như số thứ tự, giá trị khởi tạo của nhãn

thời gian cho mỗi phiên truyền là ngẫu nhiên.

9. SSRC: 32 bits

Trường này 52ing cho việc định danh một nguồn đồng

bộ. Giá trị của trường này được chọn một cách ngẫu

nhiên (có kiểm tra xung đột) để tránh trường hợp trong

một phiên RTP có nhiều hơn một nguồn đồng bộ sử dụng

cùng một giá trị SSRC.

Tuy xác 52ing mà nhiều nguồn phát chọn cùng một

định danh là rất hiếm, nhưng chúng ta vẫn phải cài đặt

cơ chế xác định và giải quyết sự xung đột này (xem phần

6.1.2).

52


Khi một nguồn thay đổi địa chỉ truyền tải nguồn

(source transport address), thì nó cũng phải chọn một giá

trị SSRC mới để tránh trường hợp xung đột.

10. CSRC:

Danh sách này được 53ing vào do bộ Mixer. Tại phía

người nhận, nó được 53ing để xác định rõ xem thông tin

nào của nguồn nào gởi.

Danh sách này sẽ có từ 0 đến 15 phần tử. Mỗi phần

tử chiếm 32 bit. Nó được 53ing để xác định số nguồn tin

tạo ra nội dung trong phần tải. Do danh sách chỉ chứa

được tối đa 16 phần tử, nên khi có nhiều hơn 16 nguồn

tới thì một số nguồn sẽ bị loại bỏ, hoặc sử dụng cơ chế

gán vòng.

Ta có thể diễn giải cụ thể hơn qua ví dụ: Trong một

cuộc hội đàm, có nhiều thành viên cùng gởi tin tức đi.

Xét tại bộ Mixer ở gần một thành viên nào đó. Bộ Mixer

sẽ tổng hợp các nguồn tin này vào một gói. Đồng thời

53ing thêm danh sách CRSC , chứa thông tin định danh

các nguồn gởi được tổng hợp trong gói tin. Về phía

nhận, sau khi gói tin được nhận, dựa vào danh sách này

sẽ xác định xem phần thông tin nào trong gói là của

thành viên nào gởi.

3.3 GHÉP CÁC PHIÊN TRUYỀN RTP:

53


Trong giao thức RTP, việc ghép kênh được dựa trên các

địa chỉ giao vận (transport address), đây là địa chỉ

kết hợp giữa địa chỉ mạng và định danh cổng tham gia

phiên truyền. Mỗi địa chỉ này sẽ xác định một phiên

RTP.

Trong trường hợp một cuộc hội thảo qua mạng, chúng ta

sử dụng đồng thời 2 thành phần âm thanh và hình ảnh.

Khi đó mỗi thành phần sẽ được mã hoá theo những định

dạng khác nhau, được mang trên những phiên RTP độc lập

với địa chỉ giao vận riêng.

Quá trình phân kênh sẽ được thực hiện dựa trên địa

chỉ SSRC. Khi ta truyền các gói dữ liệu khác loại mà sử

dụng cùng một địa chỉ SSRC sẽ gặp phải một số vấn đề:

- Phía nhận có thể hiểu đây là hai luồng thoại sử

dụng cùng một phiên truyền, với cùng giá trị SSRC.

Một luồng sẽ được coi là thay đổi cách mã hoá (dựa

trên trường payload type). Nhưng nó không thể biết

được luồng nào là gốc và luồng nào có thay đổi

cách mã hoá.

- Một nguồn SSRC chỉ 54ing một dãy nhãn thời gian và

một chuỗi số thứ tự. Trong khi đó việc truyền đồng

thời nhiều loại tải, tốc độ nhịp khác nhau sẽ yêu

cầu phải có một chuỗi số thứ tự riêng để xác định

sự thất lạc của các gói tin trong khi truyền.

54


- Các bảng thông báo RTCP của phía nhận và phía gởi

chỉ có thông tin về 1 dãy nhãn thời gian và một

dãy số thứ tự, không hề có thông tin về trường

phân loại định dạng tải.

- Các bộ Mixer không thể hiểu 1 luồng đầu vào bao

gồm các thành phần khác định dạng xen lẫn nhau.

Để khắc phục vấn đề này, chúng ta có thể chọn giải pháp

sử dụng các địa chỉ SSRC khác nhau cho mỗi luồng tín

hiệu và truyền chung trong 1 phiên RTP. Nhưng khi đó ta

lại gặp phải vấn đề:

Việc truyền đồng thời nhiều loại dữ liệu sử dụng

chung 1 phiên RTP sẽ có một số vấn đề. Không thể thực

hiện việc tìm đường khác nhau đối với 55ing loại dữ

liệu cho phù hợp với tài nguyên của mạng. Không thể cho

người 55ing lựa chọn việc chỉ nhận một loại dữ liệu

(tiếng hặc hình). Mà điều này khá cần thiết, khi một

thành viên tham gia hội thảo mà đang sử dụng đường

truyền tốc độ thấp, họ cần chọn giải pháp chỉ chấp nhận

tín hiệu âm thanh.

3.4. SỰ THAY ĐỔI PHẦN TIÊU ĐỀ TRONG MỘT SỐ TRƯỜNG HỢP:

Với phần tiêu đề như trên, chúng ta có thể đảm bảo

được những yêu cầu của tập các hàm cơ bản trong các ứng

55


dụng RTP. Tuy nhiên với một số yêu cầu nâng cao, ta cần

thêm vào một số trường trong phần tiêu đề:

Các trường M, PT mang các thông tin đặc trưng cho

56ing ứng dụng. Các trường này được đặt trong phần tiêu

đề cố định, trong khi đó để 56ing được cho rất nhiều

ứng dụng khác nhau, đòi hỏi chúng phải có độ dài tới 32

Bit. Do vậy, những trường này có thể phải được định

nghĩa lại trong các trường đánh dấu mở rộng. Tất nhiên,

khi ta thêm các byte đánh dấu này thì nên để 1 bit báo

hiệu để có thể phân biệt giữa trường hợp có mở rộng và

không mở rộng. Bit này sẽ nằm trong phần tiêu đề cố

định.

Một số thông tin thêm được xác định phụ thuộc vào

56ing loại định dạng của dữ liệu. Ví dụ, trong trường

hợp mã hoá tín hiệu Video, phần thông tin thêm vào nên

được đặt trong phần tải. Nó có thể được đặt ở phần đầu

tiên của tải hoặc cũng có thể đặt ở một vị trí nào đó

trong phần tải mà đã được mặc định trước.

Một số lớp ứng dụng, các 56ing năng cài đặt thêm

không phụ thuộc vào loại định dạng tải. Khi đó phần

thông tin thêm vào nên là cố định và đặt ngay sau phần

tiêu đề cố định. Điều này giúp cho các ứng dụng có thể

nhanh chóng và trực tiếp xử lý các thông tin trong

56


trường được thêm. Trong khi đó các vẫn thực hiện đồng

thời việc phân tích 12 byte tiêu đề cố định.

3.4.1 Phần tiêu đề mở rộng:

Một cơ chế mở rộng được cung cấp cho phép việc cài

đặt các hàm đơn lẻ hoạt động độc lập với loại định dạng

của tải. Cơ chế được thiết kế sao cho phần tiêu đề mở

rộng là trong 57ing đối với các hàm không được cài đặt

cơ chế mở rộng.

Chú ý rằng, phần mở rộng này chỉ dành cho một số

người người 57ing, khi mà đa phần người sử dụng đều

57ing đến thành phần này thì nó sẽ được đưa vào phần

tiêu đề cố định.

000

1

0

2

0

3

0

4

0

5

0

6

0

7

0

8

0

9

1

0

1

1

1

2

1

3

1

4

1

5

1

6

1

7

1

8

1

9

2

0

2

1

2

2

2

3

2

4

2

5

2

6

2

7

2

8

2

9

3

031

Defined by profile length

Header extension

Hình 3.7: cấu trúc phần tiêu đề mở rộng.

Nếu bit X ở phần tiêu đề cố định có giá trị 1, phần

tiêu đề mở rộng sẽ được nối thêm vào phần tiêu đề cố

định, sau phần danh sách CSRC (nếu có).

Trong phần mở rộng, 16-bit đầu tiên sẽ chứa số đếm số

từ 32-bit được thêm trong phần mở rộng, trừ 32—bit đầu

57


tiên dùng định dạng. Do vậy trường length sẽ lấy giá

trị hợp lệ tính từ 0.

Phần tiêu đề mở rộng phải đảm bảo một số điều kiện.

Trong suốt đối với các hàm xử lý gốc. Các tiêu đề mở

rộng khác loại không ảnh hưởng đến nhau. Một hàm cài

đặt mở rộng có thể tương thích với nhiều hơn 1 loại

tiêu đề mở rộng.

Để thực hiện những yêu cầu trên, phần tiêu đề mở rộng

được thiết kế với 16-bit đầu tiên được dùng với cho

việc nhận biết hoặc dùng để truyền tham số.

CHƯƠNG IV: GIAO THỨC ĐIỀU KHIỂN RTP

(RTCP: RTP CONTROL PROTOCOL)Như ta đã biết, giao thức RTP bản thân nó không có cơ chế

bảo đảm gói tin có thể đến đích theo đúng thứ tự, đúng thời

gian. Do vậy để có thể điều khiển việc vận chuyển các gói RTP

trên mạng cần có thêm một giao thức hỗ trợ. Đó chính là giao

58


thức điều khiển RTP, hay còn được gọi tắt là RTCP. Đây là một

phần rất quan trọng trong chùm giao thức RTP. Vậy tại sao

RTCP có thể đảm nhận được chức năng này, chúng ta sẽ đi

vào tìm hiểu cụ thể các chức năng, cấu trúc và hoạt động của

RTCP

4.1 CHỨC NĂNG VÀ HOẠT ĐỘNG CỦA RTCP:

Giao thức này dùng để điều khiển các gói mang tin

trong phiên truyền của mỗi thành viên, được phân phối

theo cùng cơ chế như các gói mang tin. Các giao thức

lớp dưới phải đảm bảo các gói mang dữ liệu RTP và các

gói mang thông tin điều khiển RTCP được truyền trên 2

cổng UDP khác nhau. Thường thì các gói mang thông tin

điều khiển đi qua cổng lẻ, các gói dữ liệu đi qua cổng

chẵn.

Hình 4.1: Hoạt động của RTCP

Giao thức RTCP được sử dụng với một số chức năng sau:

59


Cung cấp các thông tin phản hồi về chất lượng của

đường truyền dữ liệu.

Đây là một phần không thể thiếu được với vai

trò là một giao thức giao vận, nó liên quan đến

các hàm điều khiển luồng (flow control) và kiểm

soát sự tắc nghẽn (congestion control). Chức

năng này được thực hiện dựa trên các bản tin

thông báo từ phía người gởi và phía người nhận.

Thông tin hồi đáp có thể được sử dụng trực

tiếp cho việc điều khiển việc thay đổi phương

pháp mã hoá (adaptive encoding). Trong trường

hợp truyền IP multicasrt, thì các thông tin hồi

tiếp từ phía người nhận là tối quan trọng cho

việc chuẩn đoán các sự cố xảy ra trong quá trình

truyền.

Ngoài ra, việc các bản tin phản hồi từ phía

người nhận đến tất cả các thành viên khác giúp

cho mỗi thành viên có thể quan sát lỗi và đánh

giá xem lỗi xảy ra với mình là lỗi cục bộ hay là

lỗi trên toàn mạng.

Với cơ chế truyền IP multicast, có thể cần đến

một thực thể đóng vai trò của nhà cung cấp dịch

vụ, nhận các thông tin phản hồi. Thực thể này

60


đóng vai trò bên thứ 3, quan sát và phân tích

các vấn đề xảy ra.

RTCP mang một thông tin định danh ở lớp vận chuyển

gọi là CNAME (canonical name). Thông tin này giúp

ta định danh một nguồn phát RTP(tương ứng với 1

thành viên tham gia hội thảo).

Trong 1 phiên truyền RTP, khi giá trị của SSRC

của phía phát thay đổi có thể gây ra xung đột sẽ

đòi hỏi thiết lập lại kết nối. Do đó phía nhận

cần sử dụng CNAME để duy trì kết nối tới từng

thành viên.

Ngoài ra, việc CNAME có thể xác định được từng

thành viên, giúp cho bên nhận có thể phân chia

những luồng tin nhận được thành từng tập tương

ứng với từng người gởi. Ví dụ, xác định một cặp

tín hiệu video/audieo của cùng một người gởi (vì

2 luồng này có định danh SSRC khác nhau). Điều

này giúp cho việc đồng bộ tín hiệu audio với tín

hiệu video.

Việc đồng bộ nội cho từng luồng tín hiệu

(video hoặc audio) được thực hiện dựa trên các

thông tin về số thứ tự, nhãn thời gian gắn trên

các gói RTP và RTCP của bên gởi.

61


Hai chức năng trên đòi hỏi tất cả các thành viên

đều phải gởi đi các gói RTCP. Do vậy, trong trường

hợp có một số lượng lớn người cùng tham gia hội

thảo, đòi hỏi phải có sự điều chỉnh tốc độ cho phù

hợp để dành tài nguyên cho các gói RTP. Dựa vào

việc mỗi thành viên gởi gói tin điều khiển của

mình tới tất cả các thành viên khác, mỗi thành

viên có thể độc lập quan sát số lượng người tham

gia. Con số này sẽ được dùng để tính toán tốc độ

truyền. Việc tính toán tốc độ được nêu cụ thể tại

phần 4.3

Chức năng tuỳ chọn.

Cho phép tuỳ chọn các chức năng, giúp giảm tối

đa các việc truyền các thông tin điều khiển.

Điều này rất hữu ích trong các phiên truyền

"loosely controlled", các thành viên có thể tham gia

và rời bỏ mà không điều khiển quan hệ tới các

thành viên khác. Ví dụ, một thành viên chỉ cần

nghe các thông tin chuyển tới, như một RTCP

Server. Nó có thể sử dụng một kênh thích hợp kết

nối với tất cả các thành viên, nhưng nó không

cần sử dụng tất cả các chức năng của một ứng

dụng.

62


3 chức năng đầu nên được cài đặt trong mọi môi trường

hoạt động, đặc biệt là trong môi trường IP multicast.

Những nhà thiết kế ứng dụng RTP nên tránh các cơ chế mà

chỉ sử dụng được trong môi trường unicast, không tương

thích với số người dùng lớn. Việc truyền tải RTCP có

thể được điều khiển khác nhau giữa người nhận và người

gởi, trong trường hợp sử dụng đường truyền đơn hướng.

4.2. CÁC LOẠI GÓI TIN RTCP:

Chúng ta sẽ đề cập đến nhiều loại gói tin RTCP

tương ứng với những loại thông tin điều khiển khác

nhau:

- SR (Sender report): Bản tin phía gởi, dùng để

thông tin về trạng thái truyền và nhận của phía

gởi tin.

- RR (Receiver report): Bản tin người nhận, dùng để

thông tin về trạng thái nhận của phía nhận tin.

- SDES (Source description items): Thông tin mô các

về nguồn gởi, bao gồm cả CNAME.

- BYE: Dùng khi thành viên nào đó thoát khỏi hội

thảo.

- APP (Application specific functions): Xác định các

chức năng phụ thuộc vào từng ứng dụng cụ thể.

Mỗi gói tin RTCP được bắt đầu với phần tiêu đề cố

định tương tự như của gói tin RTP, tiếp theo là các

63


thành phần cấu trúc, chúng có thể có chiều dài biến đổi

tuỳ thuộc vào loại của gói tin, nhưng phải giới hạn

trong 32-bit.

Sự chuẩn hoá và các trường có chiều dài cố định

trong mỗi gói RTCP làm cho chúng có thể được lưu trong

ngăn xếp. Nhiều gói RTCP có thể được kết nối với nhau

thành gói ghép (compound packet ), mà không cần sử dụng

dấu phân cách giữa các gói RTCP, khi đưa chúng xuống

đóng gói ở các lớp dưới. Ví dụ như đóng trong các gói

UDP.

Mỗi gói RTCP trong gói ghép có thể được xử lý một

cách độc lập, không cần dựa vào thứ tự hoặc sự kết hợp

giữa các gói. Tuy nhiên để thực hiện được điều này thì

ta phải thiết lập một số ràng buộc:

- Các thông báo trạng thái (trong RS hoặc RR) phải

được gởi đi định một cách thường xuyên nhất có

thể, điều này cho phép để cập nhật các thông tin

trạng thái. Trong mỗi gói ghép RTCP, phải có 1 gói

mang bản tin (RS hoặc RR).

- Một người nhận mới cần nhận được giá trị CNAME

càng sớm càng tốt. Điều này giúp cho việc định

danh nguồn gởi, từ đó có thể thực hiện đồng bộ

giữa các thành phần (video/audio). Do vậy trong

mỗi gói ghép RTCP cần phải có gói SDES chứa CNAME.

64


- Số các kiểu gói có thể chứa trong phần đầu tiên

của gói ghép. Để giới hạn sự gia tăng của các hằng

số định kiểu, giá trị này được chứa trong 2 Byte.

Mỗi gói tin RTCP phải được gởi trong một gói ghép

chứa được ít nhất 1 bộ các gói RTCP riêng lẻ được chỉ

ra sau đây:

- Encryption prefix: tiền tố của phần mã mật.

Trường này chỉ được sử dụng khi gói tin được mã

hoá theo phương thức mã mật được đề cập ở phần sau.

Đây là một chuỗi 32-bit truyền kèm theo mỗi gói

ghép. Nếu trường đệm (padding) được truyền theo mã

mật thì nó sẽ được thêm vào ở gói cuối cùng trong

gói ghép.

- SR hoặc RR:

Gói RTCP đầu tiên trong gói ghép luôn là gói

report packet, để xác định hiệu lực của phần

header. Sự kiện này phải luôn được đảm bảo. Nếu

trong trường hợp không có dữ liệu được gởi hay nhận

thì RR rỗng sẽ được gởi, thậm chí trong trường hợp

trong gói ghép chỉ chứa 1 gói BYTE.

- Additional RRs:

Khi số nguồn gởi các thông tin trạng thái vượt quá 31

(giá trị tối đa mà SR hoặc RR có thể chứa), khi đó gói

RR sẽ được thêm vào sau gói report packet khởi tạo.

65


- SDES:

Một gói SDES có chứa CNAME Phải được thêm vào mỗi gói

RTCP ghép. Còn một số các thông số về nguồn phát khác

có thể được lựa chọn, tuỳ thuộc vào từng ứng dụng cụ

thể.

- BYE or APP:

Một số gói RTCP loại khác có thể được đặt ở các vị trí

bất kỳ. Ngoại trừ gói BYTE nên nằm ở vị trí cuối cùng,

với các giá trị SSRC/CSRC.

Hình 4.2: Minh hoạ việc ghép các gói RTCP vào gói UDP.

Thông thường, các bộ translators và mixers sẽ xử lý

từng gói RTCP riêng lẻ từ các nguồn khác nhau, sau đó

chuyển tiếp trong một gói ghép. Nếu gói ghép này có

kích thước vượt quá giá trị của một đơn vị truyền tải

(maximum transmission unit), khi đó nó sẽ được phân

thành các gói ghép nhỏ hơn để có thể tryền được trong

những gói của giao thức lớp dưới. Nhưng chú ý rằng, mỗi

gói ghép sau khi chia vẫn phải đảm bảo được bắt đầu bởi

một gói SR hoặc RR.

66


Nên cài đặt cơ chế tự động bỏ qua một gói RTCP mà ta

không xác định được loại. Cũng cần cài đặt thêm cơ chế

để một loại gói RTCP mới có thể được đăng ký với IANA

(the Internet Assigned Numbers Authority).

4.3 KHOẢNG THỜI GIAN TRUYỀN CÁC GÓI RTCP :(RTCP TRANSMISSION INTERVAL)RTP được thiết kế để cho phép một ứng dụng có thể tự

co giãn kích cỡ phiên truyền từ vài thành viên đến

hàng nghìn thành viên.

Ví dụ, trong cuộc hội thảo thoại, lưu lượng dữ liệu

vốn đã tự giới hạn. Bởi vì trong cùng một thời điểm,

chỉ có 1 hoặc 2 người cùng phát biểu. Do vậy đối với

việc truyền multicast, tốc độ dữ liệu để duy trì một

liên kết là tương đối ổn định, độc lập so với số thành

viên tham gia.

Tuy vậy, lưu lượng dùng cho việc điều khiển thì

không được hạn chế như vậy. Nếu các bản báo nhận cửa

mỗi thành viên được duy trì ở một tốc độ phát không

đổi, thì lưu lượng của luồng điều khiển sẽ tăng tỉ lệ

với số thành viên tham gia. Do đó, tốc độ phát phải

được thay đổi động dựa trên tính toán khoảng thời gian

phát các gói RTCP liên tiếp.

Với mỗi phiên truyền giả sử rằng lưu lượng dữ liệu

chịu ảnh hưởng của một tập các giới hạn, gọi là băng

thông của phiên truyền (session bandwidth). Băng

67


thông có thể được cung cấp và bị giới hạn bởi nhà

cung cấp dịch vụ. Nếu không có sự giới hạn của nhà

cung cấp thì sẽ có một số ràng buộc, phụ thuộc vào

môi trường mạng. Điều này sẽ giới hạn số phiên truyền

tối đa có thể chấp nhận. Giá trị này có thể được hiểu

như là session bandwidth.

Việc chọn băng thông này có thể dựa trên yếu tố giá

thành hoặc kinh nghiệm của nhà thiết kế. Thông thường

giá trị của nó sẽ phụ thuộc vào kiểu định dạng của dữ

liệu.

Các thông số của session bandwidth là cố định,

được quyết định bởi sự quản lý phiên của ứng dụng.

Tuy nhiên, các ứng dụng có thể thiết lập một giá trị

mặc định, tương ứng với dải thông dữ liệu (data

bandwidth ) của từng người gởi, tương ứng với từng

cách mã hoá dữ liệu. Tất cả các thành viên đều phải

sử dụng cùng một giá trị session bandwidth, do đó

khoảng thời gian phát gói RTCP sẽ được tính giống

nhau.

Việc tính toán băng thông cho lưu lượng dữ liệu và

lưu lượng thông tin điều khiển, được thực hiện ở lớp

mạng và lớp giao vận.

Lưu lượng điều khiển nên giới hạn chỉ là một phần

nhỏ của session bandwidth, để việc truyền tải dữ liệu

68


không bị ảnh hưởng. Theo khuyến nghị, luồng RTCP nên

chiếm 5% session bandwidth. Trong đó 1/4 giải thông của

RTCP dùng cho những thành viên hiện đang gởi dữ liệu.

Do đó, trong phiên truyền với số lượng người gởi ít,

người nhận nhiều, thì một thành viên mới kết nối có thể

nhanh chóng nhận được giá trị CNAME của thành viên đang

gởi dữ liệu.

Băng thông dành cho lưu lượng điều khiển có thể

chia làm 2 loại, một cho cac thành viên đang ở trạng

thái gởi dữ liệu, một dành cho các thành viên còn lại.

Chúng ta 2 tham số này là S và R. Theo khuyến nghị, 1/4

RTCP bandwidth dành cho người gởi dữ liệu, do vậy tỷ lệ

sử dụng băng thông của các thành viên sẽ là 1,25% và

3,75%.

Khi tỷ lệ người gởi lớn hơn 1/4 số thành viên, thì

những người gởi sẽ sử dụng cả 5% Session bandwidth.

Việc phân chia thành hai loại thành viên R, S cho phép

ta có thể giảm băng thông RTCP của những thành viên (R)

không gởi dữ liệu vể 0. Khi đó các thành viên này sẽ

không gởi đi các bản tin RTCP, mà chỉ nhận các bản tin

RTCP để phục vụ cho việc khôi phục và đồng bộ dữ liệu.

Thông thường, điều này không được khuyến khích vì nó sẽ

làm mất một số chức năng kiểm soát lỗi như đã nêu ở

phần đầu. Tuy nhiên nó rất phù hợp cho những kết nối 1

69


chiều, hoặc cho những phiên truyền không cần sự hồi đáp

về chất lượng dữ liệu nhận được, cũng như không cần

quan tâm đến sự có mặt của các thành viên chỉ nghe. Nếu

sử dụng cơ chế này ta có thể giảm được phần nào sự tắc

nghẽn trên mạng do băng thông không đủ.

Việc tính toán chu kỳ phát các gói tin ghép RTCP cũng

nên đặt ra giới hạn tránh trường hợp quá nhiều gói

tin vượt quá mức băng thông cho phép, khi số lượng

thành viên tham gia ít và không còn theo qui luật số

lớn nữa. Điều này đòi hỏi chu kỳ phát các bản thông

báo phải đủ lớn. Mỗi khi khởi động ứng dụng, thời

gian trễ được áp đặt trước cho gói RTCP ghép đầu

tiên. Sau đó các thành viên khác gởi các bản tin

thông báo gởi lại sẽ điều chỉnh lại khoảng thời gian

phát của các bản tin RTCP ngắn hơn cho phù hợp, có

thể sẽ bằng 1/2 giá trị ban đầu. Giá trị tối thiểu

khuyến cáo là 5s.

Các khoảng thời gian phát giữa các gói RTCP liên

tiếp, có thể được giảm xuống phụ thuộc vào các tham

số băng thông phiên truyền, tuân theo những yêu cầu

sau:

- Với phiên truyền Multicast, chỉ có bên chủ động

gởi số liệu mới được quyền rút gắn khoảng thời

gian gởi các gói RTCP ghép.

70


- Với phiên truyền unicast việc giảm giá trị có thể

được thực hiện bởi bên nhận lẫn bên gởi. Trong

trường hợp này, thời gian trễ được khởi tạo ban

đầu là 0 (tốc độ gởi nhanh nhất).

- Cho tất cả các phiên truyền nói chung, khoản thời

gian nhỏ nhất được cố định, dựa trên sự tính toán

dựa trên khoảng thời gian timeout của thành viên.

Với cách này, sẽ không xảy ra hiện tượng timeout

cho các gói tin RTCP, khi một thành viên nào đó

thiết lập thời gian timeout quá bé.

- Theo khuyến nghị, giá trị tối thiểu có thể được

giảm xuống bằng:

360/bw (kilobits/second).

Nếu băng thông của phiên truyền lớn hơn 72kb/s khi

đó khoảng thời gian tối thiểu sẽ nhỏ hơn 5s.

- Khoảng thời gian tính toán giữa các gói RTCP tỷ

lệ tuyến tính với số lượng các thành viên tham

gia. Việc này có thể gây rắc rối khi có một nhóm

thành viên mới đồng thời tham gia vào một phiên

truyền thiết lập sẵn. Khi đó các thành viên sẽ có

sự ước lượng sai về khoảng thời gian truyền, họ

sẽ thiết lập khoảng thời gian này nhỏ hơn so với

yêu cầu. Với số lượng thành viên tham gia đồng

thời là lớn thì việc này khá quan trọng. Để giải

71


quyết vấn đề này, người ta sử dụng thuật toán

"timer reconsideration", trong đó có cơ chế Back-

off. Theo đó, các thành viên sẽ tự động dữ lại

gói RTCP của mình khi lắng nghe thấy số lượng

thành viên đang tăng lên.

Khoản thời gian thực tế giữa các gói RTCP được biến

đổi ngẫu nhiên trong khoảng [0.5,1.5] lần giá trị tính

toán, để tránh sự đồng bộ không lường trước được của

các thành viên. Gói RTCP đầu tiên được gởi sau khi

thành viên tham gia phiên truyền cũng bị làm trễ đi một

khoảng thời gian ngẫu nhiên trong khoảng 1/2 khoảng

thời gian RTCP tối thiểu.

Ta liên tục ước lượng động giá trị trung bình của các

gói tin RTCP ghép, bao gồm cả các gói phía nhận và các

gói phía gởi. Giá trị này được dùng để tự động thay đổi

lượng thông tin điều khiển được mang đi.

Khi các thành viên rời bỏ phiên, họ sẽ gởi tín hiệu

BYE hoặc tạo ra thời gian timeout, số lượng thành viên

trong nhóm sẽ giảm. thuật toán "reverse reconsideration" sẽ

được sử dụng để các thành viên khác tăng tốc độ truyền

gói RTCP. Mặt khác, khi một người rời khỏi phiên

truyền, gói BYTE được chuyển đi luôn, không đợi đến

lượt. Do đó, để tránh tình trạng tràn số liệu, gây ra

72


khi có nhiều thành viên cùng rời đi, người ta sử dụng

thuật toán back-off.

4.4 CẬP NHẬT SỐ THÀNH VIÊN THAM GIA PHIÊN TRUYỀN:

( MAINTAINING THE NUMBER OF SESSION MEMBERS)

Việc tính toán chu kỳ gởi các gói RTCP dựa trên sự

ước lượng số thành viên tham gia trong phiên truyền.

Một thành viên mới sẽ được thêm vào biến đếm khi họ

được nghe thấy. Khi đó mỗi thành viên sẽ được thêm vào

bảng được đánh số bởi định danh SSRC hoặc CSRC để dùng

cho việc theo dõi. Một thành viên mới sẽ chưa chính

thức được thừa nhận trước khi gói tin có chứa giá trị

SSRC mới hoặc gói SDES RTCP có chứa CNAME chưa được

nhận. Thành viên này sẽ bị loại khỏi bảng khi gói RTCP

BYE có kèm theo định danh SSRC tương ứng mà họ gởi đi

được nhận. Để tránh trường hợp một gói tin lang thang

đến sau gói BYTE có thể tạo ra địa chỉ mới. Một thành

viên khi nhận được gói tin BYTE sẽ đánh dấu lại sự nhận

được đó và sẽ xoá địa chỉ SSRC tương ứng sau một khoảng

thời gian nào đó.

Một thành viên bất kỳ có thể đánh dấu một thành viên

khác ở trạng thái không hoạt động (inactive) hoặc loại

bỏ hẳn nếu không nhận được gói tin RTP và RTCP trong

một khoảng thời gian.

73


Với những phiên truyền có số lượng thành viên nhiều,

có thể không thực hiện được việc duy trì một bảng chứa

định danh SSRC và trạng thái của các thành viên. Lúc đó

ta sẽ cài đặt cơ chế lấy mẫu SSRC

4.5 QUI ĐỊNH ĐỐI VỚI VIỆC GỞI VÀ NHẬN CÁC GÓI RTCP:

Đây là qui tắc gởi một gói RTCP như thế nào và làm

gì khi nhận mỗi gói RTCP. Qui tắc phải đảm bảo hoạt

động tốt trong trường hợp truyền multicast hay truyền

unicast đa điểm và thoả mãn các điều kiện được nêu ở

phần trên. Để thực hiện được điều này, mỗi thành viên

tham gia phiên phải duy trì được một số thông tin trạng

thái sau:

-tp: Thời điểm mà gói RTCP gần nhất được gởi đi.

-tc: Mốc thời gian hiện tại.

-tn: Thời điểm mà gói RTCP tiếp theo sẽ được gởi.

-Pmembers: Số thành viên theo kết quả được tính

lần trước.

-members: Số thành viên hiện tại.

-senders: số người đang ở trạng thái gởi dữ liệu.

-rtcp_bw (The target RTCP bandwidth): Tổng băng

thông được sử dụng cho việc truyền các gói RTCP của

tất cả các thành viên tham gia phiên, đơn vị là

octets/giây. Giá trị này được sử dụng để tính tỷ lệ

74


session bandwidth được cung cấp cho ứng dụng khi bắt

đầu.

-we_sent: Khi cờ này là true dùng để chỉ ứng dụng

đã truyền dữ liệu đi quá 2 chu kỳ RTCP report.

-avg_rtcp_size: Kích thước trung bình của gói

RTCP ghép (compound RTCP) đã được gởi và nhận bởi

thành viên này, đơn vị là octets. Kích thước này

bao gồm cả phần tiêu đề được thêm vào ở tầng mạng

và tầng giao vận.

-initial: Cờ này mang giá trị true nếu ứng dụng

vẫn chưa gởi đi gói tin RTCP.

Như chúng ta thấy, rất nhiều giá trị được sử dụng cho

viẹc tính toán thời gian giữa các lượt truyền các gói

tin.

a. Tính toán khoảng thời gian truyền RTCP:

Phần trên chúng ta đã đề cập đến cơ sở lý thuyết cũng

như ý nghĩa của thời gian này:T

- Nếu số người gởi ≤25% số thành viên, chu kỳ gởi T phụ

thuộc là thành viên đó có đang gởi dữ liệu hay không

(dựa trên giá trị we_sent). Nếu thành viên này đang

gởi, giá trị (we_sent=true):

Hằng số ns được tính bằng số thành viên đang gởi.

75


Với những thành viên không gởi:

nr được tính bằng số người không gởi dữ liệu.

Khi số người gởi >25% số thành viên, tất cả người gởi

và người nhận được đối xử như nhau.

n được tính bằng tổng số thành viên tham gia.

Như đã nói ở phần trước, ta có thể phân dải thông của

RTCP thành 2 phần, tham số R, S để phân biệt giữa nhóm

người đang truyền và không. Trong trường hợp này ta chỉ

cần thay 25% bằng tỉ số S/(S+R), còn 75% bằng tỷ số

R/(R+S).

Trong trường hợp đặc biệt, khi không có người gởi, hặc

không có người nhận (S=0, hoặc R=0) sẽ xảy ra tình

huống chia cho 0, do vậy khi cài đặt ta phải chú ý các

trường hợp này.

- Nếu một thành viên không tham gia gởi gói RTCP

(initial=true), hằng số Tmin=2.5s, ngược lại nó được

đặt bằng 5s.

- Giá trị của khoảng thời gian Td sẽ được ước tính là

giá trị lớn nhất của (Tmin, n*C).

- Giá trị T sẽ được phân bố trong dải từ 0,5 đến 1,5

lần giá trị tính toán Td.

76


- Giá trị T trên sẽ được chia cho (e-1,5) để bù lại

việc băng thông RTCP trên thực tế thấp hơn so với mức

tính toán.

Theo cách tính này, khoảng thời gian T sẽ lấy giá trị

ngẫu nhiên tại một thời điểm, tuy nhiên nếu tính lâu

dài thì giá trị trung bình sẽ ≥25% RTCP sẽ được giành

cho những người gởi dữ liệu, phần còn lại dành cho

người nhận dữ liệu.

b. Các giá trị khởi tạo:

Khi một thành viên bắt đầu tham gia, giá trị khởi

tạo của các biến sẽ là:

- tp=0.

- tc=0.

- senders=0.

- pmembers=1.

- members =1.

- we_sent = false.

- rtcp_bw=5% băng thông của phiên.

- initial=true.

- avg_rtcp_size bằng giá trị của gói RTCP mà ứng

dụng sắp tạo ra.

- Dựa vào các thông số trên ta ước lượng T. sau

đó đặt thời gian cho gói đầu tiên: tn=T.

77


Chú ý: một ứng dụng bất kỳ có thể đặt lại giá

trị thời gian này cho phù hợp.

Thành viên sẽ thêm giá trị SSRC của mình vào đầu

bảng thành viên.

c. Nguyên tắc nhận một gói RTP hoặc một gói không

phải là RTCP-BYTE:

Khi một gói RTP hoặc một gói RTCP mà không phải là

BYTE từ một thành viên, bên nhận sẽ trường SSRC tương

ứng trong bảng các thành viên(member table). Nếu không

thấy, sẽ tạo một bản ghi mới và cập nhật các thông tin

về thành viên vừa được chấp nhận.Các giá trị chung

(pmembers) được cập nhật lại. Quá trình tương tự cũng

được thực hiện với các gói RTP có chứa danh sách CSRC.

Khi một gói RTP được nhận từ một thành viên mà giá

SSRC của nó chưa có mặt trong bảng danh sách người gởi,

giá trị này sẽ được thêm mới vào bảng, các thông số

dành cho người gởi (sender table) cũng được cập nhật.

Với mỗi gói tin RTCP được nhận, giá trị

avg_rtcp_size sẽ được cập nhật lại:

avg_rtcp_size = (1/16) * packet_size + (15/16) *

avg_rtcp_size.

Trong đó packet_size là kích thước của gói RTCP vừa

nhận được.

d. Nguyên tắc nhận một gói RTCP-BYTE:

78


Khi một gói RTCP-BYTE được nhận, trường SSRC sẽ

được kiểm tra lại trong bảng thành viên và bảng người

gởi. Nếu có, bản ghi tương ứng trong mỗi bảng sẽ bị

xoá. Các giá trị chung được cập nhật lại.

Hơn nữa để tốc độ phát các gói RTCP thích ứng tốt hơn

với những thay đổi trong nhóm thành viên, ta sử dụng

thuật toán "reverse reconsideration" khi nhận được gói BYTE:

- Giá trị tn, tp được cập nhật lại dựa theo công

thức:

tn=tc+ (members/pmembers) * (tn - tc).

tp = tc - (members/pmembers) * (tc - tp).

- Gói tin RTCP được lập lịch lại với thời điểm sẽ

truyền tn được rút ngắn lại.

- Giá trị pmembers được đặt bằng giá trị members.

Thuật toán này ngăn việc số lượng các thành viên

giảm xuống trong một thời gian ngắn (bằng thời gian

timeout), trong trường hợp thành viên rời khỏi phiên

một lúc, nhưng sau đó lại quay lại. Do vậy thuật toán

này giúp cho việc điều chỉnh lại giá trị chính xác

nhanh hơn.

e. Tính toán timeout một nguồn SSRC:

Cứ sau một khoảng thời gian nào đó, mỗi thành viên

phải được kiểm tra time out của các thành viên khác. Để

79


làm được điều này, các thành viên tính toán thời gian

Td cho phía nhận (có giá trị we_sent =false).

Nếu một thành viên mà không gởi một gói tin RTP

hoặc RTCP nào trong khoảng thời gian M.Td (M là hệ số

nhân, có giá trị mặc định là 5). Khi đó thành giá trị

SSRC tương ứng sẽ bị loại khỏi bảng thành viên, số

thành viên members được cập nhật lại.

Nếu một thành viên trong danh sách người gởi mà

không được nhận một gói RTP nào trong khoảng thời gian

2T.(khoảng thời gian giữa 2 gói RTCP cuối cùng được

nhận), khi đó thành viên sẽ bị loại khỏi danh sách

người gởi, số người gởi senders được cập nhật lại.

Nếu một thành viên nào “time out” ta sẽ sử dụng

thuật toán reverse reconsideration ở trên.

Quá trình kiểm tra “time out” nên được thực hiện ít

nhất 1 lần trong một chu kỳ RTCP.

f. Hoạt động của đồng hồ truyền tải:

Khi thời gian truyền gói đến, thành viên sẽ thực

hiện các thao tác sau:

- Tính toán lại giá trị T, bao gồm cả thừa số ngâu

nhiên.

- Nếu (tp+T)≤tc, một gói RTCP sẽ được gởi đi.

tp = tc,

giá trị T được tính lại.

80


tn = tc + T.

- Nếu (tp+T)>tc: không gói RTCP nào được gởi đi.

tn=tp+T.

Thời điểm truyền gói được đặt lại bằng

tn.

- pmembers = members.

Nếu một gói RTCP được truyền, giá trị của initial

được gán lại bằng FALSE. Giá trị avg_rtcp_size được

tính lại:

avg_rtcp_size = (1/16) * packet_size + (15/16) *

avg_rtcp_size.

Với packet_size là kích thước của gói RTCP vừa được

gởi.

g. Transmitting a BYE Packet:

Khi một thành viên muốn rời khỏi phiên, một gói BYE

được gởi đi để thông báo cho các thành viên khác biết.

Để tránh việc tràn dữ liệu do có nhiều thành viên cùng

gởi gói BYTE, mỗi thành viên phải phải thực hiện thuật

toán sau, nếu tại thời điểm đó số thành viên >50. Thuật

toán này có mức ưu tiên cao hơn quyền thông thường của

mỗi thành viên.

- Khi một thành viên muốn rời khỏi hệ thống:

tp được gán bằng tc.

members = pmembers =1.

81


initial =1.

we_sent=false.

senders =0.

avg_rtcp_size =kích thước của gói BYTE.

tn=tc+T. (giá trị T là giá trị cũ).

- Khi nhận được gói BYTE của một thành viên khác:

biến members tăng 1 đơn vị, không cần quan

tâm thành viên đó có trong bảng thành viên

chưa?

Bảng sample được đưa vào sử dụng, tất cả

các giá trị SSRC được đưa vào bảng này(kể cả

của gói BYTE).

Giá trị members sẽ không tăng khi nhận được

bất kỳ gói tin nào không phải là RTCP BYTE.

avg_rtcp_size cũng chỉ được tính lại khi

nhận được gói BYTE.

Bảng senders sẽ không cập nhật lại giá trị

khi nhận được gói RTP.

- Việc truyền gói BYTE được thực hiện theo cơ chế

như các gói RTCP thông thường.

Với cách thực hiện trên, gói BYTE được truyền 1

cách đúng đắn, bởi việc điều khiển tổng băng thông được

sử dụng. Trong tình huống xấu nhất, nó sẽ điều khiển

các gói tin RTCP sử dụng băng thông gấp đôi mức bình

82


thường (10%). Trong đó, 5% được sử dụng cho truyền gói

RTCP BYTE, 5% còn lại dùng truyền RTCP khác.

Nếu một thành viên không muốn đợi thực hiện cơ chế

trên, họ có thể rời bỏ nhóm bằng cách không gởi đi gói

BYTE, việc còn lại do sự kiện “time out” đảm nhiệm.

Chú ý, nếu kích thước của nhóm nhỏ hơn 50, khi

thành viên rời khỏi nhóm có thể gởi ngay gói BYTE mà

không phải chờ. Trong trường hợp một thành viên chưa hề

gởi đi một gói RTP hoặc RTCP nào thì khi rời khỏi nhóm

họ cũng không cần phải gởi đi gói BYTE.

h. Cập nhật biến we_sent:

Biến we_sent của 1 thành viên trong bảng sender sẽ

nhận giá trị true nếu thành viên mới gởi 1 gói RTP,

ngược lại nó nhận giá trị false.

Nếu một thành viên gởi đi một gói RTP thì nó sẽ cập

nhật lại giá trị biến we_sent trong bảng enders của

mình giá trị true.

i. Xác đinh băng thông nguồn:

Có một số thông tin được thêm vào gói SDES (several

source description) CNAME, NAME, EMAIL. Ngoài ra phần

thông tin thêm còn cung cấp phương tiện để định nghĩa

các loại gói RTCP mới cho từng ứng dụng cụ thể. Một ứng

dụng phải chú ý đến việc điều khiển phân chia băng

thông khi có phần thông tin kèm theo. Bởi vì chúng có

83


thể làm giảm tốc độ nhận các bản tin và CNAME được gởi,

điều này làm suy giảm hiệu suất của giao thức RTP. Theo

khuyến cáo, không nên sử dụng quá 20% băng thông RTCP

của 1 thành viên để truyền các thông tin bổ sung. Hơn

nữa không phải mọi thành phần của SDES đều được thêm

trong mọi trường hợp. Chúng chỉ nên sử dụng 1 phần băng

thông, tuỳ thuộc vào từng trường hợp cụ thể, hơn nữa tỷ

lệ này cũng biến đổi động.

Ví dụ, một ứng dụng chỉ truyền 3 thông số: CNAME,

NAME và EMAIL. Name được ưu tiên cao hơn EMAIL vì nó

luôn được hiển thị trên giao diện người dùng của ứng

dụng, còn tên chỉ cần hiển thị khi cóz yêu cầu. Một

gói RR và một gói SDES mang CNAME sẽ được truyền đi

sau mỗi khoảng 5s. Cứ 3 chu kỳ (15s) thì sẽ có một

gói mang thông tin bổ sung trong gói SDES. Trong đó

cứ 8 lần bổ sung (2 phút) thì mang giá trị NAME, còn

1ần mang giá trị EMAIL.

Trong những ứng dụng đa luồng, ta có thể phối hợp

giữa việc truyền các thông tin bổ sung và CNAME cho

mỗi ứng dụng, bằng cách sử dụng các kết nối chéo

thông qua CNAME. Ví dụ, trong một ứng dụng hội thảo

Multimedia, mỗi phiên RTP dùng truyền một thành phần,

thông tin thêm trong SDES có thể được gởi trong một

phiên RTP, còn phiên kia sẽ chỉ truyền giá trị CNAME.

84


4.6. CÁC BẢN TIN THÔNG BÁO CỦA NGƯỜI GỞI VÀ NGƯỜI

NHẬN

Trong giao thức RTP, các thành viên có thể trao

đổi thông tin điều khiển thông qua các bản tin RTCP.

Các bản tin này có 2 dạng, phụ thuộc vào phía gởi đi

là người gởi hay là người nhận dữ liệu. Sự khác nhau

giữa 2 loại bản tin này được xác định dựa trên kiểu

mã hoá, trong đó bản tin của người gởi sẽ gắn thêm

20-byte thông tin dùng cho người gởi tích cực (active

senders).

Bản tin SR được phát nếu có gói dữ liệu gởi đi

trong khoảng thời gian giữa 2 bản tin cuối cùng được

phátđi. Nếu ngược lại, bản tin RR sẽ được phát đi. Cả

bản tin SR và RR đều có thể không mang thông tin

(rỗng) hoặc mang thêm một vài khối thông tin.

Các đơn vị bản tin báo nhận (reception report

blocks) cung cấp trạng thái về số liệu được nhận từ

một thành viên, định danh của thành viên này cũng

được mang theo trong bản tin report. Một gói SR hoặc

RR có thể chứa tối đa 31 khối các bản tin này báo

nhận này.

Các gói RR được thêm nên được đặt sau gói SR hoặc

gói RR khởi tạo, để dùng mang các bản tin báo nhận

cho các nguồn mà nó nhận được thông tin trong khoảng

85


thời gian kể từ khi gởi bản tin trước. Nếu có quá

nhiều nguồn phát, dẫn đến số lượng các gói RR lớn.

Khi ta dồn tất cả các gói RR này vào một gói RTCP

ghép sẽ gây ra tràn MTU khi lan truyền trên mạng. Khi

đó, trong mỗi khoảng thời gian nhất định, ta chỉ có

thể truyền đi một phần trong số các gói RR này. Việc

truyền đi các tập con này được thực hiện luân phiên

sao cho tất cả mọi nguồn đều có thể nhận được bản

thông báo của mình.

Trong phần tiếp theo, chúng ta sẽ tìm hiểu cấu trúc

của 2 loại bản tin thông báo này, có bao nhiêu thông

tin có thể thêm khi một ứng dụng yêu cầu hồi tiếp,

những bản tin này được sử dụng ra sao.

a. Gói tin RS: Sender Report RTCP Packet

Đây là gói tin RTCP thông báo của người đang truyền

dữ liệu phát đi. Trước tiên ta xét đến cấu trúc của gói

tin RS:

0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3

86


0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

Head

er

V=2 P RC PT=SR=200 Length

SSRC of sender

Send

er

info

r

NTP timestamp, most significant word

NTP timestamp, least significant word

RTP timestamp

sender's packet count

sender's octet count

Repo

rt

Bloc

k 1

SSRC_1 (SSRC of first source)

fraction lost cumulative number of packets lost

extended highest sequence number received

interarrival jitter

last SR (LSR)

delay since last SR (DLSR)

Repo

rt

Bloc

k 2

SSRC_2 (SSRC of second source)

…………………….

profile-specific extensions

Hình 4.3: Cấu trúc bản tin SR-RTCP.

Gói thông báo của bên gởi dữ liệu chứa 3 phần cố

định, có thể được gắn thêm tới 4 phần mở rộng (profile-

specific extension) nếu nó được định nghĩa.

87


Phần đầu: phần tiêu đề, chiếm chiều dài là 8

octets, bao gồm các trường:

- Version (V): 2 bits, dùng để xác định version của

RTP (giá trị V trong các gói dữ liệu RTP và gói

RTCP đều có giá trị giống nhau). Trong trường hợp

này V=2 (giá trị hiện giờ của RTP đang được sử

dụng).

- padding (P): 1 bit. Nếu giá trị này được đặt bằng

1 thì trong gói RTCP này có chứa một số octets mở

rộng, ở phần cuối. Nó không là một phần của thông

tin điều khiển nhưng chiều dài của nó vẫn được

tính vào trường length.

Octet cuối cùng của phần đệm có chứa số octets

nên được bỏ qua, kể cả chinh nó (giá trị này sẽ là

bộ số của 4). Các bits đệm có thể được sử dụng

trong một số thuật toán mã mật với kích thước

block cố định. Trong gói ghép RTCP, bits đệm chỉ

được sử dụng trong các gói con, bởi vì gói ghép sẽ

được mã mật như là một khối. Hơn nữa, nếu phần đệm

được thêm vào gói thì giá trị của nó chỉ có ý

nghĩa cho gói đó mà thôi.

- reception report count (RC): 5 bits

88


Dùng để xác định số các block báo nhận (reception report

blocks) được mang trong gói này. Nếu không có block nào

thì trường này có giá trị 0.

- packet type (PT): 8 bits

Trường này có giá trị bằng 200 để xác định gói RTCP

này là gói SR.

- length: 16 bits

Dùng xác định kích thước gói tin RTCP, đơn vị là 32-

bit, bao gồm cả phần tiêu đề và các phần đệm.

- SSRC: 32 bits Dùng để xác định nguồn đồng bộ

(synchronization source) của gói SR.

Phần thứ 2: mang thông tin về người gởi, có chiều

dài 20 octets, nó có mặt trong tất cả các gói SR. Nó

tóm tắt việc truyền dữ liệu của người gởi này. Các

trường có ý nghĩa như sau:

- NTP timestamp: 64 bits. Dùng xác định giá nhãn

thời gian, khi mà gói này được truyền đi. Nó có

thể được bên nhận dùng để xác định tổng thời gian

truyền từ điểm gởi đến điểm nhận. Người nhận phải

xác định rằng độ chính xác của nhãn thời gian có

thể thấp hơn nhiều so với độ chính xác của nhãn

thời gian NTP. Một hệ thống có thể không có một

đồng hồ chuẩn riêng, khi đó người gởi sẽ sử dụng

89


đồng hồ hệ thống của mình, dựa vào đó để tính toán

ra thời gian NTP tương ứng.????

- RTP timestamp: 32 bits

Nhãn thời gian này giống như NTP timestamp ở trên,

tuy nhiên giá trị ở đây là độ chênh lệch giữa các thời

điểm phát các gói tin. Điều này có thể giúp cho bên

nhận có thể thực hiện đồng bộ các tín hiệu video/audio

thu được.

Chú ý rằng, trong đa số các trường hợp, giá trị

nhãn thời gian RTP của các SR khác nhau không giống

nhau.

Ngoài ra, ta nên tính toán ra thời gian dạng NTP,

bằng cách sử dụng mối quan hệ giữa việc đếm các nhãn

thời gian RTP và thời gian thực được xác định bằng cách

kiểm tra đồng hồ chuẩn tại thời điểm lấy mẫu.

- sender's packet count: 32 bits

Tổng sô các gói dữ liệu RTP đã được gởi bởi người nào

đó kể từ khi bắt đầu phiên đến khi gói SR được sinh

ra. Biến đếm này phải được khởi tạo lại mỗi khi người

gởi thay đổi định danh SSRC.

- Sender's octet count: 32 bits

Tổng số octets của phần tải (payload), không

tính phần tiêu đề hoặc phần đệm, đã được truyền đi kể

90


từ thành viên này tham gia phiên truyền đến khi gói SR

này được tạo ra. Biến đếm này cũng nên được khởi tạo

lại khi người gởi thay đổi định danh. Trường này cũng

có thể được sử dụng để ước tính tốc độ tải trung bình

của một người gởi.

Phần thứ 3: Phần này có thể bỏ trống hoặc có giá

trị thay đổi phụ thuộc vào số các nguồn được lắng nghe

bởi người gởi này, kể từ khi nó goiwr đi bản tin hồi

đáp cuối cùng. Mỗi một khối tin báo nhận mang theo một

số đặc điểm về sự nhận các gói tin RTP tại một thành

viên nhận. Việc truyền đi trạng thái của người nhận

trong khi người nhận đó đang thay đổi định danh SSRC có

thể gây ra xung đột. Những thông tin trạng thái bao

gồm:

- SSRC_n (source identifier): 32 bits. Định danh của

nguồn mà khối tin báo nhận này cần chuyển tới.

- fraction lost: 8 bits

Tỷ lệ gói RTP bị thất lạc từ nguồn gởi SSRC_n kể từ lần

truyền gói SR hoặc gói RR trước. Nó được tính bằng tỷ

số giữa số gói bị mất trên số gói được gởi. Giá trị

được biểu diễn bằng giá trị, tính bằng số nguyên của 8-

bit nhị phân chia cho 256. Chú ý rằng, phía nhận không

thể nói rằng có bao nhiêu gói bị thất lạc trước khi nó

nhận được gói tin cuối cùng (tính tại thời điểm đấy).

91


Do vậy, sẽ không có một bản tin báo nhận được phát đi

cho nguồn SSRC_n , nếu tất cả các gói tin gởi đi từ nó

(kể từ khi phát đi bản thông báo cuối) đều bị thất lạc.

- cumulative number of packets lost: 24 bits

Tổng số các gói dữ liệu RTP từ nguồn SSRC_n đã bị mất,

kể từ khi nhận được gói tin RTP đầu tiên. Con số này

xác định số các gói được nhận trên thực tế hụt bao

nhiêu so với mong muốn. Do con số này tính trong một

thời gian dài, nên các gói đến muộn sẽ không bị coi là

thất lạc, một gói đến muộn cũng bị loại bỏ khi mà đã có

một gói tương tự đến trước.

- extended highest sequence number received: 32 bits

Trong đó, 16 bits thấp chứa số thứ tự cao nhất đã

nhận được trong các gói dữ liệu RTP phát từ nguồn

SSRC_n. 16-bit cao dùng mở rộng cho các số thứ tự

này, được dùng khi số đếm vượt quá 16-bit. Chú ý

rằng, với những người nhận khác nhau, tham gia cùng

một phiên RTP nhưng ở cac thời điểm khác nhau sẽ tạo

ra phần mở rộng khac nhau.

- interarrival jitter: 32 bits

Dùng ước lượng sự khác nhau về mặt thời gian đến của

các gói dữ liệu RTP. Giá trị này được tính toán dựa

trên giá trị của các nhãn thời gian, được biểu diễn

bằng số nguyên không dấu. Giá trị của độ jitter J

92


dùng được xác định nhằm so sánh sự khác nhau D từ

nguồn đến đích giữa 2 gói RTP. Như được chỉ ra ở công

thức dưới đây, điều này tương đương với sự khác nhau

về relative transit time của 2 gói tin.

relative transit time là sự khác nhau giữa nhãn thời gian

được gắn trên gói RTP và đồng hồ của bên nhận khi gói

tin đó đến đích.

Nếu gọi Si là nhãn thời gian gắn trên gói RTP, Ri

là thời gian đến của gói. Khi đó đối với hai gói i và

j ta có D được tính:

D(i,j) = (Rj - Ri) - (Sj - Si) = (Rj - Sj) - (Ri -

Si).

interarrival jitter nên được tính một cách liên tục khi

mỗi gói dữ liệu được nhận từ nguồn SSRC_n. để thực

hiện điều này, sự khác biệt D giữa 1 gói RTP và một

gói RTP trước nó (không cần quan tâm đến số thứ tự)

được tính theo công thức sau:

J(i) = J(i-1) + (|D(i-1,i)| - J(i-1))/16.

- last SR timestamp (LSR): 32 bits

32 bits giữa của 64 bits trong NTP timestamp nhận

được từ gói SR RTCP mới nhất từ nguồn SSRC_n. Nếu

chưa có bản tin SR nào được nhận thì trường này được

gán bằng 0.

- delay since last SR (DLSR): 32 bits

93


Thời gian tạm ngừng được đánh giá trong 1/65536 giây,

giữa quá trình nhận một gói SR cuối nhất từ nguồn

SSRC_n và quá trình gởi đi bản tin hồi đáp. Nếu không

có bản tin SR nào được gởi từ nguồn SSRC_n nào được gởi

thì trường DLSR được gán bằng zero.

Gọi SSRC_r là người nhận đang phát đi bản tin báo

nhận này. SSRC_n có thể tính toán tổng thời gian trễ

lan truyền đến SSRC_r bằng cách ghi lại thời gian A khi

bản tin báo nhận được nhận. Nó tính tổng thời gian

round-trip time (A-LSR) dựa trên nhãn thời gian của gói SR

cuối cùng (LSR), sau đó trừ đi thời gian DLSR ta có

thơì gian trễ lan truyền là: (A - LSR - DLSR). Giá trị

này có thể được dùng để tính gần đúng khoảng cách tới

các người nhận, cho dù thời gian trễ trên các đường

truyền là khác nhau.

Cách tính thời gian trễ lan truyền được minh hoạ

trong hình dưới. Thời gian được biểu diễn ở cả hai

dạng, thập lục phân 32-bit và dạng số thực tương đương.

Dấu “:” dùng để phân cách giữa 16-bit phần nguyên và

16-bit phần thập phân.

94


Hình 4.3: Cách tính thời gian trễ lan truyền.

b. Gói tin RR:

Cấu trúc khung một gói RR như sau:

0

0

0

1

0

2

0

3

0

4

0

5

0

6

0

7

0

8

0

9

1

0

1

1

1

2

1

3

1

4

1

5

1

6

1

7

1

8

1

9

2

0

2

1

2

2

2

3

2

4

2

5

2

6

2

7

2

8

2

9

3

0

3

1

Head

er

V=2 P RC PT=RR=201 Length

SSRC of packet sender

Repo

rt

Bloc

k 1

SSRC_1 (SSRC of first source)

fraction lostcumulative number of packets lost

extended highest sequence number received

interarrival jitter

last SR (LSR)

Repo

rt

Bloc

SSRC_2 (SSRC of second source)

…………………….

profile-specific extensions

95


k 2

Hình 4.5: Cấu trúc bản tin RR-RTCP.

Dạng của bản tin RR cũng gần giống so với SR, ngoại trừ

trường PT của SR=201 (của SR là 200) và 5x4-byte chứa

thông tin người gởi (nhãn thời gian NTP và RTP, số đếm

gói và số octet của người gởi bị loại bỏ). Các trường

còn lại hoàn toàn giống so với gói SR .

Trong trường hợp không có dữ liệu được truyền hay nhận

cần thông báo, một gói tin RR rỗng (có trường RC=0)

phải được đặt ở đầu mỗi gói RTCP ghép.

c. Extending the Sender and Receiver Reports:

Trong một vài trường hợp cụ thể, cần định nghĩa một

số thông tin mở rộng trong các bản tin thông báo của

bên gởi và bên nhận, nếu nó là thông tin được trao

đổi thường xuyên giữa bên gởi và bên nhận. Các trường

hợp này nên được định nghĩa khác so với các gói RTCP

chuẩn, bởi vì nó yêu cầu phần đầu nhỏ hơn:

Cần ít bytes hơn trong gói (không có trường

RTCP header hoặc trường SSRC).

Sẽ đơn giản và nhanh hơn trong quá trình phân

tích, bởi vì trong trường hợp này, ứng dụng đã

được lập trình và luôn biết trước cấu trúc các

trường mở rộng, do đó có thể truy nhập trực

96


tiếp đến từng trường khi nhận được một bản

tin.

Phần mở rộng nếu có, là phần thứ 4 trong gói bản

tin gởi hoặc nhận, nó nằm ở phần cuối sau khối bản tin

báo nhận (reception report blocks).

Nếu thông tin thêm về người gởi được yêu cầu, khi

đó trong các bản tin thông báo của bên gởi, nó sẽ được

thêm vào phía trước của phần mở rộng. Còn đối với bên

nhận, ta không thực hiện được điều này. Nếu các thông

tin về người nhận được thêm, nó sẽ được cấu trúc thành

mảng các block ngang hàng với mảng các block khác trong

bản tin báo nhận, số các block được xác định bởi trường

RC.

d. Analyzing Sender and Receiver Reports :

Một điều chắc chắn rằng các thông tin hồi đáp về

chất lượng nhận thông tin sẽ không chỉ hữu ích cho

người nhận, nó còn dùng cho các người nhận khác và nhà

quản trị mạng (đóng vai trò của thành viên thứ 3).

Người gởi có thể điều chỉnh quá trình truyền tin

của mình thông qua các thông tin hồi đáp. Nếu có lỗi

xảy ra, các người nhận khác có thể dựa vào thông tin

hồi đáp để xác định, cấp độ lỗi là cục bộ, khu vực hay

toàn cục. Nhà quản trị mạng có thể chỉ nhận các gói

97


RTCP (không cần quan tâm đến các gói RTP) để đánh giá

hiệu suất của mạng trong quá trình truyền multicast.

Các số đếm tích luỹ được sử dụng trong cả thông tin

người gởi và các khối thông báo của người nhận, do đó

sự khác biệt được tính giữa 2 bản tin bất kỳ phục vụ

cho phép đo trong thời gian ngắn hoặc dài, được dùng để

khôi phục lại các bản tin bị thất lạc. Sự khác nhau

giữa 2 bản tin cuối cùng nhận được có thể được dùng để

ước tính chất lượng hiện thời của đường truyền.

Việc gắn nhãn thời gian NTP giúp ta có thể tính

được tốc độ truyền tải dựa vào khoảng thời gian chênh

lệch của 2 gói RTCP.

Ta lấy một ví dụ, tính toán tốc độ thất lạc gói trong

khoảng thời gian giữa 2 bản tin (bất kỳ). Sự khác

biệt giữa các số đếm tích luỹ cho ta biết được số gói

đã bị thất lạc. Giá trị của số thứ tự trong gói tin

cuối cùng nhận được giúp ta biết được số gói tin cần

nhận được trong khoảng thời gian giữa 2 bản tin. Tỷ

lệ thất lạc gói tin trongkhoảng thời gian này chính

là tỷ số của 2 giá trị trên. Nếu 2 bản tin là liên

tiếp thì tỷ số này sẽ bằng giá trị của fraction lost

field. Ta cũng có thể tính tỷ lệ thất lạc gói tin

trong 1s bằng cách chia tỷ số này cho khoảng thời

gian chênh lệch giữa 2 nhãn thời gian NTP (đơn vị

98


tính bằng s). Điều này rất quan trọng, bởi các giá

trị thống kê được tính trong thời gian dài luôn có ý

nghĩa hơn các giá trị tức thời. Việc 200 gói thất lạc

trong số 1000 gói có ý nghĩa hơn nhiều so với việc 1

gói thất lạc trong 5 gói. Bởi con số thứ nhất có thể

nói lên đặc tính của mạng, còn con số thứ 2 chỉ nói

lên một giá trị tức thời, không thể nói là mạng đó

tốt hay dở.

Từ những thông tin của người gởi, nhà quản trị mạng

có thể tính toán tốc độ tải dữ liệu trung bình và tốc

độ gói trung bình trong một khoảng thời gian mà không

cần phải phân tích bất kỳ gói dữ liệu RTP nào. Dựa vào

hai tỷ số này ta có thể biết được kích thước tải trung

bình của gói RTP. Nếu ta giả sử rằng việc thất lạc gói

không phụ thuộc vào kích thước của tải, khi đó số gói

tin nhận được bởi 1 thành viên nhân với kích thước tải

trung bình cho ta biết được thông lượng khả dụng của

thành viên đó.

Như vậy ta thấy, việc thêm biến đếm tích luỹ cho

phép ta tính toán sự mất gói trong khoảng thời gian

dài. Điều này trở lên rất có ý nghĩa trong trường hợp

có nhiều thành viên tham gia 1 phiên RTP. Khi đó các

thông tin trạng thái sẽ không thể được nhận một cách

liên tục từ tất cả các nguồn.

99


Trường interarrival jitter cung cấp cho ta phép đo trong

thời gian ngắn sự tắc nghẽn trên mạng. Packet loss cho

phép ta theo dõi sự tắc nghẽn trên mạng trong thời gian

dài, trong khi đó jitter giúp ta theo dõi sự tăc nghẽn

tức thời trên mạng.

Để có thể so sánh giữa các thành viên khác nhau,

việc tính toán jitter phải được thực hiện theo cùng một

công thức cho mọi thành viên. jitter được tính toán dựa

trên nhãn thời gian RTP, ghi lại thời điểm mà tại đó

gói dữ liệu được lấy mẫu lần đầu. Do vậy bất kỳ sự biến

đổi thời gian trễ nào trong quá trình lấy mẫu và trong

quá trình truyền lan gói dữ liệu đều được tính vào

jitter. Sự biến đổi trong thời gian trễ sẽ dẫn đến sự

“mấp mô” của tín hiệu audio nhận được. Điều này cũng

xảy ra trong quá trình mã hoá tín hiệu video. Nhãn thời

gian sẽ được gắn giống nhau cho mọi gói tin chứa cùng 1

khung hình, tuy nhiên các gói dữ liệu này lại không

được truyền đi đồng thời mà được gởi đi lần lượt, điều

này sẽ làm giảm độ chính xác của việc tính toán jitter

với mục đích phân tích hoạt động của mạng. Nhưng nó sẽ

hợp lý nếu ta giả thiết rằng quá trình xảy ra hoàn toàn

tương tự tại bộ đệm của người nhận. Khi đó hằng số thời

gian trễ do việc chờ đến lượt truyền sẽ bị loại trừ. Vì

100


vậy chúng ta có thể kiểm soát được jitter xảy ra trong

quá trình lan truyền trên mạng.

4.7 GÓI TIN MÔ TẢ CÁC THÔNG TIN CỦA NGUỒN:

(SDES: Source Description RTCP Packet)

Cấu trúc bản tin như hình vẽ:0

0

0

1

0

2

0

3

0

4

0

5

0

6

0

7

0

8

0

9

1

0

1

1

1

2

1

3

1

4

1

5

1

6

1

7

1

8

1

9

2

0

2

1

2

2

2

3

2

4

2

5

2

6

2

7

2

8

2

9

3

0

3

1

Heade

r

V=2 P RC PT=SDES=202 length

SSRC of packet sender

Chunk

1

SSRC/CSRC_1

SDES items

..........

Chunk

2

SSRC/CSRC_2

SDES items

..........Hình 4.6: Cấu trúc gói tin SDES-RTCP

Gói SDES bao gồm phần tiêu đề, kèm theo là các đoạn

chứa các thông tin về các nguồn SSRC/CSRC _i (ở đây ta

gọi tắt là các đoạn SSRC/CSRC). Trong một gói SDES có

thể có không hoặc nhiều đoạn thông tin này. Các thông

tin trong từng đoạn riêng lẻ là hoàn toàn độc lập.

- version (V), padding (P), length: hoàn toàn

tương tự như trong các gói RTCP khác.

101


- packet type (PT): 8 bits. Có giá trị bằng 202,

dùng xác định đây là một gói SDES RTCP.

- source count (SC): 5 bits. Xác định số các đoạn

SSRC/CSRC được chứa trong gói SDES này. Trường này

có thể nhận giá trị nhỏ nhất bằng 0 khi không có

thông tin về một nguồn nào được mô tả, tuy nhiên

điều này thường không xảy ra.

Mỗi đoạn SSRC/CSRC bao gồm 1 phần định danh nguồn

SSRC/CSRC, tiếp theo là một loạt các thông tin về nguồn

SSRC/CSRC đó. Mỗi đoạn sẽ bắt đầu bằng 1phần 32-bit.

Mỗi phần thông tin (SDES item) sẽ có trường định

kiểu 8-bit, 8-bit dùng xác định chiều dài của phần

thông tin (không chứa 2-byte đầu tiên này). Tiếp theo

là phần thông tin cụ thể (text). Chú ý rằng phần text

không thể vượt quá 255-byte, nhưng điều này hoàn toàn

phù hợp với giới hạn của băng thông RTCP.

Phần text được mã hoá theo tiêu chuẩn mã hoá UTF-8

được đưa ra trong bản RFC-2279. Chuẩn này hoàn toàn đáp

ứng được cá yêu cầu của chuẩn ASCII của Mỹ.

00 010

2

0

3

0

4

0

5

0

6

0

7

0

8

0

9

1

0

1

1

1

2

1

3

1

4

1

5

1

6

1

7

1

8

1

9

2

0

2

1

2

2

2

3

2

4

2

5

2

6

2

7

2

8

2

9

3

031…

Type field length textHình 4.7: Cấu trúc SDES item.

102


Mỗi hệ thống đầu cuối sẽ phát đi gói SDES mang

thông tin định danh nguồn của mình (tương tự như giá

trị SSRC trong phần tiêu đề của gói RTP). Sau đó bộ

trộn (mixer) sẽ gộp các thông tin này lại từ các nguồn

phân tán, phân chúng thành từng đoạn trong một gói SDES

chung và gởi đi. Nếu có nhiều hơn 31 nguồn thì các

thông tin sẽ được chứa trong nhiều gói SDES chung.

Chung ta sẽ nói cụ thể hơn trong phần Mixer.

Bây giờ ta sẽ định nghĩa từng loại thông tin mang

trong gói SDES. Trong đó chỉ có CNAME là bắt buộc. các

thông tin còn lại có thể có hay không tuỳ thuộc vào

từng ứng dụng cụ thể. Các loại được thông tin nêu ra ở

đây đều phổ biến, đã được đăng ký với IANA [] 15.

a. CNAME: Canonical End-Point Identifier:

Đây là một trường thông tin bắt buộc trong gói SDES,

dùng để nhận dạng một đầu cuối.

00 010

2

0

3

0

4

0

5

0

6

0

7

0

8

0

9

1

0

1

1

1

2

1

3

1

4

1

5

1

6

1

7

1

8

1

9

2

0

2

1

2

2

2

3

2

4

2

5

2

6

2

7

2

8

2

9

3

031…

CNAME=1 length user and domain name Hình 4.8: Cấu trúc CNAME-SDES .

CNAME có các thuộc tính sau:

103


- Một định danh SSRC được phân phối một cách ngẫu

nhiên và có thể thay đổi trong một phiên RTP,

khi phát hiện sự xung đột, hoặc khi chương

trình khởi tạo lại. Do vậy, CNAME được sử dụng

để liên kết một định danh SSRC với một định

danh không đổi dành cho một nguồn xác định.

- Cũng giống như SSRC, giá trị của CNAME của mỗi

thành viên phải là duy nhất trong một phiên

RTP.

- Giá trị của CNAME được dùng cố định cho một

thành viên nào đó. Điều này giúp ta có thể kết

nối giữa các luồng dữ liệu khác nhau được gởi

đi từ cùng một thành viên nhưng sử dụng 2 phiên

RTP riêng. Ví dụ, khi mà một thành viên gởi

đồng thời tín hiệu video và tín hiệu audio với

qua 2 cặp cổng UDP khác nhau.

- Để thuận tiện cho nhà quản trị mạng trong việc

định vị nguồn, CNAME nên tương ứng với với sự

xác định một cá nhân nào đó

Vì vậy, CNAME sẽ được nhận theo một thuật toán nào

đó, không được nhập vào một cách tuỳ ý bởi người dùng.

Để thoả mãn các yêu cầu trên, ta sẽ đưa ra một định

dạng của CNAME. Tuy nhiên định dạng này không hề có

104


tính bắt buộc, nó có thể được định nghĩa khác, tuỳ vào

từng trường hợp cụ thể.

CNAME xác định dựa trên "user@host" (Ví dụ:

[email protected]

, hoặc “host” trong trường hợp “user name” không

được xác định trên hệ thống đơn người dùng. Việc xác

định “host“ là hoàn toàn đơn trị. Tuy nhiên trong

trường hợp, một “host” có thể đồng thời tạo ra nhiều

nguồn, cú pháp này không giúp ta phân biệt được từng

nguồn cụ thể trong số đó. Việc này sẽ được giải quyết ở

lớp ứng dụng, ta sẽ không đề cập đến ở đây.

b. NAME: User Name

Cấu trúc khung:

00 010

2

0

3

0

4

0

5

0

6

0

7

0

8

0

9

1

0

1

1

1

2

1

3

1

4

1

5

1

6

1

7

1

8

1

9

2

0

2

1

2

2

2

3

2

4

2

5

2

6

2

7

2

8

2

9

3

031…

NAME=2 length common name of source Hình 4.9: Cấu trúc NAME-SDES .

Phần này chứa là tên thật, được dùng để mô tả

nguồn, ví dụ: “Nguyễn Văn A”. Nó có thể được đặt tuỳ ý

do người dùng. Trong một ứng dụng cụ thể, ví dụ như hội

thảo trên mạng, tên này sẽ là nick mà 1người dùng để

hiển thị trên danh sách thành viên. Chính vì vậy mà nó

có thể được gởi đi thường xuyên (đứng thứ 2 sau CNAME).

105


Chú ý:

- Giá trị của NAME sẽ được duy trì không đổi trong ít

nhất một chu kỳ.

- Nó sẽ không bắt buộc là duy nhất trong một các thành

viên tham gia.

c. EMAIL: Electronic Mail Address

Cấu trúc dữ liệu:

00 010

2

0

3

0

4

0

5

0

6

0

7

0

8

0

9

1

0

1

1

1

2

1

3

1

4

1

5

1

6

1

7

1

8

1

9

2

0

2

1

2

2

2

3

2

4

2

5

2

6

2

7

2

8

2

9

3

031…

EMAIL=3 length email address of source Hình 4.10: Cấu trúc EMAIL-SDES .

Địa chỉ Email được định dạng theo chuẩn RFC 2822.

Ví dụ: "[email protected]".

d. PHONE: Phone Number SDES Item

00 010

2

0

3

0

4

0

5

0

6

0

7

0

8

0

9

1

0

1

1

1

2

1

3

1

4

1

5

1

6

1

7

1

8

1

9

2

0

2

1

2

2

2

3

2

4

2

5

2

6

2

7

2

8

2

9

3

031…

PHONE=4 length phone number of source Hình 4.11: Cấu trúc PHONE-SDES .

Số điện thoại được định dạng với dấu “+” thay cho mã

truy nhập quốc tế. Ví dụ: "+1 908 555 1212" được dùng

cho một số của nước Mỹ.

e.LOC: Geographic User Location SDES Item00 01 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 31…

106


2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0

LOC=5 length geographic location of site Hình 4.12: Cấu trúc LOC-SDES.

Giá trị này có mức độ chi tiết khác nhau phụ thuộc

vào từng ứng dụng. Định dạng của nó phụ thuộc vào sự

cài đặt cụ thể.

f. TOOL: Application or Tool Name SDES Item

00 010

2

0

3

0

4

0

5

0

6

0

7

0

8

0

9

1

0

1

1

1

2

1

3

1

4

1

5

1

6

1

7

1

8

1

9

2

0

2

1

2

2

2

3

2

4

2

5

2

6

2

7

2

8

2

9

3

031…

TOOL=6 length name/version of source

applicationHình 4.13: Cấu trúc TOOL-SDES.

Chuỗi ký tự có thể cho biết tên và đôi khi cho biết cả

verion của ứng dụng được dùng để tạo ra luồng dữ liệu

RTP.

Ví dụ: "videotool 1.2"

Thông tin này đôi khi sẽ rất hữu ích cho mục đích “gỡ

rối” (debugging).

g. NOTE: Notice/Status SDES Item

00 010

2

0

3

0

4

0

5

0

6

0

7

0

8

0

9

1

0

1

1

1

2

1

3

1

4

1

5

1

6

1

7

1

8

1

9

2

0

2

1

2

2

2

3

2

4

2

5

2

6

2

7

2

8

2

9

3

031…

NOTE=7 length note about the sourceHình 4.14: Cấu trúc NOTE-SDES.

107


Trường chú thích này được dùng với mục đích gởi các

bản tin ngắn, mô tả trạng thái hiện tại của một nguồn.

Ví dụ: “busy”.

Trong một cuộc thảo luận chuyên đề, trường này có

thể dùng để truyền tải tiêu đề của cuộc thảo luận.

Trường này nên được sử dụng để mang những thông tin đặc

biệt, không nên được phát thường xuyên bởi tất cả các

thành viên. Bởi vì điều đó làm giảm tốc độ nhận các bản

tin hồi đáp và các gói chứa CNAME.

Nếu NOTE trở lên quan trọng, cần được hiển thị liên

tục, khi đó ta có thể giảm tốc độ của các phần thông

tin khác (không được giảm tốc độ của CNAME). Do vậy

NOTE có thể sử dụng một phần cố định của băng thông

RTCP. Khi muốn ngừng kích hoạt, NOTE chứa chuỗi rỗng sẽ

được gởi đi vài lần để báo hiệu cho phía nhận. Tuy

nhiên, nếu không nhận được thông tin NOTE trong một

thời gian nào đó, bên nhận cũng sẽ tự mặc định rằng nó

đã được ngừng kích hoạt (thời gian này khoảng 20-30 lần

chu kỳ gởi RTCP).

h. PRIV: Private Extensions SDES Item

00 010

2

0

3

0

4

0

5

0

6

0

7

0

8

0

9

1

0

1

1

1

2

1

3

1

4

1

5

1

6

1

7

1

8

1

9

2

0

2

1

2

223 24

2

5

2

6

2

7

2

8

2

9

3

031…

PRIV=8 length prefix lengthprefix

string...

value

string ...

108


Hình 4.15: Cấu trúc PRIV-SDES.

Phần này được dùng cho các SDES mở rộng. Nó chứa

thông tin về chiều dài của 2 chuỗi trong 2 trường kích

thước: length, prefix length, mỗi trường có độ dài 8-

bit.

Trường “prefix string” định nghĩa loại của PRI,

dùng chỉ dẫn cho phía nhận.Trường “value string” sẽ

chứa những phần thông tin mở rộng khác (extended

items).

Chú ý:

-Do trường prefix có độ dài 8-bit, nên tổng cộng

chiều dài của phần thông tin thêm (“prefix string”

+“value string”) phải nhỏ hơn 256 octets. Tuy điều

này có thể không làm hài lòng một số ứng dụng, tuy

nhiên với kích thước như vậy là đúng mức để băng

thông dành cho RTCP không bị quá tải.

-Phần tiền tố của PRIV – SDES không cần phải khai

báo định dạng với IANA. Khi một định dạng nào của

PRIV được phổ dụng thì nó sẽ được đưa lên phần dùng

chung (như NAME, LOC……). Lúc đó nó sẽ cần đăng ký với

IANA. Cơ chế đơn giản hoá này giúp ta tăng hiệu quả

truyền tải.

4.8. Gói BYE:

109


Gói RTCP này chỉ ra 1 hay nhiều nguồn SSRC sẽ rờikhỏi trạng thái kích hoạt. Bây giờ chúng ta sẽ tìm hiểucấu trúc của gói BYE.

00

01

020304050607080910111213141516171819202122232425262728293031

V=2 P RC PT=BYE=203 Length

SSRC/CSRC. . . . . . .

opt length reason for leavingHình 4.16: Cấu trúc gói RTCP BYTE.

- Các trường version (V), padding (P), length:

hoàn toàn giống như các trường tương ứng trong gói

SR.


Trường này có giá trị bằng 203, để chỉ định đây là

gói BYE.

- source count (SC): 5 bits

Dùng thông báo, số định danh SSRC/CSRC được chứa

trong gói BYE. Trường hợp nhỏ nhất SC có thể bằng

0, tuy nhiên đây là trường hợp không xảy ra.

Việc gởi gói BYE được thực hiện như đã trình bầy

ở phần trước.

Khi mộ gói BYE được nhận bởi bộ trộn (mixer), bộ

trộn sẽ chuyển tiếp gói BYE đến trực tiếp, không

làm thay đổi trường SSRC/CSRC có sẵn. Khi một bộ

110


trộn muốn tắt, nó sẽ gởi đi một gói BYE trong đó

liệt kê toàn bộ các nguồn mà nó quản lý, cùng địa

chỉ SSRC của chính nó.

Ngoài ra, gói BYE còn có 1 trường 8-bit, theo sau phần

danh sách SSRC. Trường này chứa số octets được chứa

trong phần chú thích. Phần chú thích chứa một chuỗi ký

tự dạng text được mã hoá theo chuẩn UTF-8 []. Nó dùng

để giải thích lý do rời bỏ của nguồn, như: “camera

malfunction”, “RTP loop detected”…. Nếu chuỗi này điển

đầy hàng 32-bit tiếp theo, nó không cần kết thúc với

xâu rỗng. Nếu không, gói BYE sẽ phải thêm các byte rỗng

cho đủ số nguyên lần 32-bit. Việc thêm này sẽ được báo

hiệu bởi bit P trong phần tiêu đề RTCP.

4.9. GÓI APP: APPLICATION-DEFINED RTCP PACKET

Cấu trúc gói RTCP-APP:

00

01

020304050607080910111213141516171819202122232425262728293031

V=2 P subtype PT=APP=204 Length

SSRC/CSRCname (ASCII)application-dependent data

Hình 4.17: Cấu trúc gói RTCP-APP..Gói APP được dùng cho những ứng dụng mới, đang thử

nghiệm hoặc những chức năng mới đang được phát triển.

111


Bởi nó hỗ trợ phần định kiểu tự do, không cần đăng ký

giá trị với IANA. Một gói APP khi không xác định được

tên sẽ được mặc định bỏ qua. Nếu sau thời gian thử

nghiệm, loại gói này được dùng rộng rãi, nó sẽ được

đăng ký với IANA, loại bỏ 2 trường “subtype” và “name”,

trở thành một gói RTCP loại mới.

- Các trường version (V), padding (P), length: giống

như các trường tương ứng trong gói SR.

- subtype: 5 bits

- Ta có thể sử kiểu phụ để định nghĩa một tập các gói

APP dưới một cái tên duy nhất, hoặc cho bất kỳ loại dữ

liệu phụ thuộc ứng dụng.


- Trường này mang giá trị 204, để chỉ định đây là gói

APP-RTCP.

- name: 4 octets

- Tên này được dùng để phân chia các tập gói APP thành

từng nhóm khác nhau để ứng dụng có thể nhận biết được.

Tên này có thể lấy giá trị tuỳ ý do người lập trình đặt

ra, tuy nhiên theo khuyến nghị, nó nên đặt dựa trên

thực thể mà nó miêu tả. Tên này sẽ được biểu diễn dưới

4 ký tự mã ASCII, có phân biệt chữ hoa, chữ thường.

- Application-dependent data: trường này có độ dài biến

đổi, có giá trị là số nguyên lần 32-bit. Đây là 1

112


trường không bắt buộc trong gói APP. Nó được mô tả phụ

thuộc từng ứng dụng.

113


CHƯƠNG V: CÁC BỘ RTP TRANSLATORS VÀ RTP MIXERS

Trong các thiết bị đầu cuối RTP, chúng ta có khái niệm"translators" và "mixers". Đây là một trong những thành phầnrất quan trọng trong hệ thống RTP. Chúng được coi như làcác hệ thống trung gian ở hoạt động ở lớp tương đương vớiRTP. Mặc dù sự có mặt của 2 thiết bị này làm cho hệ thống trởlên phức tạp hơn nhiều, nhưng đây là các chức năng thật sựcần thiết cho hệ thống RTP. Nó đóng vai trò rất quan trọngtrong các hệ thống truyền multicast, trong các hệ thống cómột phần được bảo vệ bởi fire wall, trong hệ thống có mộtphần băng thông hạn hẹp. Các bộ "translators" và "mixers" sẽgiúp cho các hệ thống này giữ nguyên khi áp dụng giao thứcRTP.

5.1. KHÁI NIỆM CHUNG:

Một bộ translator/mixer được nối với một hay nhiều

“clouds” ở tầng giao vận. Thông thường, mỗi “cloud”

được định nghĩa bởi một mạng chung và một giao thức

giao vận (ví dụ IP/UDP) cộng với địa chỉ multicast và

một cổng đích ở tầng giao vận, hoặc một cặp các địa chỉ

unicast và các cổng tương ứng.

Một hệ thống có thể được dùng như một bộ

“translator” hoặc “mixer” cho một tập các phiên RTP,

tuy nhiên chúng nên được phân thành từng thực thể

riêng. Để tránh việc xảy ra các vòng lặp khi ta cài đặt

các bộ “mixer” hoặc “translator”, các qui tắc sau cần

được đảm bảo:

114


- Các “cloud” được nối với nhau qua các bộ “mixer”

và “translator”, để tham dự vào một phiên RTP, phải

khác nhau ít nhất một trong những tham số sau:

Protocol, address, port, hoặc phải hoàn toàn tách

biệt với nhau ở lớp mạng.

- Xuất phát từ yêu cầu của điều một, để tránh sự

lặp vòng thì không được sử dụng nhiều bộ

“translator” hoặc “mixer” mắc song song, trừ khi

các ngồn được chuyển tiếp tại đầu ra được phân

thành từng nhóm.

Tương tự, mọi hệ thống cuối RTP đều có thể trao đổi

thông tin với một hoặc nhiều bộ “translator” hoặc

“mixer” chia sẽ cùng một miền SSRC, do vậy các định

danh SSRC của mọi đầu cuối phải là đơn nhất trên toàn

hệ thống. Phần sau ta sẽ đề cập cụ thể hơn về cơ chế

đảm bảo điều này.

Thực tế có rất nhiều loại “translator” và “mixer”

được thiết kế cho những mục đích, những ứng dụng khác

nhau. Ví dụ như để thêm hay loại bỏ mã bảo mật, thay

đổi mã hoá dữ liệu, Chuyền đổi giữa địa chỉ Mutilcast

và nhóm các địa chỉ Unicast. Sự khác nhau cơ bản giữa

“translator” và “mixer” là “translator” thì chuyển tiếp

các luồng dữ liệu từ các nguồn khác nhau một cách riêng

115


rẽ, còn “mixer” thì kết hợp chúng lại trong một luống

mới.

Translator: Chuyển tiếp các gói RTP mà không thay đổi

định danh SSRC của chúng. Điều này giúp cho phía nhận

có thể xác định được từng nguồn gởi riêng biệt, cho dù

chúng được chuyển qua cùng một “translator”. Một số

loại “translator” sẽ chuyển tiếp dữ liệu một cách

nguyên vẹn, nhưng một số loại khác có thể thay đổi dạng

mã hoá dữ liệu của phần tải và nhãn thời gian ngắn kèm

của gói RTP.

Nếu nhiều loại dữ liệu (hình ảnh và âm thanh) được

ghép lại hoặc trường hợp ngược lại, thì bộ “translator”

sẽ phải tạo một số thứ tự mới cho các gói đầu ra. Ngoài

ra sự thất lạc các gói gói tin đầu vào cũng có thể tạo

lên sự không liên tục của các số thứ tại đầu ra. Phía

nhận sẽ hoàn toàn không hề phát hiện ra được sự có mặt

của “translator” trừ khi sử dụng một số phương tiện đặc

biệt, bởi vì kiểu định dạng tải, địa chỉ giao vận của

các gói tin không hề bị thay đổi gì so với nguồn gốc.

Mixer: Thiết bị này sẽ nhận luồng các gói dữ liệu RTP

từ một hoặc nhiều nguồn, có thể thay đổi định dạng tải,

kết hợp chúng theo một cách nào đó, sau đó truyền chúng

đi trong một luồng kết hợp. Do nhãn thời gian gắn trên

các nguồn tới khác nhau là không đồng bộ, “Mixer” sẽ

116


điều chỉnh lại nhãn thời gian của các nguồn và tạo ra

một nhãn thời gian riêng cho luồng ra kết hợp. Vì vậy

một “Mixer” có vai trò như mọt nguồn đồng bộ SC. Tất cả

các gói dữ liệu được chuyển tiếp bởi bộ “Mixer” đều

được đánh dấu với định danh SSRC của bộ “Mixer”. Để có

thể duy trì định danh SSRC của từng nguồn phân tán

trong một gói tổng hợp, bộ “Mixer” phải chèn các giá

trị SSRC của chúng vào danh sách CSRC ngay sau phần

tiêu đề RTP của gói dữ liệu. Nếu không chèn thêm danh

sách này thì cũng được trong một số ứng dụng cụ thể.

Tuy nhiên việc này là hoàn toàn không nên bởi việc

không phát hiện được nguồn gởi gốc có thể gây ra việc

các gói tin giống nhau không được phân biệt.

Một bộ “Mixer” cũng có vai trò của một nguồn đồng bộ

nên trong một số gói tin ta cũng nên chèn thêm giá trị

SSRC của “Mixer” vào danh sách CSRC.

Trong một số trường hợp bộ “Mixer” có ưu thế hơn hẳn

so với bộ “translator”. Ví dụ, trong những ứng dụng

audio, dải thông đầu ra bị giới hạn chỉ phục vụ cho một

nguồn, mà trong khi đó lại có rất nhiều nguồn đầu vào.

Hay trong trường hợp đầu ra có băng thông hẹp, không

thể tải hết các thông tin tại đầu vào.

Tuy nhiên “Mixer” cũng có một số hạn chế. Đó là việc

bên nhận ở phía sau bộ “Mixer” sẽ không thể điều khiển

117


các nguồn phát phía trước “Mixer”, trừ khi bộ “Mixer”

được cài đặt thêm một số cơ chế điều khiển từ xa. Việc

tái tạo lại các thông tin đồng bộ của bộ “Mixer” làm

cho bên nhận không thể thực hiện đồng bộ nội giữa các

thành phần tín hiệu (âm thanh/hình ảnh) của cùng một

nguồn phát. Việc này phải đo các bộ “multi-media Mixer”

thực hiện.

Hình 5.1 : Mô hình mạng với các bộ traslator và mixer

Hình này minh hoạ tác động của “mixer” và “translator” tới

giá trị của SSRC và CSRC. Chú ý rằng ký hiệu "M1: 48(1,17)"

dùng để chỉ, gói tin được phát từ “mixer” M1có giá trị SSRC

là 48 (đây là giá trị ngẫu nhiên), kèm theo 2 định danh

118


trong danh sách SCRC là 1, 17 (2 giá trị này được lấy từ

phần định danh SSRC của 2 gói tin từ E1, E2.

5.2. HOẠT ĐỘNG CỦA BỘ TRANSLATORS:

Khi gói dữ liệu RTP được chuyển tiếp qua các bộ

“mixer” và “translator”, nó có thể bị sửa đổi, khi đó

ta phải co xử lý đối với các gói RTCP. Trong nhiều

trường hợp, chúng tách các gói ghép RTCP được nhận từ

các hệ thống đầu cuối, tập hợp các thông tin SDES và

sửa đổi các gói SR và RR. Sự truyền lại các thông tin

này có thể gây ra “trigger” do khoảng thời điểm đến của

các gói tin hoặc do bản thân bộ “mixer” và “translator”

gây ra.

Hình 5.2: Hoạt động của Translator.

Nếu bộ “translator” chỉ thực hiện chuyển đổi giữa

địa chỉ multicast và địa chỉ Unicast, không sửa đổi gì

119


các gói dữ liệu thì đối với các gói RTCP nó cũng không

phải sửa đổi. Khi một bộ “translator” thay đổi dạng của

phần tải RTP theo một cách nào đó thì nó cũng phải thay

đổi các thông tin trong gói SR và RR một cách tương

ứng. Để có thể đảm bảo các gói này vẫn phản ánh được

các thuộc tính của gói RTP được gởi đi (đối với gói

SR), chất lượng nhận các gói RTP (đối với gói RR). Các

gói RTCP không chỉ được chuyển tiếp một cách đơn thuần.

Chú ý: thường thì “translator” không kết hợp các

gói SR và RR từ các nguồn khác vào một gói chung, bởi

vì như vậy sẽ làm giảm độ chính xác của việc đo thời

gian trễ lan truyền dựa trên các trường LSR và DLSR.

Bây giờ ta sẽ tìm hiểu cụ thể tác động của

“translator” tới các loại gói tin RTCP:

a. SR (thông tin người gởi): Một bộ “translator” sẽ

không tạo ra gói SR của riêng mình, nó chỉ nhận SR

từ một “cloud” rồi chuyển tiếp đến các “cloud”

khác. Trong đó trường SSRC được giữ nguyên, nhưng

các trường mô tả thông tin người gởi có thể bị

thay đổi nếu cần thiết.

khi bộ “translator” thay đổi cách mã hoá dữ liệu

thì nó phải thay đổi giá trị của trường đếm số

byte của người gởi ( sender's byte count).

120


Nếu bộ “translator” thực hiện việc ghép nhiều gói

dữ liệu đầu vào thành một gói dữ liệu đầu ra, nó

sẽ phải thay đổi trường đếm số gói mà người gởi đã

phát đi (sender's packet count).

Nếu “translator” thay đổi nhãn thời gian trong gói

RTP thì nó cũng phải thay đổi trường "RTP

timestamp" trong gói SR.

a. Các khối thông báo SR/RR:

Một bộ “translator” nhận một bản tin báo nhận từ

một “cloud” chuyển tiếp đến các “cloud” khác, với

trường SSRC không đổi. Chú ý rằng, luồng các bản tin

báo nhận có chiều ngược với chiều của luồng dữ liệu

RTP.

Nếu trước đây “translator” kết hợp nhiều gói RTP

đầu vào thành một gói RTP ghép tại đầu ra và đã

thực hiện việc thay đổi số thứ tự của gói, thì nó

phải thực hiện chuyển đổi ngược tương ứng với các

trường “packet loss” và "extended last sequence

number”. Điều này có thể là phức tạp.

Trong một số trường hợp, không có cách nào hiệu

quả để chuyển đổi các bản tin báo nhận,

“translator”sẽ tổng hợp các bản tin báo nhận của

từng đầu cuối rồi tạo ra một bản báo nhận mới để

chuyển đi.

121


Một “translator” không bắt buộc có một định danh

SSRC riêng, tuy nhiên cũng nên có một giá trị SSRC dùng

với mục đích gởi đi các thông báo nó đã nhận được những

gì. Các bản tin này sẽ được gởi tới tất cả các “cloud”

kết nối với “translator” đó. Mỗi “cloud” sẽ nhận các

bản tin này rồi truyền multicast các thành viên của nó.

c. SDES: Thường thì “translator” sẽ chuyển tiếp các

gói tin SDES từ một “cloud” đến các “cloud” khác

mà không hề thay đổi gì. Trong trường hợp băng

thông hạn chế “translator” sẽ chặn các gói SDES.

Các gói CNAME phải luôn được chuyển tiếp vì nó

được dùng để xác định xung đột SSRC trên mạng.

Khi một bộ “translator” có tạo ra các gói RR của

riêng mình thì phải gởi đi các thông tin về SDES,

CNAME của nó.

d. BYE:

“translator” chuyển tiếp gói BYE, không hề thay đổi

gì. khi một bộ “translator” dừng việc chuyển tiếp các

gói tin (RTP/RCTP) thì nó sẽ gởi gói BYE đến tất cả

các “cloud” mà nó kết nối. Trong gói BYE này sẽ chứa

danh sách tất cả các SSRC mà nó đã từng chuyển tiếp

đến “cloud” đó, bao gồm cả SSRC của chính nó (nếu như

nó cũng đã gởi đi các bản thông báo của riêng mình).

122


e. APP: Gói này được chuyển tiếp hoàn toàn không thay

đổi gì.

5.3. HOẠT ĐỘNG CỦA MIXERS:

Do “mixer” luôn tạo ra các luồng dữ liệu mới của riêng

mình, nó sẽ không chuyển thẳng các gói SR hay RR mà nó

sẽ tái tạo lại các thông tin rồi mới chuyển đi.

Hình 5.3: Hoạt động của Mixer.

Bây giờ ta sẽ đi tìm hiểu, cách xử lý của mixer với từng

loại gói tin RTCP.

a. SR (sender information):

Bộ “mixer” không chuyển thẳng các bản tin SR bởi vì

một số đặc tính của nguồn đều bị thay đổi khi qua bộ

“mixer”. Bộ “mixer” sẽ đóng vai trò như một nguồn đồng

bộ, nó sẽ tạo ra gói SR riêng với thông tin thông báo

cho luồng dữ liệu đã được trộn tại đầu ra.

b. SR/RR (reception report blocks):

123


Tương tự như trên, bộ “mixer” cũng sẽ tạo ra bản tin

báo nhận mới tương ứng với các nguồn gởi.

Trong bản tin báo nhận mà bộ “mixer” gởi đi nguồn

nhận sẽ không được xác định dựa trên trường SSRC mà sẽ

được xác định dựa trên danh sách CSRC. Do vậy các bản

tin báo nhận cho một nguồn ở trong một “cloud” nào thì

chỉ được gởi đến “cloud” đó, không được gởi đến các

“cloud” khác. Cũng không được chuyển tiếp một bản tin

báo nhận từ một “cloud” đến một “cloud” khác.

c. SDES:

Bộ “mixer” thường nhận các gói SDES từ một “cloud”

chuyển tiếp đến các “cloud” khác mà không thay đổi gì.

Tuy nhiên trong trường hợp mạng có băng thông hạn chế,

“mixer” cũng giống như “translator” sẽ hạn chế việc

truyền đi các gói SDES không mang CNAME. Các gói SDES-

CNAME được truyền đi để sử dụng cho việc phát hiện xung

đột SSRC trên mạng.

Hình 5.4: khả năng phát hiện vòng lặp hoặc xung đột của mixer.

124


Chú ý: một định danh SSRC trong danh sách CSRC được

tạo bởi “mixer” có thể xung đột với một giá rị SSRC

được phát bởi một hệ thống cuối.

Ngoài ra bộ “mixer” phải gởi các gói SDES-CNAME của

nó tới các “cloud” mà nó gởi tới các gói SR, RR.

Khi các bộ “mixer” không chuyển tiếp thẳng các gói

SR, RR, chúng sẽ phân tích các gói SDES từ một gói ghép

RTCP, tối thiểu hoá phần tiêu đề, sau đó có thể ghép

các đoạn trong một gói SDES đơn. Các gói SDES này sẽ

được xếp vào trong các bản tin SR hoặc RR được phát đi

bởi “mixer”. Vì thế mà tốc độ gói RTCP có thể khác nhau

tại hai phía của một bộ “mixer”.

Một bộ “mixer” tổng hợp các gói SDES sẽ sử dụng băng

thông RTCP nhiều hơn một nguồn đơn bởi cac gói SDES

ghép có kích thước lớn hơn. Điều này là hoàn toàn hợp

lý bởi một bộ “mixer” đại diện cho nhiều nguồn đơn.

Đối với một bộ “mixer” sử dụng cơ chế chuyển thẳng

các gói SDES mà nó nhận được cũng có tốc độ phát các

gói RTCP lớn hơn so với một nguồn đơn.

d. BYTE:

Một bộ “mixer” phải chuyển thẳng các gói BYTE. Khi bộ

“mixer” muốn rời khỏi phiên làm việc, nó sẽ gởi một gói

BYTE đến tất cả các “cloud” có kết nối đến. Gói Byte

này sẽ chứa định danh SSRC của tất cả các nguồn đã từng

125


được chuyển qua, kể cả định danh SSRC của bản thân bộ

“mixer”.

e. APP:

Việc xử lý các gói AAP tại “mixer” sẽ phụ thuộc vào

từng ứng dụng cụ thể.

5.4. CÁC “MIXER” MẮC PHÂN TẦNG:

Một phiên RTP có thể bao gồm nhiều bộ “translator” và

“mixer” như trên hình vẽ

Hình5.5 :Mô hình phân tầng các Mixer.

Nếu 2 “mixer” được phân tầng như M2 và M3 trong hình,

các gói được nhận bởi một “mixer” đã được tổng hợp và

đã được chèn thêm danh sách CSRC. Bộ “mixer” sau đó sẽ

tạo danh sách CSRC ở đầu ra dựa vào danh sách CSRC từ

“mixer” trước và các định danh SSRC của các gói chưa

được trộn.

126


Trên hình vẽ đầu ra của M3 sẽ có danh sách CSRC là

(64,45). Giá trị này được tổng hợp từ danh sách CSRC

chuyển tới từ M2 (64) với giá trị SSRC của đầu cuối

E5:45.

Cũng giống như trong trường hợp không phân tầng, nếu

danh sách CSRC có nhiều hơn 15 định danh thì những giá

trị từ 16 trở đi sẽ không được thêm. Trường hợp này để

không xảy ra mất các nguồn từ 16 trở đi, ta sử dụng một

cơ chế vòng lặp, chèn luân phiên.

PHẦN VI: MỘT SỐ THUẬT TOÁN CẦN CHÚ Ý6.1. PHÂN PHỐI CÁC ĐỊNH DANH SSRC:

Định danh SSRC được mang trong phần tiêu đề RTP cũng

như trong nhiều trường khác của gói RTCP là một số ngẫu

nhiên 32-bit. Giá trị của nó phải hoàn toàn là duy nhất

127


trong một phiên RTP. Điều cốt yếu là làm thế nào để

chọn ra được các giá trị định danh SSRC để cho các

thành viên trong cùng mạng hay cùng bắt đầu vào một

thời điểm là không giống nhau.

Sẽ không thoả mãn nếu như ta sử dụng địa chỉ của mạng

cục bộ để định danh bởi vì địa chỉ này có thể là không

duy nhất. Ngoài ra khi các bộ “translators” và “mixers”

xử lý trong các liên mạng. Nếu các liên mạng này phân

chia địa chỉ theo một qui tắc nào đó thì khả năng xảy

ra xung đột sẽ cao hơn so với việc phân chia một cách

ngẫu nhiên.

Việc nhiều nguồn cùng chạy trên một máy chủ cũng có

thể gây ra xung đột.

Tuy nhiên, việc xác định SSRC cũng không chỉ đơn giản

là cứ chọn một giá trị ngẫu nhiên mà không quan tâm đến

trạng thái khi khởi tạo. Ví dụ về cách tạo một giá trị

SSRC được nêu ở phụ lục 6A[].

Bây giờ chúng ta sẽ thử tính xác suất xảy ra xung

đột.

6.1.1Xác suất xung đột:

Khi các giá trị SSRC được chọn một cách ngẫu nhiên,

sẽ có thể xảy ra khả năng nhiều hơn một nguồn chọn cùng

một giá trị, dẫn đến xung đột. Xác suất xảy ra xung đột

128


sẽ cao hơn nếu tại một thời điểm có nhiều người bắt đầu

đồng thời.

Nếu ta giả sử, có N nguồn tham gia, mỗi nguồn sử dụng

định danh có độ dài L-bit (ở đây L=32), khi đó xác suất

2 nguồn độc lập chọn cùng một giá trị sẽ được tính gần

đúng khi N rất lớn theo công thức sau:

PCollision=1 - exp(-N2 / 2L+1).

Nếu ta lấy N=1000, L=32 thì PCollision=10-4.

Ta thấy giá trị này khá nhỏ. Nhưng trên thực tế thì

giá trị này còn nhỏ hơn. Bởi vì khi một nguồn tham gia

vào một phiên RTP mà trong đó đã tồn tại sẵn một số

nguồn khác với các giá trị định danh hợp lệ rồi, xác

suất xảy ra xung đột chỉ sẽ được tính trên khoảng giá

trị còn trống.

Khi đó, nếu N là số nguồn, L chiều dài của phần định

danh thì xác suất xung đột sẽ là: PCollision=N/2L.

Nếu N=1000 thì PCollisioncũng chỉ xấp xỉ 2.10-7, một giá

trị nhỏ hơn rất nhiều.

Xác suất xung đột còn có thể được giảm hơn nữa khi mà

một nguồn mới được nhận các gói tin từ các nguồn khác

trước khi nó gởi đi gói tin đầu tiên của mình (là gói

RTP hoặc RTCP). Nguồn mới kiểm tra các giá trị SSRC của

những nguồn khác, trước khi phát đi gói số liệu đầu

tiên, nó kiểm tra xem SSRC của mình có xung đột với một

129


nguồn nào có sẵn không. Nếu có, nó sẽ chọn lại giá trị

mới một cách ngẫu nhiên.

6.1.2. Phát hiện vòng lặp và giải quyết xung đột:

Mặc dù xác suất xảy ra xung đột các định danh SSRC là

nhỏ, nhưng mọi ứng dụng RTP đều phải có sự cài đặt các

cơ chế để phát hiện xung đột và chọn ra các cơ chế giải

quyết thích hợp. Bất cứ khi nào một nguồn nhận ra rằng

có một nguồn khác đang sử dụng SSRC trùng với mình thì

nó sẽ gởi gói RTCP-BYTE với định danh SSRC cũ, sau đó

nó sẽ chọn lại một giá trị SSRC ngẫu nhiên khác.

Khi một người nhận phát hiện ra rằng có hai nguồn

đang xung đột, nó sẽ chọn giữ lại các gói tin của một

nguồn và loại bỏ các gói tin của nguồn kia. Việc phân

biệt hai nguồn này được thực hiện dựa trên giá trị của

địa chỉ truyền tải của nguồn hoặc dựa trên trường

CNAME. Cả hai nguồn xung đột đều được cài đặt cơ chế

giải quyết xung đột, do vậy tình trạng này sẽ không kéo

dài.

Bởi vì giá trị của SSRC được giữ đảm bảo là duy nhất

trong toàn bộ phiên RTP, do vậy nó có thể được sử dụng

để phát hiện vòng lặp gây ra bởi các bộ “translator” và

“mixer”. Vòng lặp là hiện tượng nhân đôi các gói dữ

liệu hoặc thông tin điều khiển và truyền chúng tới cùng

đích. Vòng lặp xuất hiện do một số nguyên nhân gây sau:

130


Một bộ “translator” có thể chuyển tiếp một gói

dữ liệu tới một nhóm multicast mà các nguồn tại

đấy đã nhận được gói dữ liệu rồi. Trong trường

hợp này, cùng một gói dữ liệu sẽ xuất hiện nhiều

lần tại bên nhận, xuất phát từ các nguồn khác

nhau.

Hình 6.1: Minh hoạ lặp vòng.

Khi hai “translator” mắc song song, được cài đặt

không đúng cách, chúng có cùng một nhóm địa chỉ

multicast, do vậy khi một gói tin được chuyển

tới, nó sẽ đồng thời được chuyển tiếp tới cùng 1

địa chỉ đích. Các bộ “translator” đơn hướng sẽ

tạo ra 2 bản copy, còn các bộ “translator” hai

chiều sẽ có thể hạn chế được vòng lặp.

Khi một nguồn nhận ra rằng gói tin của nó đang bị lặp

vòng, hoặc gói tin của một nguồn khác bị lặp vòng. Cả

131


sự lặp vòng và xung đột do việc chọn các giá trị SSRC

một cách ngẫu nhiên đều gây ra việc các gói dữ liệu đến

co cùng định danh SSRC nhưng lại có địa chỉ giao vận

khác nhau. Bởi vậy khi một nguồn thay đổi địa chỉ giao

vận của mình thì phải chọn một giá trị SSRC mới để

tránh gây ra lặp vòng. Điều này không hề bắt buộc, bởi

trong một số ứng dụng RTP, một nguồn có thể thay đổi

địa chỉ trong suốt phiên truyền.

Khi một bộ “translator” restart, địa chỉ giao vận của

nó cũng thay đổi (do địa chỉ cổng UDP của nguồn thay

đổi), nếu trước đó nó đã gởi đi các gói số liệu thì các

gói này sẽ bị coi là lặp vòng đối với bên nhận. Do giá

trị SSRC trên các gói đó là giá trị cũ khác với giá trị

SSRC của nguồn sau khi khởi động lại. vấn đề này có thể

tránh được bằng cách giữ nguyên địa chỉ giao vận trong

quá trình khởi động lại.

Khi xung đột hoặc lặp vòng xảy ra cách xa “mixer”

hoặc “translator” sẽ không thể phát hiện được dựa trên

địa chỉ giao vận, nếu tất cả các bản sao của gói đều

được chuyển qua 1 bộ “translator” hoặc “mixer”. Khi đó

xung đột phải được phát hiện dựa trên trường CNAME. Nếu

xung đột SSRC xảy ra, sẽ dẫn đến hiện tượng 2 gói tin

có cùng SSRC nhưng lại cho CNAME khác nhau.

132


Để có thể phát hiện và giải quyết những xung đột, RTP

cần phải được cài đặt thêm một thuật toán như được nêu

ở phần sau. Theo thuật toán này, các gói tin của một

nguồn mới tham gia hoặc sự lặp vòng gây lên xung đột

với một nguồn có săn sẽ bị bỏ qua. Nó giải quyết xung

đột giá trị SSRC của các thành viên bằng cách gởi đi

gói RTCP-BYTE, mang giá trị SSRC cũ (bị xung đột), chọn

lại một giá trị SSRC mới. Tuy nhiên khi xung đột gây ra

bởi sự lặp vòng các gói tin của chính mình, thuật toán

sẽ chọn một định danh mới duy nhất một lần và sau đó bỏ

qua tất các các gói từ địa chỉ nguồn bị lặp vòng. Việc

này là nhằm tránh trường hợp các gói BYTE khi gởi đi

cũng bị lặp dẫn đến việc tràn ngập gói BYTE.

Theo thuật toán này, cần phải tạo một bảng, đánh số

bằng các giá trị SSRC, địa chỉ giao vận của các nguồn.

Các giá trị này được ghi vào bảng khi gói RTP và gói

RTCP đầu tiên mang định danh mới được nhận. Bảng sẽ

được cập nhật các trạng thái của của các nguồn. Mỗi giá

trị SSRC hay CSRC nhận được từ các gói RTP hoặc RTCP sẽ

được so sánh với các giá trị trong bảng để cập nhật các

thông tin về dữ liệu hoặc thông tin điều khiển.

Nếu địa chỉ nguồn ban đầu được nhận thông qua một

”mixer” và sau đó nó nhận được từ nguồn đó một cách

trực tiếp, thì bên nhận được khuyến cáo nên chọn địa

133


chỉ mới hơn. Trong các ứng dụng như điện thoại, có một

số nguồn như các thực thể di động có thể thay đổi địa

chỉ trong suốt một phiên RTP, nên giao thức RTP phải

cung cấp thuật toán phát hiện xung đột để chấp nhận các

gói đến từ địa chỉ nguồn mới.

Khi có một định danh SSRC mới được chọn do hiện tượng

xung đột, thì định danh SSRC được chọn phải được kiểm

tra trong bảng định danh nguồn để xem nó đã được dùng

bởi nguồn nào hay chưa. Nếu định danh đó đã được dùng

rồi thì định danh khác được tạo ra và tiếp tục quá

trình kiểm tra đó.

Một vòng lặp các gói dữ liệu có thể gây ra hiện tượng

tràn khi nó được multicast. Tất cả các ”mixer” và

”translator” phải thực hiện thuật toán phát hiện vòng

lặp để phá vỡ chúng. Tuy nhiên, trong trường hợp xấu

nhất khi ”mixer” và ”translator” không làm việc chính

xác, tức là không loại bỏ được vòng lặp thì điều cần

thiết là cần phải cho các hệ thống cuối ngừng hoàn toàn

việc truyền phát các gói dữ liệu và điều khiển. Việc

truyền lại có thể được thử lại định kỳ sau một khoảng

thời gian dài ngẫu nhiên (đơn vị phút).

Thuật toán sẽ được nêu ở phần phụ lục.

6.2 VẤN ĐỀ BẢO MẬT TRONG RTP:

134


Các giao thức lớp dưới có thể cung cấp tất cả các dịch

vụ bảo mật cần thiết cho một ứng dụng RTP, bao gồm chức

năng xác thực, tính toàn vẹn và khả năng che dấu dữ

liệu. Những dịch vụ này đã được chỉ định ở lớp IP. Khi

khởi tạo một ứng dụng audio và video sử dụng RTP cần

che dấu dữ liệu trước khi đưa xuống lớp IP ta sử dụng

che dấu dữ liệu của các gói RTP/RTCP.

6.2.1. Khả năng che dấu dữ liệu:

Che dấu dữ liệu có nghĩa là chỉ những người nhận mong

đợi mới có thể giải mã được gói tin nhận được, đối với

những người nhận khác gói tin không cung cấp một thông

tin hữu ích nào. Để che dấu dữ liệu của nội dung gói

tin ta sử dụng mã mật.

Với cách mã hoá các gói RTP và RTCP được đề ra ở đây,

tất cả các octets sẽ được đóng gói để truyền trong một

gói đơn ở giao thức lớp dưới và được mật hoá thành một

khối dữ liệu hoàn chỉnh.

Đối với các gói RTCP, một số 32-bit ngẫu nhiên, sẽ

được gắn thêm trước khi được mã hoá. Đối với các gói

RTP, ta không gắn thêm gì nhưng sẽ khởi tạo các trường

số thứ tự và nhãn thời gian trong những khoảng ngẫu

nhiên.

Ngoài ra đối với gói RTCP, có thể chia những gói RTCP

đơn lẻ trong 1 gói ghép RTCP thành 2 gói RTCP ghép. Sau

135


đó một gói sẽ được mã hoá còn một gói sẽ được truyền đi

trực tiếp. Ví dụ các thông tin SDES có thể được mã hoá

trong khi đó các bản tin báo nhận thì được truyền đi

trực tiếp, để các thành viên thứ ba (nhà quản trị) có

thể theo dõi mà không cần khoá mã.

Để kiểm tra gói tin có được mã mật không và để kiểm

tra xem khoá giải mã có đúng không sẽ được thực hiện

tại bên nhận thông qua việc kiểm tra sự hợp lệ của phần

tiêu đề và phần tải.

Thuật toán được sử dụng cho việc mã hoá mật được dùng

là DES (Data Encryption Standard algorithm ) được nêu

trong RFC 1423. Do khuôn khổ của đồ án, ta chỉ dừng vấn

đề ở đây.

6.2.2. Nhận thực và bảo toàn dữ liệu (Integrity and

authenticity):

Dịch vụ nhận thực và bảo toàn dữ liệu không được thực

hiện ở lớp RTP nó sẽ được thực hiện ở các tầng giao

thức dưới.

6.3. ĐIỀU KHIỂN TẮC NGHẼN:

136


Mọi giao thức truyền tải được sử dụng trên internet

phải cung cấp khả năng điều khiển tắc nghẽn bằng một

vài cách nào đó. Giao thức RTP cũng không là một ngoại

lệ, tuy nhiên dữ liệu truyền tải bằng giao thức RTP

thường có tốc độ khó thay đổi (nó thường có tốc độ cố

định hoặc được ấn định trước một giá trị nào đó). Các

phương tiện dùng để điều khiển tắc nghẽn của RTP có thể

hơi khác biệt so với các giao thức truyền tải khác như

TCP. Theo một cách nào đó, việc không thể thay đổi tốc

độ của RTP làm giảm nguy cơ gây tắc nghẽn, bởi vì luồng

RTP sẽ không trải hết khoảng băng thông cho phép như

giao thức TCP. Việc không thay đổi tốc độ truyền của

luồng RTP có nghĩa là không thể giảm tải trên mạng khi

xảy ra tắc nghẽn.

Do RTP có thể sử dụng trong nhiều ứng dụng khác nhau,

trong những ngữ cảnh khác nhau, nên không thể có một cơ

chế điều khiển tắc nghẽn nào có thể sử dụng cho tất cả.

Vì thế, việc điều khiển tắc nghẽn sẽ được định nghĩa

trong từng ứng dụng RTP cụ thể cho phù hợp.

Một số loại ứng dụng có thể cài đặt một số câu lệnh

hạn chế người sử dụng để tránh xảy việc tắc nghẽn.

Một số loại ứng dụng khác có thể sử dụng những cơ chế

thay đổi tốc độ dữ liệu dựa trên những thông tin hồi

đáp từ RTCP.

137


6.4. RTP VỚI CÁC GIAO THỨC LỚP MẠNG VÀ LỚP GIAO VẬN:

Giao thức RTP nhờ vào các giao thức lớp dưới để phân

thành các luồng dữ liệu RTP và luồng điều khiển RTCP.

Đối với UDP và những giao thức tương tự, RTP nên sử

dụng những cổng chẵn và luồng RTCP nên sử dụng cổng lẻ

liền sau. Trong những ứng dụng mà các cổng đich RTP và

RTCP được chỉ định rõ ràng, tách biệt các tham số (có

thể sử dụng giao thức báo hiệu hoặc các phương tiện

khác), khi đó ứng dụng sẽ không cần quan tâm đến điều

kiện cặp cổng chẵn/lẻ. Tuy nhiên việc phân định các

cổng RTP/RTCP theo dạng chẵn/lẻ vẫn luôn được khuyến

khích. Ta phải phân định các cổng khác nhau cho RTP và

RTCP vì giao thức RTP dựa trên số hiệu cổng để tách các

luồng dữ liệu RTP và luồng điều khiển RTCP.

Trong những phiên truyền unicast cả hai thành viên

đều cần xác định một cặp cổng để nhận các gói RTP và

RTCP. Cả hai thành viên có thể sử dụng cùng một cặp

cổng. Khi các gói RTP được gởi theo cả hai hướng, các

gói RTCP-SR của mỗi thành viên phải được gởi tới cổng

mà thành viên kia dùng để nhận RTCP. Các gói RTCP-SR

kết hợp cả thông tin về dữ liệu được gởi lẫn bản tin

báo nhận. Nếu bên nào không ở trạng thái truyền dữ liệu

thì nó sẽ gởi đi gói RTCP-RR.

138


Khi địa chỉ multicast được sử dụng, địa chỉ cũng phải

được tách biệt rõ ràng, bởi vì việc chọn đường dựa trên

địa chỉ multicast và quan hệ nhóm thành viên được được

quản lý dựa trên địa chỉ riêng rẽ. Chú ý, việc phân

định các địa chỉ multicast liên tiếp không được thực

hiện, bởi vì một số nhóm có yêu cầu những phạm vi khác

nhau, nên phải được phân cho những khoảng địa chỉ khác

nhau.

Các gói dữ liệu RTP không chứa trường độ dài hay

thông tin mô tả khác, do đó RTP phải dựa vào các giao

thức bên dưới để cung cấp một số thông tin về độ dài.

Độ dài lớn nhất của các gói RTP chỉ bị giới hạn bởi các

giao thức lớp dưới.

Nếu các gói RTP được vận chuyển bởi giao thức lớp

dưới mà giao thức này cung cấp sự hỗ trợ luồng, sự đóng

gói các gói RTP phải được hỗ trợ các cơ chế framing.

Việc tạo khung cũng cần thiết nếu giao thức lớp dưới có

chứa phần đệm làm cho phần mở rộng tải của RTP không

được xác định rõ. Do phạm vi của đề tài, chúng ta sẽ

không đi tìm hiểu cơ chế framing.

Ta phải chỉ định phương thức framing được sử dụng,

ngay cả khi gói RTP được mang theo giao thức cung cấp

cơ chế framing để có thể mang nhiều gói RTP trong một

đơn vị dữ liệu của giao thức lớp dưới (ví dụ như gói

139


UDP). Việc mang nhiều gói RTP trong một gói đơn ở lớp

giao vận hoặc lớp mạng giúp cho việc giảm thiểu kích

thước tổng cộng phần tiêu đề và có thể làm cho việc

đồng bộ giữa các luồng đơn giản hơn.

140


CHƯƠNG VII: ỨNG DỤNG LÝ THUYẾT VÀO THỰC TẾ

Với phương châm, học đi đôi với hành, sau những gì đã tìm

hiểu về giao thức RTP và RTCP, em đã cùng một số bạn đã thử

áp dụng một mô hình RTP vào thực tế. Chúng em đã chọn mô

hình truyền hình theo yêu cầu (video on demand). Công việc

của chúng em là thiết kế một website quản lý VoD. Tuy có

những hạn chế về hiểu biết, kinh nghiệm cũng như điều kiện

vật chất, kỹ thuật nhưng chúng em cũng đã thu được một số

kết quả nhất định.

7.1 PHÂN TÍCH YÊU CẦU ĐẶT RA:

1. Thông lượng đường truyền:

Tuỳ thuộc vào băng thông cho phép của mạng, ta có thể

quyết định sử dụng chuẩn nén thích hợp. Với các mạng

cục bộ, các chuẩn nén có thể được sử dụng bao gồm MPEG,

H.263 và JPEG. Việc sử dụng các chuẩn nén này cho phép

đạt được băng thông các dòng video trong khoảng từ 200

kbps tới 2 Mbps.

2. Độ trễ:

Độ trễ làm ảnh hưởng đến chất lượng video. Điều mong

muốn là đạt được độ trễ nhỏ nhưng bị giới hạn bởi kênh

truyền. Độ trễ chấp nhận được đối với các cuộc hội

141


thoại video nằm trong khoảng từ 150 ms tới 200 ms. Với

các dòng video có độ trễ lớn hơn 200 ms, tính thời gian

thực sẽ không đảm bảo và đối với tai người có thể phát

hiện ra độ trễ và làm cuộc hội thoại trở nên khó khăn.

3. Jitter:

Thông thường nếu giá trị của jitter nằm trong khoảng từ

10 ms tới 30 ms coi như chấp nhận được trong việc

truyền hình.

4. Kiểm soát và cân bằng lưu lượng:

a. Kiểm soát lưu lượng:

Với một băng thông cho trước, hạn chế về dung

lượng, chúng ta phải phân phối băng thông một cách

hợp lý để ứng dụng có thể chạy hiệu quả nhất, đảm

bảo được nhiều client có thể xem đồng thời.

- Băng thông cho dòng video:

Với một băng thông khoảng 740kbps dùng chuẩn nén MPEG

là có thể cho ta chất lượng hình ảnh tương đối tốt.

- Băng thông cho dòng audio:

Thông thường, băng thông mà một dòng audio cần là

khoảng từ 56 đến 128kbps. Với mạng LAN, có điều kiện

băng thông khá rồi dào (10Mbps) ta có thể chọn tốc

băng thông dành cho dòng thoại 128M.

- Băng thông dùng điều khiển: Đây là băng thông giành

cho những thông tin điều khiển trong giao thức RTP

142


nằm trong các gói RTP, RTCP. Nó sẽ được tính bằng

tốc độ của phần tiêu đề gói RTP+tốc độ của cả gói

RTCP.

Để kiểm soát lưu lượng, ta có thể sử dụng cơ chế tĩnh

hoặc cơ chế động.

Cơ chế tĩnh: Băng thông được cố định sẵn cho mỗi

phiên truyền RTP, nó được duy trì trong suốt

phiên và được giải phóng khi kết thúc phiên.

Cơ chế động: Băng thông được cấp phát cho mỗi

phiên truyền RTP được thay đổi phụ thuộc vào khả

năng cung cấp của đường truyền, hay phụ thuộc số

phiên RTP tham gia trên toàn mạng.

b. Cân bằng lưu lượng:

Cơ chế này được sử dụng để làm giảm độ chênh lệch

quá lớn giữa các dòng video. Để thực hiện việc này

ta phải thực hiện theo trình tự.

-Kiểm tra lưu lượng của dòng video lớn nhất xem

có chất lượng có vượt hơn chất lượng tối thiểu

không?

-Nếu chất lượng vượt qua chất lượng tối thiểu ở

một khoảng nào đấy thì giảm lưu lượng dòng

video xuống.

-Lặp lại quá trình trên cho đến khi các dòng đạt

được tổng lưu lượng cho phép.

143


c. Các phương pháp điều khiển lưu lượng dòng video:

- Thay đổi độ phân giải.

- Thay đổi tốc độ khung hình.

- Thay đổi chất lượng hình ảnh (số mầu của ảnh).

7.2. THỰC HIỆN:

Mô hình triển khai là :

a. Server:

- Sử dụng hệ điều hành Linux 9.0:

Hệ điều hành mã nguồn mở, tính đa nhiệm cao, ổn định,

rẻ tiền.

- Cơ sở dữ liệu Posgresql 7.43:

Một hệ cơ sở dữ liệu mạng rất mạnh, có khả năng hộ

trợ Java tốt, tốc độ cao, hộ trợ các chức năng giao

tác, miễn phí, mã nguồn mở.

- Chùm ngôn ngữ lập trình Java (jsp, servlet,

javaScript, EJB, JMF, java): Đây là những ngôn ngữ

thuộc họ Java, chạy trên môi trường máy ảo, có rất

nhiều hàm thư viện sẵn có. Đặc biệt java là ngôn ngữ

hướng đối tượng, khả chuyển, linh động, hiệu quả cao.

- Máy chủ Tomcat:

khả năng quản lý tốt, hộ trợ jsp và servlet, dễ sử

dụng.

- Phương thức truyền:

144


File video được nén theo chuẩn MPEG được lưu trên máy

chủ. Khi có yêu cầu từ máy khách, máy chủ sẽ đọc

file, xử lý, xuất thành luồng tới máy khách.

Hình 7.1: Mô hình hoạt động.

- Phương thức báo hiệu:

Việc truyền các luồng video được điều khiển và báo

hiệu bằng giao thức RTCP.

b. Client:

145


Sử dụng microsoft windows media phiên bản từ 7.x, có khả

năng hỗ trợ luồng (streaming suport). Khi chơi một

streaming media, ta có thể quan sát được nhữngthông tin về chất lượng kết nối, tốc độ bit hiện

thời, tốc độ hình ảnh…

7.3. KẾT QUẢ:

Sau một thời gian thực hiện, chúng em đã hoàn thành một

website quản lý VoD trên hệ điều hành Linux với đầy đủ

các chức năng của nhà quản trị VoD, đáp ứng được nhu

cầu xem phim trực tuyến.

Kết quả thu được như sau:

146


Hình 7.2: Màn hình trang chủ

147


Hình 7.4: Các chức năng phục vụ đối với Client.

Hình 7.3: Chức năng quản lý của VoD admin.

148


PHỤ LỤC

1. KIỂM TRA PHẦN TIÊU ĐỀ RTP : RTP Data HeaderValidity ChecksBên nhận trong giao thức RTP phải kiểm tra tính

hợp lệ của phần tiêu đề RTP của các gói tới, trongtrường hợp chúng được mã mật hay là một gói tin bịnhầm địa chỉ từ một ứng dụng khác. Tương tự, nếu khimã hoá mật theo phương thức được mô tả ở phần 9, thìphải thực hiện kiểm tra phần tiêu đề để khẳng địnhquá trình giải mã mật là chính xác.

Việc kiểm tra tính hợp lệ của phần tiêu đề RTPđược thực hiện theo một số qui tắc sau:

Giá trị trường RTP version phải bằng 2. Kiểu tải (payload type) phải được xác định,

phải khác kiểu SR và RR. Nếu bit P được thiết lập bằng 1, khi đó byte

cuối cùng của gói phải chứa số byte hợp lệ(nhỏ hơn tổng kích thước gói trừ đi kích thướcphần tiêu đề).

Bit X phải bằng 0 nếu kiểu ứng dụng chưa đượcxác đinh, khi đó phần tiêu đề mở rộng được sửdụng. Ngược lại, trường kích thước mở rộng(extension length field) phải nhỏ hơn tổngkích thước gói trừ đi kích thước phần tiêu đềcố định và phần thêm (padding).

Kích thước của gói phải nhất quán với CC vàpayload type. (nếu phần tải có kích thước đãbiết).

Trong những qui định trên, 3 qui tắc cuối cùng làkhá phức tạp và có thể bỏ qua. Nếu phần định danhSSRC trong gói là một giá trị đã được nhận trước đây,

149


khi đó gói có thể hợp lệ nếu số thứ tự nằm trongkhoảng giá trị cho phép. Nếu định danh SSRC lần đầutiên được nhận, khi đó gói tin mang định danh này sẽbị coi là không hợp lệ cho đến khi nhận được một sốcác gói tin có số thứ tự liên tiếp. hững gói được coilà không hợp lệ sẽ bị loại bỏ hoặc có thể được lưulại và được đem ra sử dụng khi bắt đầu có gói tin hợplệ trong thời gian trễ cho phép.

Ngoài ra, việc kiểm tra có thể khắt khe hơn vớiyêu cầu nhiều hơn 2 gói tin liên tiếp.

2. KIỂM TRA PHẦN TIÊU ĐỀ RTCP:Việc kiểm tra phần tiêu đề gói RTCP cũng được thực

hiện tương tự với các qui tắc sau: RTP version bằng 2. Trường payload type của gói RTCP đầu tiên

trong gói ghép phải bằng SR hoặc RR. Bit đệm (P) phải bằng 0 đối với gói đầu tiên

trong gói ghep RTCP. Bởi vì phần đệm chỉ đượcthêm, nếu cần thiết, vào cuối gói.

Những trường kích thước của từng gói RTCPriêng cộng lại phải bằng tổng kích thước củagói RTCP ghép nhận được. Việc kiểm tra nàynhằm chuẩn hoá.

Nếu trường hợp một gói RTCP có kiểu chưa xác địnhthì phải được nhận ra và bỏ qua.

3. CÁC HẰNG SỐ DÙNG CHO PAYLOAD TYPE:

PT Name Type Clock rate(Hz)

Audiochannels References

0 PCMU Audio 8000 1RFC 35511 1016 Audio 8000 1RFC 35512 G721 Audio 8000 1RFC 35513 GSM Audio 8000 1RFC 35514 G723 Audio 8000 1

150

http://www.networksorcery.com/enp/rfc/rfc3551.txt





5 DVI4 Audio 8000 1RFC 35516 DVI4 Audio 16000 1RFC 35517 LPC Audio 8000 1RFC 35518 PCMA Audio 8000 1RFC 35519 G722 Audio 8000 1RFC 355110 L16 Audio 44100 2RFC 355111 L16 Audio 44100 1RFC 355112 QCELP Audio 8000 1 13 CN Audio 8000 1RFC 3389

14 MPA Audio 90000 RFC 2250, RFC 3551

15 G728 Audio 8000 1RFC 355116 DVI4 Audio 11025 1 17 DVI4 Audio 22050 1 18 G729 Audio 8000 1

19 reserved Audio

20-24

25 CellB Video 90000 RFC 202926 JPEG Video 90000 RFC 243527 28 nv Video 90000 RFC 355129 30 31 H261 Video 90000 RFC 203232 MPV Video 90000 RFC 2250

33 MP2T Audio/Video 90000 RFC 2250

34 H263 Video 90000

151




















35-71

72-76

Reserved

77-95

96-127

dynamic

dynamic GSM-HR Audio 8000 1

dynamic GSM-EFR Audio 8000 1

dynamic L8 Audio variable variable

dynamic RED Audio

dynamic VDVI Audio variable 1

dynamic BT656 Video 90000

dynamic

H263-1998 Video 90000

dynamic MP1S Video 90000

dynamic MP2P Video 90000

dynamic BMPEG Video 90000

152


TÀI LIỆU THAM KHẢO

1- Nguyễn Quốc Cường (2001) – Internetworking với TCP/IP.2- Andrew S.Tanenbaum (2002) - Mạng máy tính. Biên soạn và

lược dịch Hồ Anh Phong.3- RFC 3550 – RTP: A Transport Protocol for Real-time

Applications 4- Kevin Jeffay, Department of Computer Science,

University of North Carolina at Chapel Hill (1999) –The Multimedia Transport Protocol RTP.

5- Kevin Jeffay (1999), Department of Computer Science,University of North Carolina at Chapel Hill – TheMultimedia Control Protocol RTCP.

6- Nguyễn Thúc Hải (1999) - Mạng máy tính và các hệ thốngmở.

7- Cisco press - Internetworking Technologles Handbook.

153


8- Henning Schulzrinne (2003), Dept. of Computer Science,Columbia University – Multicast.

9- David Meyer, Cisco System – Introduction to IPMulticast.

KẾT LUẬN

Hiện nay tại Việt Nam, tuy các ứng dụng RTP chưa phát

triển, nhưng trong một thời gian ngắn nữa chắc chắn nó

sẽ là một lĩnh vực nghiên cứu sôi động. Nếu có một

nghiên cứu hoàn chỉnh, đầy đủ về RTP là một điều rất có

ý nghĩa thực tế. Tuy nhiên do thời gian có hạn, những

gì em làm được ở đây mới chỉ là nghiên cứu phần kiến

thức cơ bản về RTP. Chương trình quản lý website VoD là

sự thực hành giúp chúng em hiểu rõ hơn nắm chắc hơn

những khái niệm và những thuật toán trong giao thức

RTP. Tuy ứng dụng hoạt động còn nhiều hạn chế, nhưng

154


dẫu sao nó cũng khẳng định rằng sự đầu tư tìm hiểu của

chúng em là có hiệu quả.

Em hy vọng rằng, sau này em sẽ có điều kiện để tiếp

tục tìm hiểu sâu hơn nữa về giao thức RTP, và có thể

hoàn thiện chương trình của mình tốt hơn, đáp ứng được

như cầu của một dịch vụ VoD hoàn hảo.

Một lần nữa, em xin chân thành cảm ơn thầy Nguyễn Tài

Hưng đã tận tình hướng dẫn, khích lệ và tạo mọi điều

kiện thuận lợi giúp đỡ em trong quá trình hoàn thành

đồ án này!

Em xin chân thành cảm ơn các thầy cô đã tận tình dìu

dắt em trong những năm học vừa qua!

155

Truyen dong du lieu thoi gian thuc real time streaming - Tại 123doc

Documents

Transcript of Truyen dong du lieu thoi gian thuc real time streaming - Tại 123doc