Bài tập lớn mạng máy tính lập trình mô phỏng hoạt động của giao thức RTP

MỤC LỤC
Danh mục hình ảnh .......................................................................................................... 3
Danh mục bảng biểu......................................................................................................... 4
MỞ ĐẦU .......................................................................................................................... 5
Chương 1: Truyền dòng trong thơi gian thực .................................................................. 6
1.1

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

1.2. Quá trình truyền dòng ........................................................................................... 6
Bước 1: Mã hóa ........................................................................................................ 7
Bước 2: Lấy mẫu ...................................................................................................... 9
Bước 3: Truyền các mẫu qua mạng. ........................................................................ 9
Bước 4: Nhận và khôi phục dữ liệu và đồng bộ các dòng ..................................... 10
Bước 5: Giải nén .................................................................................................... 11
Chương 2: Giao thức RTP (RealTime Transport Protocol) ........................................... 12
2.1. RTP- RealTime Transport Protocol .................................................................... 12
2.2. Một số khái niệm liên quan đến RTP .................................................................. 13
2.3. Hoạt động của giao thức ..................................................................................... 17
2.3.1. Sender ........................................................................................................... 17
2.3.2. Receiver........................................................................................................ 17
2.4. Đặc điểm của cơ chế .......................................................................................... 17
2.5. Kiến trúc gói dữ liệu header RTP ....................................................................... 19
Chương 3: RCTP ............................................................................................................ 21
Chương 4 : Một số thuật toán được sử dụng .................................................................. 22
4.1. Phân phối các định danh SSRC........................................................................... 22
1


4.1.1. Xác xuất xảy ra xung đột ................................................................................. 22
4.2. Vấn đề bảo mật trong RTP .................................................................................. 23

4.2.1. Khả năng che giấu dữ liệu ............................................................................ 23
4.2.2. Nhận thức và bảo toàn dữ liệu ..................................................................... 24
4.3. Điều khiển tắc nghẽn. .......................................................................................... 24
KẾT LUẬN .................................................................................................................... 25
TÀI LIỆU THAM KHẢO .............................................................................................. 26

2


Danh mục hình ảnh
Hình 1: Quá trình truyền dòng ......................................................................................... 7
Hình 2: Sự phát triển của các chuẩn nén .......................................................................... 8
Hình 3: Mô hình phiên RTP(RTP session) .................................................................... 14
Hình 4: Minh họa các đồng bộ nguồn(Synchroization soure) ....................................... 15
Hình 5: Hoạt động của bộ Mixer.................................................................................... 15
Hình 6: Minh họa việc chèn danh sách CSRC khi đi qua bộ Mixer. ............................. 16
Hình 7: Mã hóa gói tin RTP trong gói IP ....................................................................... 18

3


Danh mục bảng biểu
Bảng 1: Băng thông mạng và tỉ lệ nén yêu cầu ................................................................ 7

4


MỞ ĐẦ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, giờ đây mạng máy tính đã trải rộng trên toàn cầu với đường truyền có chất lượng

cao. Ngoài ra tính bảo mật và độ 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 những buổi hội thảo trực tuyến, trong đào tạo từ
xa trên mạng, trong dịch vụ audio/video theo yêu cầu… Tuy 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, chum giao thức TCP/IP hiện
đang được sử dụng rất phổ biến không thể đáp ứng nhu cầu này. Do vậy đòi hỏi các
chuyên gia mạng phải tìm 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 nhu 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 là lý do chính chúng em chọn đề tài này.

5


Chương 1: Truyền dòng trong thơi gian thực
1.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 mad không cần
phải đợi đến khi toàn bộ nội dung của audio hay video được truyền xong.
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 audio hoặc
video có kích thước lớn hay các dòng video hoặc audio có độ dài không xác định.
Chúng ta có thể bắt gặ 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
audio , video thông qua mạng, chúng ta có thể 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 được truyền đi theo thời gian thể hiện nội dung của video đó. Bên
nhận, khi nhận dòng tin nội dung video có thể hiển thị 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 vào thời gian,
bởi để đảm bảo chất lượng cảm thụ video, audio tì phải đảm bảo được mối quan hệ về
mặt thời gian giữa những khung hình.
1.2. Quá trình truyền dòng
Truyền dòng đối với audio và video phải trải qua nhiều công đoạn với từng nhiệm
vụ riêng lẻ để đi đến kết quả cuối cùng là đạt được khả năng hiển thị ngay ở bên nhận

