TRUYỀN DÒNG DỮ LIỆU THỜI GIAN THỰC

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

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

1

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

2

đóng vai trò là máy truyền và một máy đóng vai trò là máy nhận Bên truyền được trang

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

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:

Dũng video/audio

3

Việc mã hoá video, mà cụ thể là nén video là một công đoạn không bắt buộc nhưng rất cần thiết Với các loại dữ liệu video thô như dữ liệu thu từ camera, thì việc lưu trữ hay truyền video không nén sẽ phải trả giá cao, đôi khi là điều không thể Ta lấy ví dụ với một định dạng tiêu biểu thường được sử dụng trong các ứng dụng hội nghị từ xa bằng video là định dạng CIF (Common Intermediate Format) CIF sử dụng độ phân giải

352 pixel mỗi dòng và 288 dòng tất cả Một ảnh không nén cho một frame hình (chế độ 352x288x16bpp) chiếm 202752 byte Việc ghi video không nén với tốc độ 15 hình một giây sẽ cần xấp xỉ 3 MB một giây và nếu truyền qua mạng thì băng thông cần thiết cho một dòng video không nén là 24 Mbps Từ ví dụ trên đây, ta thấy việc nén video gần như là không thể thiếu được nếu các dòng video được truyền trên môi trường mạng tốc

độ thấp Bảng sau cho biết độ nén cần thiết đối với từng môi trường mạng khác nhau:

Dạng kết nối Bit Rate Tỉ lệ nộn

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

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

4

Hình 0.3: 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ác khối nhỏ thích hợp để có thể truyền đi trong môi trường mạng Đối với các dữ liệu audio, việc lấy mẫu được thực hiện theo thời gian Tương ứng sau một khoảng thời 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á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

5

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

của các khung hình và việc lấy mẫu theo không gian sẽ được thực hiện bằng cách chia nhỏ các khung hình thành các phần với kích thước thích hợp đối với việc truyền đi.Khi lấy mẫu, các mẫu phải chứa đựng đầy đủ các thông tin dùng cho việc khôi phục lại dữ liệu video hay audio về cả mặt không gian cũng như thời gian khi bên nhận nhận được các mẫu này Với việc sử dụng một giao thức như giao thức truyền thông thời gian thực như RTP, quá trình lấy mẫu sẽ được tiến hành tự động.

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

Việc truyền các mẫu dữ liệu video có thể được thực hiện một cách trực tiếp thông qua các giao diện của môi trường mạng như Socket hay được thực hiện thông qua một giao thức cấp cao ở tầng ứng dụng như RTP Thông thường người ta sẽ chọn giải pháp thứ hai, tức là sử dụng một giao thức truyền dòng thời gian thực cho việc truyền các mẫu nếu như giao thức đó được hỗ trợ trên nền phần cứng cũng như phần mềm

Việc sử dụng một giao thức truyền dòng thời gian thực có nhiều ưu điểm Ưu điểm thứ nhất là tính hiệu quả, bởi vì các giao thức truyền thông thời gian thực được thiết kế cho việc truyền các loại dữ liệu động, như dữ liệu video chẳng hạn, khi đó tính thời gian thực sẽ được chú trọng hơn là tính chính xác về mặt dữ liệu Ví dụ như đối với giao thức RTP, giao thức truyền thông lớp dưới thường được sử dụng là UDP (User Datagram Protocol) là giao thức với độ tin cậy thấp nhưng có tốc độ truyền dữ liệu cao hơn các giao thức với độ tin cậy cao như TCP

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

dữ liệu từ các nguồn khác nhau nhưng có quan hệ với nhau về mặt thời gian thực Ví dụ như đối với việc truyền âm thanh và hình ảnh của cùng một sự vật, khi đó bên nhận khi thể hiện phải đảm bảo yêu cầu là âm thanh phải phù hợp với hình ảnh

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

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

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

6

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

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

7

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

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

8

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

1.3 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:

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

9

Sending

Application

TCPSecssionPresentation

IPDadalinkPhysical

IPDadalinkPhysical

IPDadalinkPhysical

Receiving

TCP End to End CommmunicationRouter Router

 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

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:

10

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.

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

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

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

SYN được thiết lập Nếu bit SYN được thiết lập thì Sequence Number là số hiệu tuần tự khởi đầu (ISN) và Byte dữ liệu đầu tiên là ISN+1 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

11

Bit 0 15 16 31

Sourse Port Destination Port

Sequence NumberAcknowledgment NumberData

