Bộ giao thức RTP/RTCP

Vai trò của RTP/RTCP

Giao thức RTP (Realtime Transport Protocol) cung cấp các chức năng giao vận phù hợp cho các ứng dụng truyền dữ liệu mang đặc tính thời gian thực như là thoại và truyền hình tương tác. Những dịch vụ của RTP bao gồm trường chỉ thị loại tải trọng (payload identification), đánh số thứ tự các gói, điền tem thời gian (phục vụ cho cơ chế đồng bộ khi phát lại tín hiệu ở bên thu)…

Thông thường các ứng dụng chay giao thức RTP ở bên trên giao thức UDP để sử dụng các dịch vụ ghép kênh (mutiplexing) và kiểm tra tổng (checksum) của dịch vụ này; cả hai giao thức RTP và UDP tạo nên một phần chức năng của giao thức tầng giao vận. Tuy nhiên RTP cũng có thể được sử dụng với những giao thức khác của tầng mạng và tầng giao vận bên dưới miễn là các giao thức này cung cấp được các dịch vụ mà RTP đòi hỏi: Giao thức RTP hỗ trợ việc truyền dữ liệu tới nhiều đích sử dụng phân bố dữ liệu multicast nếu như khả năng này được tầng mạng hoạt động bên dưới nó cung cấp.

Một điều cần lưu ý là bản thân 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 tầng 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ự. Tuy nhiên số thứ tự trong RTP header ch phép bên thu xây dựng lại thứ tự đúng của các gói bên phát.

Đi cùng với RTP là giao thức RTCP (Realtime Transport Control Protocol) có các dịch vụ giám sát chất lượng dịch vụ và thu thập các thông tin về những người tham gia vào phiên truyền RTP đang tiến hành.

Giao thức RTP được cố tình để cho chưa hoàn thiện. Nó chỉ cung cấp các dịch vụ phổ thông nhất cho hầu hết các ứng dụng truyền thông hội nghị đa phương tiện. Mỗi một ứng dụng cụ thể đều có thể thêm vào RTP các dịch vụ mới cho phù hợp với các yêu cầu của nó. Các khả năng mở rộng thêm vào cho RTP được mô tả trong một profile đi kèm. Ngoài ra, profile còn chỉ ra các mã tương ứng sử dụng trong trường PT (Payload type) của phần tiêu đề RTP ứng với các loại tải trong (payload) mang trong gói.

Một vài ứng dụng cả thử nghiệm cũng như thương mại đã được triển khai. Những ứng dụng này bao gồm các ứng dụng truyền thoại, video và chuẩn đoán tình trạng mạng (như là giám sát lưu lượng). Tuy nhiên, mạng Internet ngày nay vẫn chưa thể hỗ trợ được đầy đủ yêu cầu của các dịch vụ thời gian thực. Các dịch vụ sử dụng RTP đòi hỏi băng thông cao (như là truyền audio) có thể là giảm nghiêm trọng chất lượng của các dịch vụ khác trong mạng. Như vậy những người triển khai phải chú ý đến giới hạn băng thông sử dụng của ứng dụng trong mạng.

Các ứng dụng sử dụng RTP

3.3.2.1 Hội nghị đàm thoại đơn giản

Các ứng dụng hội nghị đàm thoại đơn giản chỉ bao gồm việc truyền thoại trong hệ thống. Tín hiệu thoại của những bên tham gia được chia thành những đoạn nhỏ, mỗi phần được thêm vào phần tiêu đề của giao thức RTP. Tiêu đề RTP mang thông tin chỉ ra cách mã hóa tín hiệu thoại (như là PCM, ADPCM, hay LPC…). Căn cứ vào thông tin này, các bên thu sẽ thực hiện giải mã cho đúng.

Mạng Internet cũng như các mạng gói khác đều có khả năng xảy ra mất gói và sai lệch về thứ tự các gói. Để giải quyết vấn đề này, phần tiêu đề RTP mang thông tin định thời và số thứ tự các gói, cho phép bên thu khôi phục định thời với nguồn phát. Sự khôi phục định thời được tiến hành độc lập với từng nguồn phát trong hội nghị. Số thứ tự gói có thể được sử dụng để ước tính số gói bị mất trong khi truyền. Các gói thoại RTP được truyền đi theo các dịch vụ của giao thức UDP để có thể đến dích nhanh nhất có thể.