6


Hình 1: Quá trình truyền dòng
Các bước truyền dòng:
Bước 1: Mã hóa
Việc mã hóa 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ô (video thu được từ camera) thì việc lưu trữ
dữ liệu hay truyền video không nén sẽ phải trả giá cao, đôi khi là không thể.
Có bảng 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

Tốc độ Bit (Bit Rate)

Tỉ lệ nén

OC3

155 Mbps

1:1

T3

42 Mbps

4:1

Ethernet

10 Mbps

17:1

T1

1.5 Mbps

110:1

ÍSDN

128 Kbps

1300:1

Modem

56 Kbps

3000:1

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


Có thể sử dụng nhiều chuẩn nén khac nhau cho việc nén video. Tùy theo yêu cầu
chất lượng và băng thông , mà ta có thể chọn lựa được phương pháp nén thích hợp. Với
việc sử dụng một chuẩn nén video cho dữ liệu video , không gian lưu trữ cần thiết cũng
như bang thông mạng yêu cầu cho dòng video giảm đột ngột. 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
-

H.261 :một kĩ thuật với tốc độ dòng bit nhỏ được đưa ra sử dụng vào năm 1984
bởi ITU sử dụng trong các dịch vụ audio-visal

-

MPEG-1: Chuẩn ISO, ứng dụng trong ngành công nghệ quảng bá . MPEG-1 được
tạo ra như một sự sửa đổi của H.261 cho việc chuyển video vào đĩa CD với tốc
đọ 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ác sử
dụng tỉ lệ nén thấp

8

-

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 được 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 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 đó tà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
Trasform) ban đầu được phát triển cho việc nén nanh, nay được áp dụng cho cả
video.

-

H.264: Mở rộng của H.263 hiện chưa được phát triể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 thành các

khối nhỏ thích hợp 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 cho 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ó cả việc lấy
mẫu qua không gian. Việc lấy mẫu theo thời gian sẽ tương ứng với thời gian thể hiện
của 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 dung cho việc khôi
phục lại dữ liệu video hay audio về cả mặt thời gian cũng như không 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 mẫu dữ liệu video có thể được thể hiện trực tiếp thông qua giao diện
của môi trường mạng như Socket hay thực hiện qua một giao thức cấp cao ở tầng ứng
dụng như RTP. Thông thường người ta sẽ chon giải pháp thứ 2, tức là sử dụng một giao
9


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 đó hỗ trợ
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. 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ư 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 truyền
tin cậy khác như TCP. Ưu điểm thứ 2 là các giao thức thời gian thực hỗ trợ mạnh về việc
đồng bộ các dòng dữ liệu từ các nguồn khác nhau nhưng có qua hệ với nhau về mặt thời
gian thực.
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ưe 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 tín sẽ mạng đầy đủ cấc thông tin
như nhan thời gian , số thức tự của gói và các thông tin khác đủ dung cho việc khôi phục
lại dữ liệu và đồng bộ các dòng khi bên nhận tiến hành nhận hay thể hiện nội dung của
video hay audio. Thông qua các giao thức lớp dưới, các gói tin sẽ được truyền đi trong
môi trường mạng.
Bước 4: Nhận và khôi phục dữ liệu và đồng bộ các dòng
Đây là quá trinh ngược với bước thứ ba, được thực hiện ở bên nhận dữ liệu dưới
dạng các gói tin truyền đến . Các gói tin được chuyể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ó tế thứ tự các gói nhận được sẽ không
giống với lúc nó truyền đ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 để có thể xác đinh được vị trí về mặt khong gian và thời gian của các mẫu dữ
liệu mà các gói tin mang theo. Việc truyền các dòng đơn lẻ không có quan hệ với nhau
về mặt thời gian thì nội dung của audio hay video vừa được khôi phục có thể được dùng

10


