RTP và RTCP

Nhóm 3
Nguyễn Trường Giang B17DCVT106
Trương Kim Tài B17DCVT314
Phạm Thanh Hưng B17DCVT162
Nguyễn Xuân Tiệp B17DCVT354
 I. Tại sao cần giao thức RTP và RTCP
• Các ứng dụng phương tiện (Multimedia/Media Application) ở tầng
ứng dụng (trong mô hình OSI hay mô hình TCP/IP) cần phải đảm
bảo những tính chất khắt khe về thời gian thực, không cho phép độ
trễ quá lớn gây ảnh hưởng tương tác người dùng với chúng. Để
thực hiện cần đảm bảo 1 số điều như sau:

• Có khả năng thử lỗi: có thể chấp nhận mất 1 số gói tin bị lỗi, mất
mát.

• Cần phải kết hợp các thông số về thời gian: điều này có lí do khá ró
ràng do các dữ liệu đa phương tiện luôn liên quan tới miền thời
gian và nhu cầu đảm bảo tương tác thời gian thực của người dùng.

• Hộ trợ định tuyến đa điểm (multicast): điều này không có ý nghĩa

nhiều khi tương tác chỉ dừng lại ở mức độ điểm-điểm (unicast),
nhưng nhu cầu của con người không chỉ dừng lại ở đó.
• Sử dụng giao thức TCP hay UDP để truyền tải dữ liệu đa phương
tiện rất không thuận lợi.

• TCP là giao thức tin cậy, vì vậy có tính thử lỗi rất tốt. Tuy nhiên
TCP là giao thức hướng kết nối, và cơ chế hộ trợ tin cậy khiến nó
chậm chạp .
• UDP thì gần như ngược lại TCP khi không phải là giao thức không
hướng kết nối, gửi dữ liệu theo phương pháp best-effort, vì vậy nó
có thể truyền dữ liệu với tốc độ rất nhanh.

• Tốc độ truyền dữ liệu của TCP quá chậm so với nhu cầu, hơn nữa
không có hỗ trợ multicast nên người ta đã lựa chọn phương án sử
dụng UDP kết hợp với 1 giao thức tầng trên để khắc phục được các
nhược điểm của UDP trong truyền dữ liệu thời gian thực nhưng vẫn
lợi dụng được tốc độ truyền dữ liệu cao của nó cụ thể là RTP và
RTCP.
II. Giao thức RTP
• Khái niệm
• Real-time Transport Protocol (RTP) là giao thức thực hiện vận
chuyển các ứng dụng dữ liệu thời gian thực như thoại và hội nghị
truyền hình.

• Các ứng dụng này thường mang các định dạng của âm thanh
(PCM, GSM và MP3 và các định dạng độc quyền khác) và định
dạng của video (MPEG, H.263 và các định dạng video độc quyền
khác).

• RTP được định nghĩa trong RFC 1889, RFC 3550.

• Giao thức RTP chạy trên nền UDP để sử dụng các chức năng
ghép kênh và checksum. Cả hai giao thức RTP và UDP tạo nên
một phần chức năng của lớp giao vận.

• Một điều cần lưu ý là bản thân giao thức RTP không cung cấp
một cơ chế nào đảm bảo việc phân phát kịp thời dữ liệu tới các
trạm, mà nó dựa trên các dịch vụ của lớp thấp hơn để thực hiện
điều này.

• RTP cũng không đảm bảo việc truyền các gói theo đúng thứ tự.

• Số thứ tự trong header cho phép bên thu điều chỉnh lại thứ tự
dòng gói tin của bên phát gữi đến.
• RTP có khả năng mở rộng cho phù hợp với dịch vụ mới.
• Cấu trúc

Version: 2 bit. Trường vesion để chỉ phiên bản của giao thức.

P (Padding): 1 bit. Nếu trường P được thiết lập thì gói tin sẽ có một
hoặc nhều octets P (những octets này không phải một phần của
payload) được thêm vào cuối gói tin.
• X (Extension): 1 bit. Nếu trường X được thiết lập thì phần
header cố định phải được liên kết với phần header mở rộng.
• CC (CSRC count): 4 bits. Chứa các giá trị của trường CSRC ID
trong header cố định.
• M (Marker): 1 bit. Được sử dụng ở lớp ứng dụng để xác định
một profile.
• PT (Payload type): 7 bits. Xác định và nêu ý nghĩa các dạng
payload của RTP.  RTP có thể hỗ trợ đến 27  = 128 loại payload
khác nhau.
• Sequence Number: 16 bits. Trường mang số thứ tự của các gói
tin RTP. Số thứ tự này được tăng lên 1 sau mỗi lần gói tin RTP
được máy phát gửi đi,
• Timestamp: 32 bits. Trường xác định thời điểm lấy mẫu của
octets đầu tiên trong gói tin RTP.

• SSRC (Synchronization Source Identifier): 32 bits. Giá trị của

trường SSRC chỉ ra nguồn đồng bộ (nguồn phát gói tin RTP từ
micro, camera hay RTP mixer) của gói tin RTP, giá trị này được
chọn ngẫu nhiên.

• CSRC (Contributing Source List): từ 0 đến 15 items, 32 bits.

Trường CSRC xác định các nguồn đóng góp payload cho gói tin.

