NGHIÊN CỨU GIAO THỨC RTP VÀ XÂY DỰNG ỨNG DỤNGVIDEO STREAMING

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

KHOA CÔNG NGHỆ THÔNG TIN

Tel (84-511) 736 949, Fax (84-511) 842 771Website: itf.ud.edu.vn, E-mail: cntt@edu.ud.vn

LUẬN VĂN TỐT NGHIỆP KỸ SƯ

NGÀNH CÔNG NGHỆ THÔNG TIN

SINH VIÊN : HUỲNH PHƯƠNG ĐỨC

NGUYỄN VĂN HƯNG

ĐÀ NẴNG, 06/2011

Chúng em xin gửi lời cảm ơn chân thành đến tất cả các Thầy Cô đã giảng dạy chúng

em trong suốt thời gian qua Cảm ơn thầy KS.GVC.Nguyễn Thế Xuân Ly - người đã

hướng dẫn, gợi mở và đóng góp ý tưởng để chúng em thực hiện đề tài này.

Bên cạnh đó, để hoàn thành đề tài này, chúng em cũng đã nhận được rất nhiều sự giúp đỡ, những lời động viên quý báu của các bạn bè, các anh chị thân hữu; chúng

em xin hết lòng ghi ơn.

Tuy nhiên, do thời gian hạn hẹp, mặc dù đã nỗ lực hết sức mình, nhưng chắc rằng đồ

án khó tránh khỏi thiếu sót Chúng em rất mong nhận được sự thông cảm và chỉ bảo tận tình của quý Thầy cô và các bạn.

Tôi xin cam đoan :

1 Những nội dung trong luận văn này là do tôi thực hiện dưới sự hướng dẫn

trực tiếp của thầy KS.GVC.Nguyễn Thế Xuân Ly.

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

3 Mọi sao chép không hợp lệ, vi phạm quy chế đào tạo, hay gian trá,

tôi xin chịu hoàn toàn trách nhiệm.

Sinh viên,

Huỳnh Phương Đức Nguyễn Văn Hưng

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

II Quá trình truyền dòng: 4

I Giao thức TCP:(Transmision Control Protocol) 9

I.1 Đặc điểm giao thức TCP: 9

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

I.3 Điều khiển luồng dữ liệu: 12

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

I.4.1 Thiết lập liên kết TCP: 12

I.4.2 Huỷ bỏ một liên kết: 12

I.5 Truyền và nhận dữ liệu: 13

II Giao thức UDP:(User Datagram Protocol) 13

II.1 Định tuyến Multicast: 14

II.1.1 Khái niệm nhóm Multicast: 15

II.1.2 Địa chỉ Multicast:15