để trình diễn. Còn trong trường hợp có nhiều dòng khác nhau có quan hệ với nahu về
mặt thời gian thực thì cần phải dồng bộ 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ư 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 cho phù hợp nhau nhất. Việc đồng bộ là một việc phức tạp,
thường được thể 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ù các gói tin nhận được có thể không giống nhau như thứ tự được gưi đ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 đò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 audio/video với chuẩn đã được sử dụng khi

nén dữ liệu. Dữ lieu sau khi được giải nén có thể được thực hiện ra các thiết bị hay được
ghi ra file

11


Chương 2: Giao thức RTP (RealTime Transport Protocol)
2.1. RTP- RealTime Transport Protocol
Phương thức thông thường để truyền dữ liệu dạng audio hay video cùng các dữ liệu
đính kèm và khung truyền là RTP. RTP nhằm mục tiêu cung cấp các dịch vụ truyền tải
hình ảnh thời gian thực như audio/video thông qua mạng (IP Network)
Các dịch vụ đó bao gồm các khôi phục dữ liệu sau khoảng thời gian xác
định(Timing Recovery), tìm lỗi và sửa lỗi (loss detection anh correction), định dạng
khung truyền và nguồn (payload and source identifition), tiếp nhận phản hồi về chất
lượng dịch vụ(reception quality feedback), đồng bộ dữ liệu (media synchroization) và
quản lí thành viên (membership management) .RTP được thiết kế để dùng trong trao đổi
quảng bá (multicast conferences) dùng cơ chế lightweight sessions.
Nó tỏ ra hữu ích trong hàng loạt các ứng dụng: hội nghị truyền hình dùng cơ chế
H323, webcasting, truyền hình, hệ thống thoại có dây và không dây. Bằng việc
dùng giao thức này mỗi phiên truyền tải được gửi đến hàng nghìn người
RTP được coi là chuẩn đóng gói để truyền tải dữ liệu dạng audio và video qua mạng
Internet. Nó được pháy triển bởi Audio-Video Traansport Working Group và được công
bố lần đầu năm 1996 là RFC 1889. Sau này RFC 3550 vào năm 2003
RTP thường được dung trong hệ thống truyền thông cùng với RTSP để thực hiện
hội nghị truyền hình và hệ thống thoại. Nó chứa dòng dữ liệu được điều khiển bởi H323,
MGCP và SIP. Đó là nền tảng công nghệ cho kiến trúc Voice IP
RTP thường được dung kết hợp với RTCP. Trong khi RTP truyền dữ liệu out-ofband signal (DTMF) . RTCP được dung để điều khiển trạng thái truyền và chất lượng
dịch vụ QoS. Khi được dung kết hợp RTP thường được sắp xếp nhận trên cổng chẵn,
RTCP trên cổng lẻ.
RTP ban đầu được tạo là giao thức multicast nhưng nó vẫn chấp nhận trong nhiều

ứng dụng unicast. Trong truyền thông dạng host-to-host, RTP và RTCP thường dung
UDP qua cá giao thức ở lớp vận chuyển.

12


Số hiệu cổng: RTP không thao tác trên các cổng mặc định như TCP và UDP. Tuy
nhiên nó thường dung các cổng số hiệu chẵn, có giá trị từ 16384 – 32767, dải địa chỉ này
đang dần được mở rộng. Việc này gay khó khan trong trường hợp có tường lửa (firewall)
và NATs. Để giải quyết vấn đề này, nó cần khởi tạo STUN server.
2.2. Một số khái niệm liên quan đến RTP
1. RTP payload: Đây là phần dữ liệu được truyền trong gói RTP, đây có thể là các
mẫu tín hiệu thoại hoặc video đã được nén.
2. RTP packet: là gói dữ liệu RTP , gồm phần cố định RTP header, phần sanh 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.
3. RTCP packet : Đây là gói tín hiệu điều khiển RTCP, có phần tiêu đề cố định gần
giống với gói RTP. Tiếp theo đến phần có cấu trúc , dạng của cấu trúc sẽ phụ
thuộc vào loại 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
4. 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 16bits/ Khái niệm port tương đương với khai 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à các gói tin điều khiển RTCP trong mỗi phiên truyền.
5. Transport address: Địa chỉ này phục vụ việc vận chuyển dữ liệu. Nó là sự kết hơp
giữa địa chỉ mạng và địa chỉ cổng được định nghĩa ở các tầng giao vận.