Để giám sát số người tham gia vào hội nghị và chất lượng thoại họ nhận được tại mỗi thời điểm, mỗi một trạm trong hội nghị gửi đi một cách định kỳ một gói thông tin RR (Reception report) của giao thức RTCP để chỉ ra chất lượng thu của từng trạm. Dựa vào thông tin này mà các thành phần trong hội nghị có thể thỏa thuận với nhau về phương pháp mã hóa thích hợp và việc điều chỉnh băng thông.

3.3.2.2 Hội nghị điện thoại truyền hình

Nếu cả hai dòng tín hiệu thoại và truyền hình đều được sử dụng trong hội nghị thì ứng với mỗi dòng sẽ có một phiên RTP (RTP session) độc lập. Mỗi một phiên RTP sẽ ứng với một cổng (port number) cho thu phát các gói RTP và một cổng thu phát các gói RTCP. Các phiên RTP sẽ được đồng bộ với nhau để cho hình ảnh và âm thanh dùng nhận được ăn khớp.

Lý do để bố trí các dòng thông tin thoại và truyền hình thành những phiên RTP tách biệt là để cho các thiết bị đầu cuối chỉ có khả năng thoại cũng có thể tham gia vào cuộc hội nghị truyền hình mà không cần có bất kỳ thiết bị hỗ trợ nào.

3.3.2.3 Translator và Mixer

Các ứng dụng miêu tả ở phần trên đều có điểm chung là bên thu và bên phát đều sử dụng chung một phương pháp mã hóa thoại. Trong trường hợp một người dùng có đường kết nối tốc độ thấp tham gia vào một hội nghị gồm các thành viên có đường liên kết nối tốc độc cao thì tất cả những người tham gia đều buộc phải sử dụng kết nối tốc độ thấp cho phù hợp với thành viên mới tham gia. Điều này rõ ràng là không hiệu quả. Để khắc phục, một translator hoặc một mixer được đặt giữa hai vùng tốc độ đường truyền cao và thấp để chuyển đổi cách mã hóa thích hợp giữa hai vùng. Điểm khác biệt giữa translator và mixer là mixer trộn các dòng tín hiệu đưa đến nó thành một dòng dữ liệu duy nhất trong khi translator không thực hiện việc trộn dữ liệu.

Khuôn dạng gói RTP

Tiêu đề giao thức RTP bao gồm một phần tiêu đề cố định thường có ở mọi gói RTP và một phần tiêu đề mở rộng phục vụ cho các mục đích nhất định.

3.3.3.1 Phần tiêu đề cố định

Tiêu đề cố định miêu tả trong hình 3.5.

Hình 3.5:Tiêu đề cố định gói RTP

12 octets (byte) đầu tiên của phần tiêu đề có trong mọi gói RTP còn các octets còn lại thường được mixer thêm vào trong gói khi gói đó được mixer chuyển tiếp đến đích.

• Version (V): 2 bit.

Trường này chỉ ra version của RTP. Giá trị của trường này là 2.

• Padding (P): 1 bit.

Nếu bit padding được lập, gói dữ liệu sẽ có một vài octets thêm vào cuối gói dữ liệu. Octets cuối cùng của phần thêm vào này sẽ chỉ kích thước của phần thêm vào này (tính theo byte). Những octets này không phải là thông tin. Chúng được thêm vào để đáp ứng các yêu cầu sau:

Phục vụ cho một vài thuật toán mã hóa thông tin cần kích thước của gói cố định.

Dùng để cách ly các gói RTP trong trường hợp nhiều gói thông tin được mang trong cùng một đơn vị dữ liệu của giao thức tầng dưới.

• Extension (X): 1 bit.

Nếu như bit X được lập, theo sau phần tiêu đề cố định sẽ là một tiêu đề mở rộng.