TỔNG QUAN GIAO THỨC THỜI GIAN THỰC RTP(REAL TIME

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

II Ứng dụng của RTP trong hội thảo đa phương tiện: 18

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

II.2 Hội thảo sử dụng thoại và video (Audio and Video Conference): 19

GIAO THỨC TRUYỀN TẢI THỜI GIAN THỰC(RTP:REAL TIME

TRANSPORT PROTOCOL) 21

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

II Cấu trúc phần tiêu đề gói RTP: 25

III Ghép các phiên truyền RTP: 28

IV Sự thay đổi tiêu đề trong một số trường hợp: 28

GIAO THỨC ĐIỀU KHIỂN RTP (RTCP:REAL TIME CONTROL

I Chức năng và hoạt động của giao thức RTCP: 30

II Các loại gói tin RTCP: 32

III Khoảng thời gian truyền các gói RTCP: (RTCP Transmision Interval) 34

IV Cập nhật số thành viên tham gia phiên truyền:37

V Quy định đối với việc gửi và nhận gói tin RTCP: 37

VI Các bản tin thông báo của người gửi và người nhận: 43

VI.1 Phần đầu: 44

VII Gói tin mô tả các thông tin của nguồn: 51

I Khái niệm chung: 58

II Hoạt động của Translators: 60

III Hoạt động của Mixers: 62

IV Các Mixer mắc phân tầng: 64

MỘT SỐ THUẬT TOÁN CƠ BẢN 66

I Phân phối định danh SSRC: 66

I.1 Xác suất xung đột: 66

II Vấn đề bảo mật trong RTP: 69

II.1 Khả năng che dấu dữ liệu: 70

III Điều khiển tắt nghẽn: 70

IV RTP với các giao thức lớp Network và lớp Transport: 71

I Phân tích yêu cầu đặt ra: 73

I.1 Thông lượng đường truyền: 73

I.2 Độ trễ: 73

I.3 Jitter: 73

I.4 Kiểm soát và cân bằng lưu lượng: 73

I.4.1 Kiểm soát lưu lượng: 73

I.4.2 Cân bằng lưu lượng: 74

I.4.3 Các phương pháp điều khiển lưu lượng dòng video: 74

I.4.4 Thực hiện: 74

II Kết quả: 75

CƠ SỞ LÝ THUYẾT

Có rất nhiều ứng dụng hiện nay đòi hỏi tính thời gian thực (real time) Trong các dịch vụtruyền hình qua mạng, hội thảo trực tuyến, chat hình, chat tiếng…mỗi ứng dụng có nhữngđặc điểm riêng của nó, tuy nhiên có một số điều chung nhất mà các dịch vụ này đều yêu cầu

đó là việc truyền dữ liệu theo dòng (streaming) Do vậy chúng ta sẽ bắt đầu với việc tìm hiểu

về khái niệm truyền dòng

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

Khái niệm truyền dòng có thể hiểu là khi nội dung của audio hay video đượctruyề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àyhoà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ôngphụ thuộc vào độ dài của video Điều này rất có ý nghĩa khi truyền các file video cókích thước lớn hay các dòng video có độ dài không xác định Khi đó, các giao thứckhá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ácchươ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ộidung video, audio thông qua mạng, chúng ta có một phương pháp giao tiếp và truynhậ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ủavideo 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ộcthời gian như video, audio, bởi vì để đảm bảo chất lượng cảm thụ video thì phải đảmbả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 đượctruyền tới máy nhận Bên nhận có nhiệm vụ nhận dòng dữ liệu từ bên truyền gửi tới vàthể hiện lên thiết bị ra như TV hay màn hình máy tính Khi đó với việc sử dụng cơ chếtruyền dòng thời gian thực, các hình ảnh của giảng viên mà bên nhận thể hiện sẽ phảnánh một cách tức thời (về mặt lí thuyết) những gì đang xảy ra đối với giảng viên ở bêntruyề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

giác việc thể hiện đoạn video như là được thực hiện ngay trên máy cục bộ.

.II Quá trình truyền dòng:

Truyền dòng đối với video hay audio phải trải qua nhiều công đoạn với từng nhiệm

vụ riêng để đi đến kết quả cuối cùng là đạt được khả năng thể hiện ngay ở bên nhận

Hình 1 Quá trình truyền dòng video/audio

Để có thể tìm hiểu sâu được cơ chế truyền dòng, chúng ta cần đi sâu vào quá trình

mà thông tin được truyền đi thông qua môi trường mạng Bất cứ một nội dung videohay 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ộcnhư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ệclưu trữ hay truyền video không nén sẽ phải trả giá cao, đôi khi là điều không thể Talấy ví dụ với một định dạng tiêu biểu thường được sử dụng trong các ứng dụng hộinghị 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ộtframe hình (chế độ 352x288x16bpp) chiếm 202752 byte Việc ghi video không nénvớ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ì

NetworkDòng video/audio

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, tathấ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ềntrê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ôitrường mạng khác nhau:

Dạng kết nối

Bảng 1 Băng thông mạng và tỉ lệ nén yêu cầu

Có thể sử dụng nhiều chuẩn nén khác nhau cho việc nén video Tuỳ theo yêu cầuchất lượng và băng thông, mà ta có thể lựa chọn được phương pháp nén thích hợp.Với việc áp dụng một chuẩn nén cho dữ liệu video, không gian lưu trữ cần thiết cũngnhư 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òngvideo ở 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ềndòng video này chỉ vào khoảng 140 Kbps và không gian lưu trữ cần thiết cho mộtngà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ọ CCITTvới các chuẩn dạng H.26x, H.36x và họ ISO MPEG với các chuẩn MPEG-1, MPEG-

2, MPEG-4, MPEG-7 Sự phát triển của các chuẩn nén có thể tham khảo trong sơ đồdưới đây:

Hình 2 Sự phát triển của cá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áckhối nhỏ thích hợp để có thể truyền đi trong môi trường mạng Đối với các dữ liệuaudio, việc lấy mẫu được thực hiện theo thời gian Tương ứng sau một khoảng thờigian 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ác dữ liệu video, ngoài việc lấy mẫu theo thời giancò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ờigian thể hiện của các khung hình và việc lấy mẫu theo không gian sẽ được thực hiệnbằng cách chia nhỏ các khung hình thành các phần với kích thước thích hợp đối vớiviệc truyền đi

Khi lấy mẫu, các mẫu phải chứa đựng đầy đủ các thông tin dùng cho việc khôiphụ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

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

nhận nhận được các mẫu này Với việc sử dụng một giao thức như giao thức truyềnthông thời gian thực như RTP, quá trình lấy mẫu sẽ được tiến hành tự động.

Bước 3 - Truyền các mẫu qua mạng:

Việc truyền các mẫu dữ liệu video có thể được thực hiện một cách trực tiếp thôngqua các giao diện của môi trường mạng như Socket hay được thực hiện thông qua mộtgiao 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ápthứ 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ácmẫu nếu như giao thức đó được hỗ trợ trên nền phần cứng cũng như phần mềm

Việc sử dụng một giao thức truyền dòng thời gian thực có nhiều ưu điểm Ưu điểmthứ nhất là tính hiệu quả, bởi vì các giao thức truyền thông thời gian thực được thiết

kế cho việc truyền các loại dữ liệu động, như dữ liệu video chẳng hạn, khi đó tính thờigian 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ớigiao thức RTP, giao thức truyền thông lớp dưới thường được sử dụng là UDP (UserDatagram Protocol) là giao thức với độ tin cậy thấp nhưng có tốc độ truyền dữ liệucao hơn các giao thức với độ tin cậy cao như TCP

Ưu điểm thứ hai là các giao thức thời gian thực hỗ trợ mạnh việc đồng bộ các dòng

dữ liệu từ các nguồn khác nhau nhưng có quan hệ với nhau về mặt thời gian thực Ví

dụ như đối với việc truyền âm thanh và hình ảnh của cùng một sự vật, khi đó bên nhậnkhi thể hiện phải đảm bảo yêu cầu là âm thanh phải phù hợp với hình ảnh

Ngoài ra, các giao thức điều khiển còn cung cấp các dịch vụ cho phép quản lí cácthành viên tham gia và điều khiển chất lượng của việc phân phối dữ liệu

Với việc sử dụng một giao thức truyền thông thời gian thực cho việc truyền, khi đócác mẫu sẽ được đóng gói thành các gói tin Các gói tin sẽ mang đầy đủ các thông tinnhư nhãn thời gian, số thứ tự của gói tin và các thông tin khác đủ dùng cho việc khôiphục dữ liệu và đồng bộ các dòng khi bên nhận tiến hành nhận và thể hiện nội dungcủa video hay audio Thông qua các giao thức lớp dưới, các gói tin sẽ được truyền đitrong môi trường mạng

Bước 4 - Nhận và khôi phục dữ liệu và đồng bộ các dòng:

Đây là quá trình ngược với bước thứ ba, được thực hiện ở bên nhận khi dữ liệudưới dạng các gói tin được truyền đến Các gói tin được truyền đến có thể là của nhiềudòng tương ứng với nhiều nguồn dữ liệu khác nhau và cũng có thể thứ tự các gói tinnhậ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àocác thông tin được ghi trong từng gói tin để có thể xác định được vị trí về mặt khônggian và thời gian của các mẫu dữ liệu mà gói tin mang theo Việc xác định được vị trícủa các mẫu dữ liệu trong gói tin giúp cho việc khôi phục lại nội dung của video hayaudio một cách chính xác nhất Với việc truyền các dòng đơn lẻ không có quan hệ vớinhau về mặt 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ó quan

hệ với nhau về mặt thời gian thực thì cần phải đồng bộ các dòng về mặt thời gian.Việc đồng bộ các dòng chỉ cần thiết khi các dòng có quan hệ với nhau về mặt thờigian, chẳng hạn như việc đồng bộ hình với tiếng khi truyền video, khi đó thời gian thểhiện của các dòng phải được tính toán sao cho phù hợp với nhau Việc đồng bộ là mộtcông việc phức tạp, thường được thực hiện tự động bởi các giao thức truyền thôngthời gian thực như RTP Khi đó, mặc dù thứ tự các gói tin nhận được có thể khônggiống như thứ tự khi được gửi, thậm chí có một số gói tin bị mất nhưng giao thức vẫnphải đảm bảo tính đồng bộ cho các dòng khi được thể hiện ở nơi nhận

Bước 5 - Giải nén:

Bước này sẽ tiến hành giải nén dòng video/audio với chuẩn nén được sử dụng khinén Dữ liệu sau khi giải nén có thể được thể hiện ra các thiết bị ra hay được ghi rafile

CHƯƠNG 2

CÁC GIAO THỨC TRUYỀN TẢI CƠ BẢN

Trong chương trước chúng ta đã tìm hiểu qua khái niệm truyền dòng và phần nào đã hiểu một

số yêu cầu cơ bản của truyền dòng Chúng ta cũng đã đề cập đến việc sử dụng giao thức RTPcho 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ầnnà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ácgiao thức lớp truyền tải: TCP, UDP cùng với khái niệm truyền đa điểm multicast

.I Giao thức TCP:(Transmision Control Protocol)

TCP là một giao thức kiểu có liên kết (Connection – Oriented), tức là phải có giai

đoạn thiết lập liên kết giữa một cặp thực thể TCP trước khi truyền dữ liệu

Là một giao thức ở tầng giao vận TCP nhận thông tin từ các lớp trên chia nó thànhnhiều đoạn nếu cần thiết Mỗi gói dữ liệu được chuyển tới giao thức lớp mạng (thường

là IP) để truyền và định tuyến Bộ xử lý TCP của nó nhận thông báo đã nhận từng gói,nếu nó nhận thành công, các gói dữ liệu không có thông báo sẽ được truyền lại TCPcủ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 đượctoàn bộ

Trước khi các gói dữ liệu được gửi tới máy đích nơi gửi và nơi nhận phải thương

lượng để thiết lập một kết nối logic tạm thời Kết nối này về đặc trưng sẽ ở trạng thái

mở trong suốt phiên truyền

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

Trong bộ giao thức TCP/IP TCP là giao thức được phát triển như là cách để kết nốicá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 TCPthiế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 tintrao đổi giữa hai hệ thống được chia thành các gói TCP có những đặc điểm sau:

Sự bắt tay: Hai hệ thống cần kết nối với nhau cần phải thực hiện một loạt các sự

bắt tay để trao đổi những thông tin về việc chúng muốn kết nối Quá trình bắt tay đảm

bảo ngăn chặn sự tràn và mất mát dữ liệu khi truyền

Xác nhận: Trong phiên truyền thông tin, hệ thống nhận dữ liệu cần phải gửi các

xác nhận cho hệ thống phát để xác nhận rằng nó đã nhận được dữ liệu.

Trật tự: Các gói tin có thể đến đích không theo thứ tự sắp xếp của dòng dữ liệu

liên tục bởi các gói tin đi từ cùng một nguồn tin theo những đường dẫn khác nhau để

đi tới cùng một đích Vì vậy thứ tự đúng của các gói tin phải được đảm bảo sắp xếp lại

tại hệ thống nhận

Phát lại: Khi phát hiện gói tin bị lỗi thì nơi gửi chỉ phát lại những gói tin bị lỗi

nhằm để tránh loại bỏ toàn bộ dòng dữ liệu

Sending

Application

TCPSecssionPresentation

IPDadalinkPhysical

IPDadalinkPhysical

IPDadalinkPhysical

Receiving

TCP End to End CommmunicationRouter Router

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

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

Đơn vị dữ liệu sử dụng trong giao thức TCP được gọi là Segment Khuôn dạng của

Segment được mô tả như hình sau:

Hình 4.Khuôn dạng TCP Segment.

Các tham số của khuôn dạng trên có ý nghĩa như sau:

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

Bit 0 15 16 31

Sequence NumberAcknowledgment NumberData

PSH

RST

SYN

FIN

Window (16 bits)

TCPdata

Destination Port (16 bits): Số hiệu cổng của trạm đích Số hiệu này là địa chỉ thâm

nhập dịch vụ lớp giao vận (CCISAP Addess) cho biết dịch vụ mà TCP cung cấp làdịch vụ gì TCP có số lượng cổng trong khoảng 0216-1 tuy nhiên các cổng nằm trongkhoảng từ 01023 là được biết nhiều nhất vì nó được sử dụng cho việc truy cập cácdịch vụ tiêu chuẩn, ví dụ 23 là dịch vụ Telnet, 25 là dịch vụ mail

Sequence Number (32 bits): Số hiệu của byte đầu tiên của Segment trừ khi bit

SYN được thiết lập Nếu bit SYN được thiết lập thì Sequence Number là số hiệu tuần

tự khởi đầu (ISN) và byte dữ liệu đầu tiên là ISN+1

Acknowledgment Number (32 bits): Số hiệu của Segment tiếp theo mà trạm nguồn

đang chờ để nhận Ngầm ý báo đã nhận tốt các Segment mà trạm đích đã gửi cho trạmnguồn

Data offset (4bits): Số lượng từ 32 bit trong TCP header (Tham số này chỉ ra vùng

bắt đầu của vùng dữ liệu)

Reserved (6 bits): Dành để dùng trong tương lai.

Control bits: Các bits điều khiển Nếu tính từ trái sang phải:

URG: Vùng con trỏ khẩn có hiệu lực

ACK: Vùng báo nhận (ACK number) có hiệu lực

PSH: Chức năng PUSH

RST: Khởi động lại (reset) liên kết

SYN: Đồng bộ các số liệu tuần tự (sequence number)

FIN: Không còn dữ liệu từ trạm nguồn

Window (16bits): Cấp phát credit để kiểm soát luồng dữ liệu (cơ chế cửa sổ) Đây

chính là số lượng các byte dữ liệu bắt đầu từ byte được chỉ ra trong vùng ACKnumber, 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ệulự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.

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

Trong việc điều khiển luồng dữ liệu phương pháp hay sử dụng là dùng phương

pháp cửa sổ trượt Phương pháp này giúp cho việc nhận luồng dữ liệu hiệu quả hơn.

Phương pháp cửa sổ trượt cho phép nơi gửi (Sender) có thể gửi đi nhiều gói tin rồi

sau đó mới đợi tín hiệu báo nhận ACK (Acknowledgement) của nơi nhận(Receiver).

Với phương pháp cửa sổ trượt khi cần truyền các gói tin, giao thức sẽ đặt một cửa sổ

có kích cố định lên các gói tin Những gói tin nào nằm trong vùng cửa sổ ở một thờiđiểm nhất định sẽ được truyền đi

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

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

Thiết lập liên kết TCP:

Một liên kết có thể được thiết lập theo một trong hai cách chủ động (active) và bịđộng (passive) Nếu liên kết được thiết lập theo cách bị động thì đầu tiên TCP tại trạmmuố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ườnghợ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ênkế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 opentương hợp thì liên kết sẽ được thiết lập.Nếu liên kết được thiết lập thành công thì hàmOpen 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

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

Sau khi liên kết được thiết lập giữa một cặp thực thể TCP thì có thể tiến hành việc truyền dữ liệu Với liên kết TCP dữ liệu có thể được truyền theo cả hai hướng

Khi nhận được một khối dữ liệu cần chuyển đi từ người sử dụng, TCP sẽ lưu giữ

nó tại bộ đệm gửi Nếu cờ PUSH được dựng thì toàn bộ dữ liệu trong bộ đệm sẽ đượcgửi đi hết dưới dạng các TCP Sgment Còn nếu cờ PUSH không được dựng thì toàn

bộ dữ liệu vẫn được lưu giữ trong bộ đệm để chờ gửi đi khi có cơ hội thích hợp

Tại bên nhận, dữ liệu gửi đến sẽ được lưu giữ trong bộ đệm nhận Nếu dữ liệu đệmđược đánh dấu bởi cờ PUSH thì toàn bộ dữ liệu trong bộ đệm nhận sẽ được gửi lêncho người sử dụng Còn nếu dữ liệu không được đánh dấu với cờ PUSH thì chúng vẫnđược lưu trong bộ đệm Nếu dữ liệu khẩn cần phải chuyển gấp thì cờ URGENT đượcdù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ểngấp

.II Giao thức UDP:(User Datagram Protocol)

UDP (User Datagram Protocol) là một giao thức kiểu không kết nối, được sử dụngtrong một số yêu cầu ứng dụng thay thế cho TCP Tương tự như giao thức IP, UDPkhô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áonhậ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 TCPnên UDP chạy nhanh hơn, nó thường được sử dụng trong các dịch vụ không đòi hỏi

độ tin cậy cao Đơn vị dữ liệu dùng trong giao thúc UDP là UDP Datagram Khuôndạng của một UDP Datagram gồm hai phần: Phần tiêu đề (Header) chứa các thông tinđiều khiển và phần Data chứa dữ liệu

Khuôn dạng của UDP Datagram cụ thể như hình 2.5

UDP Source Port UDP Destination Port

UDP Message Length UDP Checksum

Data

Hình 5.Khuôn dạng UDP Datagram

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

UDP Source Port (16 bits): Cho biết địa chỉ cổng của trạm nguồn Nếu nó không

được chỉ ra thì trường này được thiết lập là 0

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ầnHeader, không có phần dữ liệu)

UDP Checksum (16 bits): Là mã kiểm soát lỗi theo phương pháp CRC.

Lớp UDP được đặt trên lớp IP, tức là UDP Datagram khi chuyển xuống tầng dưới

sẽ được đặt vào IP Datagram để truyền trên liên mạng IP Datagram này được ghépvà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ốicùng chỉ còn lại phần dữ liệu như ban đầu được chuyển cho người sử dụng

.II.1 Định tuyến Multicast:

IP Multicast là một kỹ thuật duy trì dải thông bằng cách làm giảm lưu lượng thôngqua 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 theonhóm, lớp học từ xa, hoặc là để phân phối các phần mềm, các chỉ số chứng khoán vàtin tức

Hình 6 Truyền Multicast

IP Multicast thực hiện phân phối nguồn thông tin tới rất nhiều các bên nhận màkhông cần thêm bất kỳ thông tin gì vào trong nguồn hay các bên nhận trong khi chỉ sửdụng một mức dải thông tối thiểu Các gói multicast được tái tạo lại bên trong cácRouter mà đã kích hoạt khả năng PIM (Protocol Independent Multicast) và các giaothứ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ệutớ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ồnphả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 chomỗi một bên nhận một bản copy độc lập Nếu như có hàng ngàn bên nhận, việc sửdụng IP Multicast là rất có lợi Với các ứng dụng yêu cầu băng thông cao như làMPEG video, thì nó có thể yêu cầu một phần lớn dải thông đường truyền cho mộtluồng đơn Trong những ứng dụng này, cách duy nhất để gửi dữ liệu tới hang ngànđích một cách đồng thời là sử dụng IP Multicast Hình dưới đây sẽ cho chúng ta biếtlà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ểudiễn một sự quan tâm đến việc nhận một luồng dữ liệu Nhóm này không có bất cứmột ranh giới rõ ràng về mặt vật lý hay địa lý Các thành viên (hosts) của nhóm này cóthể nằm ở bất cứ nơi nào trên Internet Các thành viên này có cùng sở thích là nhậnmộ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ànhviên của nhóm thì mới nhận được luồng dữ liệu mà họ quan tâm

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

RTP là một giao thức chuẩn dùng cho việc truyền các dữ liệu thời gian thực như

video, audio Nó có thể được sử dụng trong media-on-demand cũng như trong các

dịch vụ tương tác khác như điện thoại internet…giao thức RTP bao gồm hai phần, dữ liệu và điều khiển(RTCP)

Hình 8 Mô hình tổng quát về giao thức RTP.

Giao thức RTP (Real-time transport protocol), cung cấp các hàm phục vụ việc truyền tải dữ liệu “end to end” cho các ứng dụng thời gian thực, qua các mạng

multicast hay qua mạng unicast Các dịch vụ này bao gồm:

Sự phân loại tải: payload type identification

Đánh số thứ tự: sequence numbering

Đánh dấu thời gian phát, đồng bộ hoá:

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

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

Hình 10 Kiểm soát quá trình phân phối dữ liệu.

Để hỗ trợ cho RTP là giao thức điều khiển RTCP Giao thức này nhằm đảm bảocho 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ạngmulticast Ngoài ra nó còn cung cấp các dịch vụ, chức năng điều khiển và nhận dạng

Cả RTP và RTCP đều được thiết kế để có thể cài đặt một cách độc lập với các giaothức lớp Network và lớp Transport

Các ứng dụng RTP hoạt động phía trên của chồng giao thức UDP, với vai trò điềuchế 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ợpvớ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ờigian, cũng như sự đảm bảo về chất lượng dịch vụ(QoS) của các ứng dụng thời gianthự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ưngcá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 chophé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 đượcdù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ụngmultimedia 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ự thích ứng của RTP

Khi đề cập đến giao thức RTP là chúng ta đề cập đến hai vấn đề:

Giao thức truyền tải thời gian thực (real-time transport protocol): Với chức năng truyền tải các dữ liệu có thuộc tính thời gian thực

Giao thức điều khiển RTCP: Với chức năng giám sát chất lượng dịch vụ và truyền các thông tin về những phiên truyền RTCP giúp cho việc điều khiển các phiên

.II Ứng dụng của RTP trong hội thảo đa phương tiện:

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

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

.II.1 Hội thảo thoại sử dụng multicast đơn giản (Simple

Multicast Audio Conference):

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

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ệuthoạ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àyrấ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 haytrong 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 hayxả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 tinvới chu kỳ 20ms Việc khôi phục thời gian sẽ giúp cho bên nhận có thể phân biệt đượccá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ạccủa mỗi nguồn, kể từ khi họ tham gia hội thoại Việc này giúp chúng ta có thể đánhgiá 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 tinthô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ôngbáo

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

Conference):