ACK

PSH

RST

SYN

FI

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

Đây chính là số lượng các Byte dữ liệu bắt đầu từ Byte được chỉ ra trong vùng ACK number, mà trạm nguồn đã sẵn sàng để nhận

- Checksum (16bits): Mã kiểm soát lỗi (theo phương pháp CRC) cho toàn bộ

Segment

- Urgent Pointer (16 bits) : Con trỏ này trỏ tới số liệu tuần tự của Byte đi theo sau

dữ liệu khẩn, cho phép bên nhận biết được độ dài của dữ liệu khẩn Vùng này chỉ có hiệu lực khi bit URG được thiết lập

- Option (độ dài thay đổi): Khai báo các option của TCP, trong đó có độ dài tối đa

của vùng TCP data trong một Segment

- Padding (độ dài thay đổi): Phần chèn thêm vào Header để bảo đảm phần Header

luôn kết thúc ở một mốc 32 bits Phần thêm này gồm toàn số 0

Việc kết hợp địa chỉ IP của một máy trạm và số cổng được sử dụng tạo thành một

Socket Các máy gửi và nhận đều có Socket riêng Số Socket là duy nhất trên mạng.

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

12

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

1.2 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

13

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

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

14

dụng sử dụng ưu điểm của Multicast như là hội nghị video, truyền thông theo nhóm, lớp học từ xa, hoặc là để phân phối các phần mềm, các chỉ số chứng khoán và tin tức.

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

15

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

- 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

16

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

17

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

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

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.

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

18

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

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

20

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

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

21

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 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 and Video 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 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

22

Với việc truyền tách biệt này, cho phép một thành viên tham gia hội thảo thiết lập cơ chế chỉ nhận một luồng Audio hoặc Video Việc mất đồng bộ của tín hiệu hình và tiếng

sẽ được giải quyết dựa vào thông tin định thời trong các gói tin RTCP của hai luồng.Trên đây chúng ta đã giả định tất cả các thành viên đều cùng nhận 1 dạng format cho các dữ liệu Media Điều này không thể được trong trường hợp có thành viên sử dụng đường truyền tốc độ thấp, các thành viên khác lại sử dụng đường truyền có tốc độ cao Khi đó ta không thể bắt tất cả các thành viên cùng sử dụng truyền ở tốc độ thấp, chất lượng tín hiệu thấp

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

Bộ này sẽ tái đồng bộ các gói tin thoại, khôi phục lại chu kỳ 20ms của phía gởi Sau đó truyền lại dòng audio với tốc độ bit phù hợp với đường truyền Việc truyền lại này có thể sử dụng truyền Unicast cho một người nhận đơn, hoặc Multicast cho một nhóm người nhận Phần RTP header sẽ đảm nhiệm việc định danh lại người gởi phía nhận RTP-level còn có thể sử dụng để thay đổi độ phân giải của tín hiệu Video cho phù hợp với từng thành viên tham gia

Ngoài ra chúng ta còn kể đến trường hợp, một thành viên sử dụng đường truyền tốc

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

23

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

24

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

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)

25

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

26

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

27

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

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

1 version (V): 2 bits

Trường này _ing để 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 _ing cài đặt thêm các _ing 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 _ing để mã hoá mật gói tin, hoặc _ing 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

28

Bit này được _ing với mục đích báo hiệu Ta có thể _ing 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 _ing để xác định dạng _ing_t 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 _ing 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ư:

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 _ing để phát hiện số lượng gói đã bị mất

29

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.

Tần số nhịp của nhãn thời gian phụ thuộc vào _ing 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 _ing 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 _ing 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 _ing 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)

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 _ing vào do bộ Mixer Tại phía người nhận, nó được _ing để 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 _ing

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

30

đ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 _ing 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:

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

- 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

31

Để 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 _ing 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 _ing 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 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 _ing ứng dụng Các trường này được đặt trong phần tiêu đề cố định, trong khi đó để _ing đượ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 _ing 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 _ing 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 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 _ing đối với các hàm không được cài đặt cơ chế mở rộng

32

Chú ý rằng, phần mở rộng này chỉ dành cho một số người người _ing, khi mà đa

phần người sử dụng đều _ing đến thành phần này thì nó sẽ được đưa vào phần tiêu đề

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

33

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

 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

34

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

 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

35

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

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

36

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

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

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

37

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

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 thông có

38

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 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 chiều, hoặc cho những phiên truyền

39

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

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

40