Giao thức điều khiển RTP ( RTCP ) là giao thức chính của Giao thức vận chuyển thời gian thực (RTP). Chức năng cơ bản và cấu trúc gói của nó được xác định trong RFC 3550. RTCP cung cấp thông tin kiểm soát và thống kê ngoài băng cho phiên RTP. Nó hợp tác với RTP trong việc phân phối và đóng gói dữ liệu đa phương tiện, nhưng không tự vận chuyển bất kỳ dữ liệu truyền thông nào.
Chức năng chính của RTCP là cung cấp phản hồi về chất lượng dịch vụ (QoS) trong phân phối phương tiện bằng cách gửi định kỳ thông tin thống kê như octet truyền và số gói, mất gói, biến đổi trễ gói và thời gian trễ chuyến đi người tham gia trong một phiên truyền phát đa phương tiện. Một ứng dụng có thể sử dụng thông tin này để kiểm soát chất lượng của các tham số dịch vụ, có lẽ bằng cách giới hạn lưu lượng hoặc sử dụng một codec khác.
Các chức năng giao thức [ chỉnh sửa ]
Thông thường RTP sẽ được gửi trên cổng UDP được đánh số chẵn, với các tin nhắn RTCP được gửi qua cổng có số lẻ cao hơn tiếp theo. [1]
Bản thân RTCP không cung cấp bất kỳ phương thức mã hóa hoặc xác thực dòng chảy nào. Các cơ chế như vậy có thể được triển khai, ví dụ, với Giao thức truyền tải thời gian thực an toàn (SRTP) được xác định trong RFC 3711.
RTCP cung cấp các chức năng cơ bản dự kiến sẽ được triển khai trong tất cả các phiên RTP:
- Chức năng chính của RTCP là thu thập số liệu thống kê về các khía cạnh chất lượng của phân phối phương tiện trong một phiên và truyền dữ liệu này đến nguồn phương tiện phiên và những người tham gia phiên khác. Thông tin đó có thể được sử dụng bởi nguồn để mã hóa phương tiện thích ứng (codec) và phát hiện lỗi truyền. Nếu phiên được truyền qua mạng đa hướng, điều này cho phép giám sát chất lượng phiên không xâm phạm.
- RTCP cung cấp số nhận dạng điểm cuối chính tắc (CNAME) cho tất cả người tham gia phiên. Mặc dù số nhận dạng nguồn (SSRC) của luồng RTP được dự kiến là duy nhất, nhưng ràng buộc tức thời của mã định danh nguồn với điểm cuối có thể thay đổi trong phiên. CNAME thiết lập nhận dạng duy nhất các điểm cuối trên một phiên bản ứng dụng (sử dụng nhiều công cụ phương tiện) và để theo dõi bên thứ ba.
- Cung cấp các chức năng kiểm soát phiên. RTCP là một phương tiện thuận tiện để tiếp cận tất cả những người tham gia phiên, trong khi bản thân RTP thì không. RTP chỉ được truyền bởi một nguồn phương tiện.
Các báo cáo RTCP dự kiến sẽ được gửi bởi tất cả những người tham gia, ngay cả trong một phiên phát đa hướng có thể có hàng ngàn người nhận. Lưu lượng như vậy sẽ tăng tỷ lệ thuận với số lượng người tham gia. Vì vậy, để tránh tắc nghẽn mạng, giao thức phải bao gồm quản lý băng thông phiên. Điều này đạt được bằng cách kiểm soát linh hoạt tần số truyền báo cáo. Việc sử dụng băng thông RTCP thường không được vượt quá 5% tổng băng thông phiên. Hơn nữa, 25% băng thông RTCP nên được dành riêng cho các nguồn phương tiện mọi lúc, để trong các hội nghị lớn, những người tham gia mới có thể nhận được số nhận dạng CNAME của người gửi mà không bị chậm trễ quá mức.
Khoảng thời gian báo cáo RTCP được chọn ngẫu nhiên để ngăn việc đồng bộ hóa báo cáo ngoài ý muốn. Khoảng thời gian báo cáo RTCP tối thiểu được đề xuất cho mỗi trạm là 5 giây. Các trạm không nên truyền báo cáo RTCP thường xuyên hơn 5 giây một lần.
| Offsets | Octet | 0 | 1 | 2 | 3 | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Octet | Bit [a] | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
| 0 | Phiên bản | P | RC | PT | chiều dài | ||||||||||||||||||||||||||||
| 32 | SSRC | ||||||||||||||||||||||||||||||||
- Phiên bản : (2 bit) Xác định phiên bản của RTP, giống với các gói RTCP như trong các gói dữ liệu RTP. Phiên bản được xác định bởi thông số kỹ thuật này là hai (2). [2]
- P (Padding) : (1 bit) Được sử dụng để chỉ ra nếu có thêm byte đệm ở kết thúc gói RTP. Một phần đệm có thể được sử dụng để lấp đầy một khối có kích thước nhất định, ví dụ như theo yêu cầu của thuật toán mã hóa. Byte cuối cùng của phần đệm chứa số byte đệm được thêm vào (bao gồm cả chính nó). [2]
- RC (Số báo cáo tiếp nhận) : (5 bit) số khối báo cáo tiếp nhận có trong gói này. Giá trị bằng 0 là hợp lệ. [2]
- PT (Loại gói) : (8 bit) Chứa hằng số để xác định loại gói RTCP. [2]
- Chiều dài : (16 bit) Cho biết độ dài của gói RTCP này. [2]
- SSRC : (32 bit) Mã định danh nguồn đồng bộ hóa xác định duy nhất nguồn của luồng. [2]
Các loại thông báo [ chỉnh sửa ]
RTCP phân biệt một số loại gói: báo cáo người gửi báo cáo người nhận mô tả nguồn và tạm biệt . Ngoài ra, giao thức có thể mở rộng và cho phép các gói RTCP dành riêng cho ứng dụng. Một phần mở rộng của RTCP dựa trên tiêu chuẩn là loại báo cáo mở rộng được giới thiệu bởi RFC 3611. [3]
- Báo cáo người gửi (SR)
- Báo cáo người gửi được gửi theo định kỳ bởi người gửi đang hoạt động trong một hội nghị để báo cáo thống kê truyền và nhận cho tất cả các gói RTP được gửi trong khoảng thời gian. Báo cáo người gửi bao gồm dấu thời gian tuyệt đối, là số giây trôi qua kể từ nửa đêm ngày 1 tháng 1 năm 1900. Dấu thời gian tuyệt đối cho phép người nhận đồng bộ hóa tin nhắn RTP. Điều đặc biệt quan trọng khi cả âm thanh và video được truyền đồng thời, vì các luồng âm thanh và video sử dụng dấu thời gian tương đối độc lập.
- Báo cáo người nhận (RR)
- Báo cáo người nhận dành cho người tham gia thụ động, những người không gửi gói RTP. Báo cáo thông báo cho người gửi và những người nhận khác về chất lượng dịch vụ.
- Mô tả nguồn (SDES)
- Thông báo Mô tả nguồn được sử dụng để gửi mục CNAME cho người tham gia phiên. Nó cũng có thể được sử dụng để cung cấp thông tin bổ sung như tên, địa chỉ email, số điện thoại và địa chỉ của chủ sở hữu hoặc người kiểm soát nguồn.
- Tạm biệt (BYE)
- Một nguồn gửi tin nhắn BYE tới tắt một dòng. Nó cho phép một điểm cuối thông báo rằng nó sẽ rời khỏi hội nghị. Mặc dù các nguồn khác có thể phát hiện sự vắng mặt của một nguồn, thông báo này là một thông báo trực tiếp. Nó cũng hữu ích đối với một bộ trộn phương tiện.
- Thông báo dành riêng cho ứng dụng (APP)
- Thông báo dành riêng cho ứng dụng cung cấp một cơ chế để thiết kế các phần mở rộng dành riêng cho ứng dụng cho giao thức RTCP.
Khả năng mở rộng trong các triển khai lớn [19659004] [ chỉnh sửa ]
Trong các ứng dụng quy mô lớn, như trong Truyền hình Giao thức Internet (IPTV), có thể xảy ra sự chậm trễ rất lâu (vài phút đến vài giờ) giữa các báo cáo RTCP, do cơ chế kiểm soát băng thông RTCP cần thiết để kiểm soát tắc nghẽn (xem chức năng Giao thức). Tần số chấp nhận được thường ít hơn một mỗi phút. Điều này cho thấy tiềm năng báo cáo không phù hợp về số liệu thống kê có liên quan của người nhận hoặc nguyên nhân đánh giá của người gửi phương tiện là không chính xác so với trạng thái hiện tại của phiên. Các phương pháp đã được giới thiệu để làm giảm bớt các vấn đề: [4] Lọc RTCP, phân tập RTCP và tổng hợp phân cấp. [5]
Tập hợp phân cấp [ chỉnh sửa ]
Tập hợp phân cấp phân cấp phản hồi) là tối ưu hóa mô hình phản hồi RTCP và mục đích của nó là thay đổi số lượng người dùng tối đa giới hạn hơn cùng với phép đo chất lượng dịch vụ (QoS). [6][7] Băng thông RTCP không đổi và chỉ chiếm 5% băng thông phiên . Do đó, khoảng thời gian báo cáo về QoS phụ thuộc vào một số thành viên phiên và đối với các phiên rất lớn, nó có thể trở nên rất cao (phút hoặc thậm chí là vài giờ) [2]. Tuy nhiên, khoảng thời gian chấp nhận được là khoảng 10 giây báo cáo. Các giá trị lớn hơn sẽ gây ra tình trạng báo cáo thay đổi theo thời gian và rất không chính xác về trạng thái phiên hiện tại và bất kỳ tối ưu hóa nào được thực hiện bởi người gửi thậm chí có thể có tác động tiêu cực đến các điều kiện mạng hoặc QoS.
Tập hợp phân cấp được sử dụng với Multicast nguồn cụ thể trong đó chỉ cho phép một nguồn duy nhất, tức là IPTV. Một loại đa hướng khác có thể là Any-Source Multicast nhưng nó không phù hợp với các ứng dụng quy mô lớn với số lượng người dùng khổng lồ.
Kể từ tháng 6 năm 2007 [update]chỉ các hệ thống IPTV hiện đại nhất mới sử dụng tổng hợp phân cấp. [ trích dẫn cần thiết ]
Mục tiêu phản hồi [ chỉnh sửa ]
Target Target là một loại thành viên mới, lần đầu tiên được giới thiệu bởi Dự thảo Internet-ietf-avt-rtcpssm-13 [8]. Phương pháp phân cấp phân cấp đã mở rộng chức năng của nó. Chức năng của thành viên này là nhận Báo cáo người nhận (RR) (xem RTCP) và truyền lại các gói RR được tóm tắt, được gọi là Thông tin tóm tắt người nhận (RSI) [8] cho người gửi (trong trường hợp phân cấp một cấp).
Tài liệu tiêu chuẩn [ chỉnh sửa ]
- RFC 3550, Tiêu chuẩn 64, RTP: Giao thức vận chuyển cho các ứng dụng thời gian thực
Xem thêm ] chỉnh sửa ]
- ^ Bits được sắp xếp theo thứ tự quan trọng nhất đến ít quan trọng nhất; bit offset 0 là bit đáng kể nhất của octet đầu tiên. Octets được truyền theo thứ tự mạng. Thứ tự truyền bit là phụ thuộc trung bình.
Tài liệu tham khảo [ chỉnh sửa ]
- ^ RFC 3605, Thuộc tính Giao thức điều khiển thời gian thực (RTCP) ) C. Huitema, Microsoft (tháng 10 năm 2003)
- ^ a b c ] d e f RFC 3550
- ^ RFC 3611, Báo cáo mở rộng giao thức kiểm soát RTP (RTCP XR) T. Friedman (Ed.), R. Caceres, A. Clark (Ed.) , Hiệp hội Internet (tháng 11 năm 2003)
- ^ Vít Novotný, Dan Komosný, Tối ưu hóa phản hồi RTCP quy mô lớn Tạp chí Mạng, Vol.3 (3), tháng 3 năm 2008
- ^ Giao thức điều khiển thời gian thực và các cải tiến của nó đối với Truyền hình Giao thức Internet
- ^ KOMOSNY D., NOVOTNY V. Cấu trúc cây cho Đa tuyến nguồn cụ thể với Phản hồi tổng hợp, trong ICN07 – Hội nghị quốc tế lần thứ sáu về kết nối mạng. Martinique, 2007 ISBN 0-7695-2805-8
- ^ NOVOTNY, V., KOMOSNY, D. Tối ưu hóa Báo cáo phản hồi RTCP quy mô lớn trong ICWMC 2007 ICWMC 2007 – Hội nghị quốc tế lần thứ ba về Truyền thông không dây và di động. Guadeloupe, 2007 ISBN 0-7695-2796-5
- ^ a b RFC 5760 J. Ott, J. Chesterfield, E. Học sinh. "Phần mở rộng RTCP cho các phiên đa nguồn đơn với phản hồi Unicast"
Đọc thêm [ chỉnh sửa ]