Hình 12.RTP trong hội thảo sử dụng cả video/audio.

Trong trường hợp ta sử dụng đồng thời cả âm thanh và hình ảnh trong hội thảo, ta

sẽ sử dụng đồng thời hai cặp RTP/RTCP Việc truyền tín hiệu tiếng và tín hiệu hình là

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 Tuynhiê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 hailuồ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 formatcho các dữ liệu Media Điều này không thể được trong trường hợp có thành viên sửdụng đường truyền tốc độ thấp, các thành viên khác lại sử dụng đường truyền có tốc

độ cao Khi đó ta không thể bắt tất cả các thành viên cùng sử dụng truyền ở tốc độthấp, chất lượng tín hiệu thấp

Khi đó ta có thể sử dụng bộ trộn RTP-level mixer, đặt gần nơi có băng thông hẹp

Bộ này sẽ tái đồng bộ các gói tin thoại, khôi phục lại chu kỳ 20ms của phía gởi Sau

đó truyền lại dòng audio với tốc độ bit phù hợp với đường truyền Việc truyền lại này

có thể sử dụng truyền Unicast cho một người nhận đơn, hoặc Multicast cho một nhómngườ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ợpvớ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ềntố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 saufirewall

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

Trước khi đi vào tìm hiểu cụ thể về giao thức RTP, chúng ta cần phải nắm đượcmột số khái niệm cơ bản sau đây:

RTP payload: Đây là phần dữ liệu được truyền trong các gói RTP Đây có thể là

các mẫu tín hiệu thoại hoặc dữ liệu Video đã được nén Việc phân định dạng dữ liệu(được chỉ định bởi phần payload type) sẽ được để cập đến ở phần sau

RTP packet: Là gói dữ liệu RTP, bao gồm phần cố định RTP header, phần danh

sách các nguồn phân tán (có thể rỗng), phần RTP payload Một số giao thức tầng dưới

có thể yêu cầu phải đóng gói lại các gói RTP Thông thường 1 gói lớp dưới chứa 1 góiRTP 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àyhoà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óiRTCP Thông thường một số gói RTCP sẽ được ghép chung trong một gói của lớpdưới Điều này có thể thực hiện được do các gói RTCP có phần tiêu đề cố định

Port: Cổng địa chỉ UDP được sử dụng Đây là khái niệm trừu tượng mà các giao

thức truyền tải sử dụng để phân biệt các phiên truyền Với giao thức TCP/IP nó là sốnguyên dương 16Bit RTP dựa trên các cơ chế tương tự sự phân cổng được cung cấpbở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ểnRTCP 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ếthợp giữa địa chỉ IP với một cổng UDP nhất định Các gói tin sẽ được truyền từ địa chỉTransport address nguồn tới địa chỉ Transport address đích