• Phần header mở rộng: Cơ chế mở rộng của RTP cho phép

những ứng dụng riêng lẻ của giao thức RTP thực hiện được với
những chức năng mới đòi hỏi những thông tin thêm vào phần
header của gói tin.
 III.Giao thức RTCP
• Giao thức RTCP (Realtime Transport Control Protocol): Là
giao thức điều khiển được thiết kế để hoạt động kết hợp với RTP,
dựa trên việc truyền đều đặn các gói điều khiển tới tất cả các
người tham gia vào phiên truyền RTCP cung cấp thông tin về các
gói tin nhận được, cung cấp thông tin phản hồi để theo dõi về
chất lượng dịch vụ hội nghị và thông tin về các thành viên tham
gia hội nghị để giúp kiểm soát phiên làm việc.
• Trong một phiên RTP, thường chỉ có một địa chỉ multicast
duy nhất và tất cả các gói tin RTP và RTCP đều phụ thuộc
vào phiên làm việc IP multicast.
• Gói tin RTP và RTCP được phân biệt với nhau bằng việc sử
dụng cổng riêng, thường thì số cổng của RTCP được tạo từ
cổng RTP cộng thêm một. 
• Chức năng
• Cung cấp các thông tin phản hồi về chất lượng của đường
truyền dữ liệu:
• Đây là một phần không thể thiếu được với vai trò là một giao
thức giao vận, nó liên quan đến các hàm điều khiển luồng (flow
control) và kiểm soát sự tắc nghẽn (congestion control). Chức
năng này được thực hiện dựa trên các bản tin thông báo từ phía
người gửi và phía người nhận.
• Thông tin hồi đáp có thể được sử dụng trực tiếp cho việc điều
khiến việc thay đổi phương pháp mã hoá (adaptive encoding).
• Trong trường hơn truyền IP multicast thì các thông tin hồi tiến từ
nhí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.
 • Xác định nguồn:
• RTCP mang một thông tin định danh ở lớp giao vận gọi là
CNAME (canonical name) giúp ta định danh một nguồn phát
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.
• 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.
• Đồng bộ thời gian:
•Các thông báo của bộ phát RTCP chứa thông tin để xác
định thời gian NTP và nhãn thời gian RTP tương ứng. Chúng
có thể được sử dụng để đồng bộ giữa âm thanh với hình ảnh.
• Điều chỉnh tốc độ truyền các gói RTCP:
• Hai chức năng đầu đòi hỏi tất cả các thành viên đều phải gửi đi
các gói RTCP.
 • Các loại thông điệp RTCP:
• RR (Receiver Report)
• Thông điệp RR được tạo ra để báo cáo về việc thu nhận của máy
thu trong một phiên làm việc RTP và nó sẽ được đưa vào một gói
tin RTCP. Gói tin này sau đó sẽ được gửi vào cây multicast để
kết nối với tất cả phiên làm việc khác.
• SR (Sender Report)
• SDES (Source Description Items)
• BYE (End of participation)
•     APP (Application-specific message)
IV. Khoảng thời gian giữa hai lần phát hợp gói RTCP
• Các hợp gói của RTCP được phát đi một cách đều đặn sau những
khoảng thời gian bằng nhau để thường xuyên thông báo về trạng
thái các điểm cuối tham gia. Vấn đề là tốc độ phát các hợp gói
này phải đảm bảo không chiếm hết lưu lượng thông tin dành cho
các thông tin khác.
• Trong một phiên truyền, lưu lượng tổng cộng cực đại của tất cả
các loại thông tin truyền trên mạng được gọi là băng thông của
phiên (session bandwidth). Lưu lượng này được chia cho các bên
tham gia vào cuộc hội nghị. Lưu lượng này được mạng dành sẵn
và không cho phép vượt quá để không ảnh hưởng đến các dịch
vụ khác của mạng. Trong mỗi phần băng thông của phiên được
chia cho các bên tham gia phần lưu lượng dành cho các gói
RTCP chỉ được phép chiếm một phần nhỏ và đã biết là 5% để
không ảnh hưởng đến chức năng chính của giao thức là truyền
các dòng dữ liệu media.
•Phân tích cụ thể từng loại thông điệp:

•Khuôn dạng gói RR

 •Khuôn dạng gói SDES
•Gói SDES (System Description).
• Gói SDES có khuôn dạng như trong hình 3.10 bao gồm một
phần tiêu đề và các đoạn thông tin mô tả nguồn.
 •Phần miêu tả nguồn
• Mỗi đoạn thông tin miêu tả nguồn bao gồm một cặp số nhận
dạng nguồn SSRC/CSRC theo sau đó là các mục miêu tả (SDES
Items).

• Chỉ thị loại mục mô tả. Giá trị của trường này tương ứng với các
loại mục miêu tả sau: CNAME, NAME, EMAIL, PHONE, LOC,
TOOL, NOTE, PRIV
•Khuôn dạng gói BYE
•Gói BYE được sử dụng để thông báo một hay một vài
nguồn sẽ rời khỏi phiên truyền. Trường thông tin về lý do rời
khỏi phiên là tùy chọn (có thể có hoặc không).
 •Khuôn dạng gói APP
•Khuôn dạng gói APP được miêu tả trong hình dưới. Gói
này được sử dụng để dành cho các chức năng cụ thể của từng
ứng dụng.