6. RTP media type: Đây là một tập các loại tải có cung 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ể dùng hai loại
RTP media type là video-MPEG2 và audio-PCMA.
7. 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
13


(một dùng truyền gói RTP, một dùng truyền gói RTCP). Cặp địa chỉ đích có thể
là chung cho tất cả các thành viên còn lại(trong trường hợp truyền đa điểm
multicast) hoặc riêng 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: Mô hình phiên RTP(RTP session)
8. Đồng bộ nguồn (Synchroization source)(SSRC) : Nguồn phát dòng các gói RTP,
được định danh bởi 32-bits 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 từ một nguồn được đánh 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 vị trên
toàn mạng, nó được khởi tạo một cách ngẫu nhiên.

14


Hình 4: Minh họa các đồng bộ nguồn(Synchroization soure)
9. Bộ trộn (Mixer ) : đâ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 một
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 với mỗi luông ra. Mixer
khi hoạt động sẽ có vai trò như một nguồn đồng bộ

Hình 5: Hoạt động của bộ Mixer
10. Contributing source (CSRC): khi dòng các gói RTP được tổng hợp nhờ bộ Mixer.
Bộ Mixer sẽ chèm thêm một danh sách CSRC chứa các định dan của 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

15


Hình 6: Minh họa việc chèn danh sách CSRC khi đi qua bộ Mixer.
11. Hệ thống cuối (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 nhiều nguồn
đồng bộ trong một phiên RTP., tùy thuộc vào số định danh SSRC mà nó sử dụng
12. Bộ dịch (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
13. Non-RTP means: Dùng để chỉ các giao thức hay các cơ chế được dùng kết hợp
với RTP để tạo ra những dịch vụ cụ thể, cụ thể.
14. Tem thời gian (TimeStamp): Được sử dụng theo quy định giao thức thời gian
mạng (Network Time Protocol), thời gian tính bằng s kể từ 0h (UTC) ngày 1-11900. 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 32bits ở giữa, khí đó sẽ có sự phân biệt giữa 16bits cao của phần
nguyên và 16 bits cao của phần thập phân. Với cách tính thời gian theo NTP, đến
năm 2036 nó sẽ quay trở lại giá trị zero. Tuy nhiên ứng 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 thỏa mãn.

16


2.3. Hoạt động của giao thức
2.3.1. Sender
- Bên gửi có nhiệm vụ lưu trữ và biến đổi dữ liệu dạng nghe nhìn để truyền tải . RTP
tham gia vào quá trình sửa lỗi và điều phối tránh tắc nghẽn bằng cách thêm vào dòng dữ
liệu truyền tải thông tin phản hồi của bên nhận
- Các khung truyền được nạp vào các gói RTP và sẵn sang gửi. Nếu khung truyền quá
lớn nó sẽ được chia thành nhiều gói RTP. Tùy thuộc vào lược đồ sửa lỗi được sử dụng,
1 Chanel coder được sử dụng để tạo ra các gói sửa lỗi hoặc các gói lặp lại trước khi
truyền.
- Sau khi các gói RTP được gửi bộ đệm dữ liệu tương ứng với nó được giải phóng. Bên
gửi không hủy các dữ liệu cần cho quá trình sửa lỗi hoặc mã hóa. Có nghĩa là bên thu
phải lưu trữ dữ liệu trong một khoảng thời gian sau khi các gói tin tương ứng được gửi,
tùy thuộc vào sơ đồ mã hóa và sửa lỗi được dung.
- Bên gửi có trách nhiệm tạo các bản báo cáo trạng thái định kì về dòng dữ liệu để đồng
bộ dữ liệu. Nó cũng nhận thông tin phản hồi từ các bên tham gia và dung thông tin đó
để tham gia vào quá trình truyền.
2.3.2. Receiver
- Bên nhận có trách nhiệm thu nhận các gói RTP từ mạng, sửa lỗi, recovering the timing,
cắt bớt dữ liệu và hiển thị kết quả cho người dung. Nó gửi phản hồi chất lượng cho bên
gửi. Cơ sở dữ liệu của các bên được duy trì trong một phiên truyền.
2.4. Đặc điểm của cơ chế
RTP không có sẵn các cơ chế để đảm bảo việc truyền theo thời gian hay các kĩ
thuật về QoS mà dựa vào các dịch vụ ở lớp dưới để thực hiện những khả năng này. RTP
không đảm bảo an toàn hay thứ tự các packet khi truyền, số thứ tự trong RTP packet cho
phép bên nhận sắp xếp lại các packet theo thứ tự khi truyền của người gửi. Ngoài ra số
thứ tự cũng có thể được tận dụng để xác định vị trí thích hợp của một packet, ví dụ trong
việc giải mã video, mà không cần giải mã các packet theo thứ tự

17


Các gói tin truyền trên mạng Internet có trễ và jitter không đoán được. Nhưng các
ứng dụng đa phương tiện yêu cầu một thời gian thích hợp khi truyền các gói dữ liệu và
phát lại. RTP cung cấp các cơ chế đảm bảo thời gian, số thứ tự và các cơ chế liên quan
đến thời gian
Bằng các cơ chế này RTP cung cấp sự truyền tải thời gian thực giữa các đầu cuối
của mạng. Tem thời gian thực (Time-Stamping) là thành phần quan trọng các ứng dụng
thời gian thực. Người gửi thiết lập các “tem thời gian” tăng dần theo thời gian với mỗi
gói. Sau khi nhận được gói dữ liệu bên thu sử dụng các tem thời gian này nhằm khôi
phục lại thời gian để chạy các ứng dụng với tốc độ thích hợp. Ngoài ra nó được sử dụng
để đồng bộ các dòng dữ liệu khác nhau (chẳng hạn như giữa hìn và tiếng). Tuy nhiên
RTP không thực hiện dồng bộ mà các ứng dụng phía trên sẽ thực hiện đồng bộ này. Bộ
phận dạng tải xác định kiểu định dạng của tải tin cũng như các phương cách mã hóa nén.
Từ các bộ phận định đạng này , các ứng dụng phía trên biết cách phân tích và chạy dữ
liệu tải tin. Tại một thời điểm bất kì trong quá trình truyền tin, các bộ phân RTP chỉ có
thể gửi một dạng của tải tin có thể thay đổi trong thời gian truyền (thay đổi để thích ứng
với sự tắc nghẽn của mạng).
Một chức năng khác mà RTP có là xác định nguồn. Nó cho phép các ứng dụng thu
biết được dữ liệu từ đâu. Ví dụ, thoại hội nghị, từ thông tin nhận dạng nguồn một ngườ
sử dụng có thể biết được ai đang nói
UDP header

RTP header

RTP playload

Hình 7: Mã hóa gói tin RTP trong gói IP

Các cơ chế hoạt động nêu trên được thực hiện thông qua mào đầu của RTP. Cách
mã hóa gói tin RTP trong các gói tin IP được mô tả trong hình trên: RTP nằm ở phía trên
UDP, sử dụng các chức năng ghép kênh và kiểm tra của UDP. UDP và TCP là hai giao
thức sử dụng chủ yếu trên Internet. TCP cung cấp kết nối định hướng và các dòng thông
tin với độ tin cậy thấp với hai trạm chủ.
Sở dĩ UDP được sử dụng làm thủ tục truyền tải cho RTP là bởi hai lý do:

18


-

Thứ nhất, RTP được thiết kế chủ yếu cho việc truyền tin đa đối tượng, các kết nối
có định hướng, có báo nhận không đáp ứng tốt điều này.

-

Thứ hai, đối với dữ liệu thời gian thực, độ tin cậy không quan trọng bằg truyền
đúng theo thời gian. Hơn nữa sự tin cậy trong TCP là do cơ chế báo phát lại không
thích hợp cho RTP. Ví dụ khi mạng bị tắc nghẽn một số gói dữ liệu sẽ bị mất,
chất lượng dịch vụ thấp nhưng vẫn chấp nhận được. Nếu thực hiện việc phát lại
sẽ gây ra độ trễ lớn chất lượng thấp gây ra sự tắc nghẽn của mạng.

2.5. Kiến trúc gói dữ liệu header RTP
RTP header có kích thước tối thiểu là 12 octet

Hình 2: Kiến trúc gói dữ liệu
-

Ver (2 bit) : Cho biết version của giao thức. Hiện tại đang là version 2.

-

P (Padding): được dùng để cho biết có byte mở rộng thêm vào cuối gói RTP.

-

X(Extension): (1 bit) cho biết sự có mặt của Extension header và payload data.

-

CC (CSRC Count_4 bỉt): tổng số CSRS đã được định nghĩa thêm vào header.
19


-

M(Marker_ 1 bit): được dùng trong các mức ứng dụng và được định nghĩa bởi 1
profile. Nếu nó được khởi tạo dữ liệu có liên quan đặc biệt đến ứng dụng.

-

PT (Payload Type): Cho biết khuôn dạng payload và xác định giới hạn của nó
trong ứng dụng.

-

Sequence Number : số thứ tự tăng dần trong mỗi ứng dụng RTP đã được gửi và
được dùng để biên nhận sửa lỗi và lưu trữ lại số thứ tự gói tin.

-

Time Stamp: phản ánh sampling instant của dữ liệu trong gói RTP. Nó tăng dần
và tuyến tính để đồng bộ dữ liệu và tính jitter. Số liệu đó phải đủ để đồng bộ chính
xác và tính được jitter, thông thường 1 tick trên 1 khung truyền video là không đủ
để tính. Tần số của đồng hồ phụ thuộc vào khung dữ liệu. Giá trị mặc định khi
khởi tạo là 0.

-

SSRC (32 bits): Đồng bộ nguồn dữ liệu xác định duy nhất một dòng dữ liệu vào.

-

CSRC: Đếm số các nguồn vào từ nhiều nguồn khác nhau.

-

Extension header: 32 bit đầu bao gồm 16 bit định danh chương trình và 16 bit xác
định độ dài phần mở rộng (EHL=extension header length ), thêm 32 bit mở rộng.

20


Chương 3: RCTP
RCTP (Real-time Transport Control Protocol)là giao thức hỗ chợ cho RTP cung
cấp các thôngtin phản hồi về chất lượng truyền dữ liệu. Cácdich vụ mà RCTP cung cấp
là:
-

Giám sát chất lượng và điều khiển tắc nghẽn: Đây là chức năng cơ bản của RCTP.
Nó cung cấp thông tin phản hồi đến một ứng dụng về chất lượng phản hồi dữ liệu.
Thông tin điều khiển này rất hữu ích cho các bộ phát, bộ thu và giám sát. Bộ phát
có thể điều chỉnh cách thức truyền dữ liệu dựa trên các thông báo phản hồi của
bộ thu. Bộ thu có thể xác định được tắc nghẽn là cục bộ, từng phần hay toàn bộ.
Người quản lý mạng có thể đánh giá được hiệu suất mạng.

-

Xác định nguồn: Trong các gói RTP, các nguồn được xác định bởi các số ngẫu
nhiên có độ dài là 32 bit. Các số này không thuận tiện với người sử dụng RCTP
cung cấp thông tin nhận dạng cụ thể hơn dạng văn bản. Nó có thể bao gồm tên
nguời sử dụng, số điện thoại, địa chỉ E-mail và các thông tin khác... Đồng bộ môi
trường: Các thông báo của bộ phận phát RTCP chứa thông tin để xác định thời
gian RTP tương ứng. Chúng có thể được sử dụng để đồng bộ giữa âm thanh và
hình ảnh.

-

Điều chỉnh thông tin điều khiển: Các gói RTCP được gửi theo chu kỳ giữa những
người tham dự. Khi số người tham dự tăng lên, cần phải cân bằng giữa việc nhận
thông tin điều khiển mới nhất và hạn chế dung lượng điều khiển. Để hỗ trợ một
nhóm người điều khiển lớn, RCTP phải chấm dứt điều khiển rất lớn đến từ các tài
nguyên của mạng. RTP chỉ cho phép tối đa 5% lưu lượng cho điều khiển toàn bộ
lưu lượng của phiên làm việc. Điều này được thực hiện bằng cách điều chỉnh tốc
độ phát của RCTP theo số lượng người tham dự.

21

Chương 4 : Một số thuật toán được sử dụng
4.1. Phân phối các định danh SSRC
Định danh SSRC được mạng trong phần tiêu đề RTP cũng như trong nhiều trường
khác của gói RTCP là một số ngẫu nhiên 32bit. Giá trị của nó phải hoàn toàn là suy nhất
trong một phiên RTP. Điều cốt yếu là làm thế nào để chọn ra các giá trị định danh SSRC
để cho các thành viên trong cùng một mạng hay cùng bắt đầu vào cùng một thời điểm là
không giống nhau.
Sẽ không thỏa mãn nếu như ta sử dụng đia chỉ của mạng cục bộ để định danh vì có
thể địa chỉ này là không duy nhất. Ngoài ra khí các bộ “translators” và “Mixer” xử lý
trong các liên mạng. Nếu các liên mạng này phân chia địa chỉ theo một quy tắc nào đó
thì khả năng xảy ra xung đột sẽ cao hơn so với việc phân chia một cách ngẫu nhiên.
Việc nhiều nguồn cùng chạy trên một máy chủ cũng có thể gây ra xung đột.
Tuy nhiên, việc xác định SSRC cũng không chỉ đơn giản là cứ chọn một giá trị
ngẫu nhiên mà khong quá tâm đến trạng thái khi khởi tạo.
4.1.1. Xác xuất xảy ra xung đột
Khi các giá trị SSRC được chọn một cách ngẫu nhiên, sẽ có thể xảy ra khả năng
nhiều hơn mọt nguồn chọn cùng một giá trị, dẫn đến xung đột.. Xác xuất xảy ra xung đột
sẽ cao hơn nếu tại mốt thời điểm có nhiều người bắt đầu đồng thời
Giả sử có N nguồn tham gia, mỗi nguồn sử dụng định danh có độ dài L-bit(ở đây
sử dụng 32 bit ) , khi đó xác xuất hai nguồn độc lấp cùng chọn một giá trị sẽ được tính
gần đúng khi N rất lớn như sau
PCollision  1  exp( N2 / 2L1 )

Nếu N = 1000, L= 32 bits, thì PCollision  104 khá nhỏ. Nhưng trong thực tế nó còn
nhở hơn, bởi vì một nguồn tham gia vào một phiên RTP mà trong đó đã tồn tại sẵn một
số nguồn khác với các giá trị định danh hợp lệ rồi, xác xuất xảy ra xung đột chỉ sẽ được
tính trên khoảng giá trị con trống.

22

Khi đó nếu N là số nguồn, L là chiều dài của phần định danh thì xác xuất xung đột
sẽ là : PCollision  N / 2L , nếu N= 1000 thì PCollision  2.107 ,rất nhỏ.
Xác xuất xung đột còn có thể giảm được nữa khi mà một nguồn mới được nhận các
gói tín từ nguồn khác trước khi nó gửi đi gói tin đầu tiên của mình(RTP hoặc RTCP).
Nguồn mới kiểm tra xem các giá trị SSRC của những nguồn khác, trước khi phát đi gói
số liệu đầu tiên, nó kiểm tra xem SSRC của mình có xung đột với nguồn sẵn có nào
không. Nếu có thì chọn lại giá trị mới một cách ngẫu nhiên.
4.2. Vấn đề bảo mật trong RTP
Các giao thức lớp dưới có thể cung cấp tất cả các dịch vụ bảo mật cần thiết cho một
ứng dụng RTP, bao gồm chức măng xác thực,tính toàn vẹn và khả năng che dấu dữ liệu.
Những dịch vụ này được chỉ định ở lớp IP. Khi khởi tạo một ứng dụng audio và video
dùng RTP cần che dấu dữ liệu trước khi được đưa xuống lớp IP, ta sử dụng che dấu dữ
liệu của các gói RTP/RTCP
4.2.1. Khả năng che giấu dữ liệu
Che dấu dữ liệu có nghĩa là chỉ người nhận mong đợi mới có thể giải mã được gói
tin, đối với những người nhận khác gói tin không cung cấp một thông tin hữu ích nào.
Để che dấu dữ liệu nội dung của gói tin ta sử dụng mã mật
Với cách mã hóa gói RTP và RTCP được đề ra thì tất cả các octets sẽ được đồng
bộ để truyền trong một gói đơn ở giao thức lớp dưới và được mật mã hóa thành một khối
dữ liệu hoàn chỉnh.
Đối với mỗi gói RTCP, một số 32bits ngẫu nhiên,sẽ được gắn thêm trước khi được
mã hóa. Đối với các gói RTP ta không nên thêm gì nhưng sẽ khởi tạo các trường số thứ
tự và nhãn thời gian trong khoảng ngẫu nhiên.
Ngoài ra đối với gói RTCP, có thể chia những gói RTCP đơn lẻ trong 1 gói ghép
RTCP thnahf 2 gói RTCP ghép. Sau đó một gói sẽ được mã hóa còn một gói sẽ được
truyền trực tiếp.

23

Để kiểm tra gói tin có được mật mã hay không và để kiểm tra xem khóa giải mã có
đúng không,sẽ đượcthể hiện tại bên nhận thông qua kiểm tra sự hợp lệ của phần tiêu đề
đề tài.
Thuật toán được sử dụng cho việc mã hóa được dùng là DES (Data Encryption
Standard algorithm) .
4.2.2. Nhận thức và bảo toàn dữ liệu
Dịch vụ nhận thực và bảo toàn dữ liệu không được thực hiện ở lớp RTP nó sẽ được
thực hiện ở các giao tầng dưới
4.3. Điều khiển tắc nghẽn.
Mọi giao thức truyền tải được sử dụng trên Internet phải cung cấp khả năng điều
khiển tắc nghẽn bằng một vài cách nào đó. Giao thức RTP cũng không là một ngoại lệ,
tuy nhiên dữ liệu truyền tải bằng giao thức RTP thường có tốc độ khó thay đổi. Các
phương tiện dùng để điều khiển tắc nghẽn của RTP có thể hới khác biệt so với các giao
thức truyền tải khác như TCP. Theo một cách nào đó,việc không thể thay đổi tốc độ của
RTP làm giảm nguy cơ gây tắc nghẽn, bởi vì luồng RTP sẽ không trải hết khoảng bằng
thông như giao thức TCP. Việc không thay đổi tốc độ truyền của luồng RTP có nghĩa
là không thể giảm tải trên mạng khi xảy ra tắc nghẽn.
Do RTP có thể sử dụng trong nhiều ứng dụng khác nhau, trong nhứng ngữ cảnh
khác nhau, nên không thể có một cơ chế điều khiển tức nghẽn nào có thể sử dụng chi tất
cả. Vì thế việc điều khiển tắc nghẽn sẽ được định nghĩa trong từng ứng dụng RTP cụ thể
cho phù hợp hơn.
Một số loại ứng dụng có thể cài đặt một số câu lệnh hạn chế người dùng để tránh
tắc nghẽn.
Một số loại ứng dụng khác có thể được sử dụng những cơ chế thay đổi tốc độ dữ
liệu dựa trên những thông tin hồi đáp từ RTCP

24

KẾT LUẬN
Hiện nay ở Việt Nam, tuy các ứng dụng RTP chưa phát triển, nhưng trong một thời
gian ngắn nữa chắc chắn nó sẽ là một lĩnh vực nghiên cứu sôi động. Nếu có một nghiên
cứu hoàn chỉnh, đầy đủ về RTP là một điều rất có ý nghĩa thực tế. Tuy nhiên do thời gian
có hạn, những gì bọn em làm chỉ là nghiên cứu và mô phỏng cơ bản về RTP. Tuy ứng
dụng còn nhiều hạn chế, nhưng dẫu sao nó cũng khẳng định sự đầu tư tìm hiểu của chúng
em là có hiệu quả.
Chúng em hi vọng sau này nếu có điều kiện, em sẽ tìm hiểu sâu hơn nữa về giao
thức RTP, và hoàn thiện chương chình của mình tốt hơn.
Một lần nữa, chúng em xin cảm ơn thầy Trần Quang Vinh đã tận tình hướng dẫn,
khích lệ và tạo điều kiện thuận lợi, giúp đỡ em trong quá trình thực hiện!

25