RTP media type: Đây là một tập các loại tải có cùng một số tính chất được mang

trong phiên truyền RTP Trong hội thảo đa phương tiện ta có thể có hai loại RTP

media type là video-MPEG2 và audio-PCMA

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ộtdùng truyền gói RTP, một dùng truyền gói RTCP) Cặp địa chỉ đích có thể là chungcho 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ặcriêng biệt cho từng thành viên (trong trường hợp truyền điểm điểm unicast) Trongmột phiên truyền Multimedia, các tín hiệu thành phần (video/audio) được truyền theomột cặp cổng riêng

Hình 13 Mô hình phiên RTP.

Synchronization source (SSRC): nguồn phát dòng các gói RTP, được định danh

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

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

Hình 16 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ộ trongmộ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 17.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 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ễnphầ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ờigian chênh lệch do đó với chu kỳ như vậy là hoàn toàn thoả mãn.

.II 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ẽ:

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

Timestamp

SSRC

CSRC [0 15] :::

Hình 18 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ỉ sử dụng vào khi ta cho qua bộ Mixer Bây giờ ta sẽ phântích chức năng cụ thể của từng trường:

version (V): 2 bits

Trường này dùng để 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ònVerson 0 chỉ là giao thức để cài đặt thêm các chức năng cho Audio

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ệnphụ ở 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 dùng