• Marker (M): 1 bit.

Tùy từng trường hợp cụ thể mà bit này mang những ý nghĩa khác nhau ý nghĩa của nó được chỉ ra trong một profile đi kèm.

• Payload Type (PT): 7 bits.

Trường này chỉ ra loại tải trọng mang trong gói. Các mã sử dụng trong trường này ứng với các loại tải trọng được quy định trong một profile đi kèm.

• Sequence Number: 16 bits.

Mang số thứ tự của gói RTP. Số thứ tự này được tăng lên một sau mỗi gói RTP được gửi đi. Trường này có thể được sử dụng để bên thu phát hiện được sự mất gói và khôi phục lại trình tự đúng của các gói. Giá trí khởi đầu của trường này là ngẫu nhiên.

• Timestamp (tem thời gian): 32 bits.

Tem thời gian phản ánh thời điểm lấy mẫu của octets đầu tiên trong gói RTP. Thời điểm này phải được lấy từ một đồng hồ tăng đều đặn và tuyến tính theo thời gian để cho phép việc đồng bộ và tính toán độ jitter. Bước tăng của đồng hồ này phải đủ nhỏ để đạt được độ chính xác đồng bộ mong muốn khi phát lại và độ chính xác của việc tính toán jitter. Tần số đồng hồ này là không cố định, tùy thuộc vào loại khuôn dạng của tải trọng. Giá trị khởi đầu của tem thời gian cũng được chọn một cách ngẫu nhiên. Một vài gói RTP có thể mang cùng một giá trị tem thời gian nếu như chúng được phát đi cùng một lúc về mặt logic (ví dụ như các gói của cùng một khung hình video). Trong trường hợp các gói dữ liệu được phát ra sau những khoảng thời gian bằng nhau (tín hiệu đã mã hóa thoại tốc độ cố định, fixed-rate audio) thì tem thời gian được tăng một cách đều đặn. Trong trường hợp khác giá trị tem thời gian sẽ tăng không đều.

• Số nhận dạng nguồn đồng bộ SSRC (Synchronization Source Identifier): 32 bits.

SSRC chỉ ra nguồn đồng bộ của gói RTP, số này được chọn một cách ngẫu nhiên. Trong một phiên RTP có thể có nhiều hơn một nguồn đồng bộ. Mỗi một nguồn phát ra một dòng các gói RTP. Bên thu nhóm các gói của cùng một nguồn đồng bộ lại với nhau để phát lại tín hiệu thời gian thực. Nguồn đồng bộ có thể là nguồn phát các gói RTP phát ra từ một micro, camera hay một RTP mixer.

• Các số nhận dạng nguồn đóng góp (CSRC list – Contributing Source list): Có từ 0 đến 15 mục mỗi mục 32 bit.

Các số nhận dạng nguồn đóng góp trong phần tiêu đề chỉ ra những nguồn đóng góp thông tin và phần tải trọng của gói. Các số nhận dạng này được Mixer chèn vào tiêu đề của gói và nó chỉ mang nhiều ý nghĩa trong trường hợp dòng các gói thông tin là dòng tổng hợp tạo thành từ việc trộn nhiều dòng thông tin tới mixer. Trường này giúp cho bên thu nhận biết được gói thông tin này mang thông tin của những người nào trong một cuộc hội nghị.

Số lượng các số nhận dạng nguồn đóng góp được giữ trong trường CC của phần tiêu đề. Số lượng tối đa của các số nhận dạng này là 15. Nếu có nhiều hơn 15 nguồn đóng góp thông tin vào trong gói thì chỉ có 15 số nhận dạng được liệt kê vào danh sách.

Mixer chèn các số nhận dạng này vào gói nhờ số nhận dạng SSRC của các nguồn đóng góp.

3.3.3.2 Phần tiêu đề 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 tiêu đề của gói. Cơ chế này được thiết kế để một vài ứng dụng có thể bỏ qua một số ứng dụng khác lại có thể sử dụng được phần nào đó.

Cấu trúc của phần tiêu đề mở rộng như hình 3.6:

Hình 3.6: Tiêu đề mở rộng của gói RTP

Nếu như bit X trong phần tiêu đề cố định được đặt bằng 1 thì theo sau phần tiêu đề cố định là phần tiêu đề mở rộng có chiều dài thay đổi.

• 16 bit đầu tiên trong phần tiêu đề được sử dụng với mục đích riêng cho từng ứng dụng được định nghĩa bởi profile. Thường nó được sử dụng để phân biệt các loại tiêu để mở rộng.

Length: 16 bits. Mang giá trị chiều dài của phần tiêu đề mở rộng tính theo đơn vị là 32 bits. Giá trị này không bao gồm 32 bit đầu tiên của phần tiêu đề mở rộng.

Giao thức điều khiển RTCP

Giao thức RTCP 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. Nó sử dụng có chế phân phối gói dữ liệu trong mạng giống như giao thức RTP, tức là cũng sử dụng các dịch vụ của giao thức UDP qua một cổng UDP độc lập với việc truyền các gói RTP.

3.3.4.1 Các loại gói điều khiển RTCP

Giao thức RTCP bao gồm các loại gói sau:

• SR (Sender Report): Mang thông tin thống kê về việc truyền và nhận thông tin từ những người tham gia trong trạng thái tích cực gửi.
• RR (Receiver Report): Mang thông tin thống kê về việc nhận thông tin từ những người tham gia không ở trạng thái tích cực gửi.
• SDES (Source Description items): Mang thông tin miêu tả nguồn phát gói RTP.
• BYE: Chỉ thị sự kết thúc tham gia vào phiên truyền.
• APP: Mang các chức năng cụ thể cửa ứng dụng.

Giá trị của trường PT (Packet Type) ứng với mỗi loại gói được liệt kê trong bảng sau:

Loại gói	SR	RR	SDES	BYE	APP
PT (Decimal)	200	201	202	203	204

Mỗi gói thông tin RTCP bắt đầu bằng một phần tiêu đề cố định giống như gói RTP thông tin. Theo sau đó là các cấu trúc có chiều dài có thể thay đổi theo loại gói nhưng luôn bằng số nguyên lần 32 bits. Trong phần tiêu đề cố định có một trường chỉ thị độ dài. Điều này giúp cho các gói thông tin RTCP có thể gộp lại với nhau thành một hợp gói (compound packet) để truyền xuống lớp dưới mà không phải chèn thêm vào các bit cách ly. Số lượng các gói trong hợp gói không quy định cụ thể mà tùy thuộc vào chiều dài đơn vị dữ liệu lớp dưới.

Mọi gói RTCP đều phải được truyền trong hợp gói cho dù trong hợp gói chỉ có một gói duy nhất. Khuôn dạng của hợp gói được đề xuất như sau:

Tiếp đầu mã hóa (Encription Prefix): (32 bit) 32 bit đầu tiên được để dành nếu và chỉ nếu hợp gói RTCP cần được mã hóa. Giá trị mang trong phần này cần chú ý tránh trùng với 32 bit đầu tiên trong gói RTP.

Gói đầu tiên trong hợp gói luôn luôn là gói RR hoặc SR. Trong trường hợp không thu, không nhận thông tin hay trong hợp gói có một gói BYE thì một gói RR rỗng dẫn đầu trong hợp gói.

Trong trường hợp số lượng các nguồn được thống kê vượt quá 31 (không vừa trong một gói SR hoặc RR) thì những gói RR thêm vào sẽ theo sau gói thống kê đầu tiên. Việc bao gồm gói thống kê (RR hoặc SR) trong mỗi hợp gói nhằm thông tin thường xuyên về chất lượng thu của những người tham gia. Việc gửi hợp gói đi được tiến hành một cách đều đặn và thường xuyên theo khả năng cho phép của băng thông.

Trong mỗi hợp gói cũng bao gồm SDES nhằm thông báo về nguồn phát tín hiệu.

Các gói BYE và APP có thể có thứ tự bất kỳ trong hợp gói trừ gói BYE phải nằm cuối cùng.