để mã hoá mật gói tin, hoặc dùng trong trường hợp đóng gói nhiều gói RTP trong 1gói của lớp dưới

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 RTPkhi cần thiết

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

Marker (M): 1 bit

Bit này được sử dụng với mục đích báo hiệu Ta có thể dùng nó để làm sự kiện báohiệ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ườngpayload type

Payload type (PT): 7 bits

Trường này dùng để xác định dạng 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 takhông nên sử dụng 1 phiên RTP để truyền đồng thời các luồng media có định dạngkhá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ư:

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 dùng để 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ằmtă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

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 truyền tín hiệu Video thì Jitter có thể gây ra hiện tượngvấp hình

Tần số nhịp của nhãn thời gian phụ thuộc vào từng trường hợp cụ thể, thường doloạ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ácgói tin sẽ được truyền đi theo từng khối sau mỗi khoảng thời gian 20ms, tương ứngvớ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

SSRC: 32 bits

Trường này dùng 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ộtphiê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 suất mà nhiều nguồn phát chọn cùng một định danh là rất hiếm, nhưngchúng ta vẫn phải cài đặt cơ chế xác định và giải quyết sự xung đột này

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

CSRC:

Danh sách này được dùng vào do bộ Mixer Tại phía người nhận, nó được sử dụng

để 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 dùng

để 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 đượctố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ànhviê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 sử dụng thêm danh sách CSRC,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àotrong gói là của thành viên nào gởi

.III Ghép các phiên truyền RTP:

Trong giao thức RTP, việc ghép kênh được dựa trên các địa chỉ giao vận (transportaddress), đây là địa chỉ kết hợp giữa địa chỉ mạng và định danh cổng tham gia phiêntruyề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 2thà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ậnriê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ácgó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ớicùng giá trị SSRC Một luồng sẽ được coi là thay đổi cách mã hoá (dựa trên trườngpayload 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ỉ dùng một dãy nhãn thời gian và một chuỗi số thứ tự Trongkhi đó 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.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ãynhã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 địnhdạ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 địnhdạ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ưngkhi đó 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 từng loại dữ liệu chophù hợp với tài nguyên của mạng Không thể cho người sử dụng lựa chọn việc chỉnhận một loại dữ liệu (tiếng hoặc hình) Mà điều này khá cần thiết, khi một thành viêntham 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ápchỉ chấp nhận tín hiệu âm thanh

.IV Sự thay đổi 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ậpcác hàm cơ bản trong các ứng dụng RTP Tuy nhiên với một số yêu cầu nâng cao, tacầ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 từng ứng dụng Các trườngnày được đặt trong phần tiêu đề cố định, trong khi đó để dùng được cho rất nhiều ứngdụ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 tathê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ườnghợ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 từng 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 chức năng cài thêm không phụ thuộc vào loại định dạngtả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ôngtin trong trường được thêm.Trong khi đó các trường vẫn thực hiện đồng thời việc phântích 12 byte tiêu đề cố định

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 suốt đố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 dùng, khi mà đaphần người sử dụng đều sử dụng đến thành phần này thì nó sẽ được đưa vào phần tiêu

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

Defined by profile length

Header extension

Hình 19.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ốithêm vào phần tiêu đề cố định, sau phần danh sách CSRC (nếu có)

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 5

GIAO THỨC ĐIỀU KHIỂN RTP (RTCP:REAL

TIME 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 đíchtheo đú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 RTPtrên mạng cần có thêm một giao thức hỗ trợ Đó chính là giao 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 saoRTCP 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ứcnăng, cấu trúc và hoạt động của RTCP

.I Chức năng và hoạt động của giao thức 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ỗithà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ớpdướ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ểnRTCP đượ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 20 Hoạt động của RTCP

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

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 đổiphương pháp mã hoá (adaptive encoding) Trong trường hợp truyền IP multicast, 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ênkhá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 đó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 (canonicalname) Thông tin này giúp ta định danh một nguồn phát RTP (tương ứng với 1 thànhviên tham gia hội thảo)

Trong 1 phiên truyền RTP, khi giá trị SSRC của phía phát thay đổi có thể gây raxung độ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 để duytrì 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ườigởi Ví dụ, xác định một cặp tín hiệu video/audio của cùng một người gởi (vì 2 luồngnày có định danh SSRC khác nhau) Điều này giúp cho việc đồng bộ tín hiệu audiovới tín hiệu video

Việc đồng bộ cho từng luồng tín hiệu (video hoặc audio) được thực hiện dựa trêncá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.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 Dovậ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àoviệ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ỗithà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

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

Các chức năng đó 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ùnglớ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ườigởi, trong trường hợp sử dụng đường truyền đơn hướng

.II 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ô tả về các 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 tinRTP, tiếp theo là các thành phần cấu trúc, chúng có thể có chiều dài biến đổi tuỳ thuộcvà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 chochú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 nhauthà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óiRTCP, khi đưa chúng xuống đóng gói ở các lớp dưới Ví dụ như đóng trong các góiUDP

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ựavà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ì taphải thiết lập một số ràng buộc:

Các thông báo trạng thái (trong SR hoặc RR) phải được gởi đi định một cáchthườ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 (SR 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àygiúp cho việc định danh nguồn gởi, từ đó có thể thực hiện đồng bộ giữa các thànhphần (video/audio) Do vậy trong mỗi gói ghép RTCP cần phải có gói SDES chứaCNAME

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ự giatăng của các hằng số định kiểu, giá trị này được chứa trong 2 bytes

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óiRTCP 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ếutrường đệm (padding) được truyền theo mã mật thì nó sẽ được thêm vào ở gói cuốicù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ợptrong gói ghép chỉ chứa 1 gói BYE

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.

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ònmộ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 ứngdụ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 BYEnên nằm ở vị trí cuối cùng, với các giá trị SSRC/CSRC

Hình 21.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ể truyền được trong nhữnggó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

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ớiIANA (the Internet Assigned Numbers Authority)

.III Khoảng thời gian truyền các gói RTCP: (RTCP

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ếucá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ưulượ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átphả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êntiế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 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ềunà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ủanhà 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ớitừ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 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ườinhậ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 cácthà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 cho 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 chiều, hoặc cho những phiêntruyề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ầnquan 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ánhtrườ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ànhviê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átcá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 đặttrướ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 chophù 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ốngphụ 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útngắn khoảng thời gian gởi các gói RTCP ghép

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ẫnbê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ởinhanh 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ựatrê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:

trọng Để giải 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

giữ 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ácthành viên Gói RTCP đầu tiên được gởi sau khi thành viên tham gia phiên truyềncũ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 gianRTCP 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 đổilượ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 BYE đượ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 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.

.IV Cập nhật số thành viên tham gia phiên truyền:

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 thamgia trong phiên truyền Một thành viên mới sẽ được thêm vào biến đếm khi họ đượcnghe thấy Khi đó mỗi thành viên sẽ được thêm vào bảng được đánh số bởi định danhSSRC 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 RTCPBYE có kèm theo định danh SSRC tương ứng mà họ gởi đi được nhận Để tránhtrường hợp một gói tin lang thang đến sau gói BYE có thể tạo ra địa chỉ mới Mộtthành viên khi nhận được gói tin BYE sẽ đánh dấu lại sự nhận được đó và sẽ xoá địachỉ 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ộtkhoảng thời gian

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

.V Quy định đối với việc gửi và nhận gói tin 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ềnunicast đ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áisau:

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ệ session bandwidth được cung cấp

cho ứng dụng khi bắt đầu