Một điều chắc chắn rằng các thông tin hồi đáp về chất lượng nhận thông tin sẽ không chỉ hữu ích cho người nhận, nó còn dùng cho các người nhận khác và nhà quản trị mạng (đóng vai trò của thành viên thứ 3).
Người gởi có thể điều chỉnh quá trình truyền tin của mình thông qua các thông tin hồi đáp. Nếu có lỗi xảy ra, các người nhận khác có thể dựa vào thông tin hồi đáp để xác định, cấp độ lỗi là cục bộ, khu vực hay toàn cục. Nhà quản trị mạng có thể chỉ nhận các
gói RTCP (không cần quan tâm đến các gói RTP) để đánh giá hiệu suất của mạng trong quá trình truyền multicast.
Các số đếm tích luỹ được sử dụng trong cả thông tin người gởi và các khối thông báo của người nhận, do đó sự khác biệt được tính giữa 2 bản tin bất kỳ phục vụ cho phép đo trong thời gian ngắn hoặc dài, được dùng để khôi phục lại các bản tin bị thất lạc. Sự khác nhau giữa 2 bản tin cuối cùng nhận được có thể được dùng để ước tính chất lượng hiện thời của đường truyền.
Việc gắn nhãn thời gian NTP giúp ta có thể tính được tốc độ truyền tải dựa vào khoảng thời gian chênh lệch của 2 gói RTCP.
Ta lấy một ví dụ, tính toán tốc độ thất lạc gói trong khoảng thời gian giữa 2 bản tin (bất kỳ). Sự khác biệt giữa các số đếm tích luỹ cho ta biết được số gói đã bị thất lạc. Giá trị của số thứ tự trong gói tin cuối cùng nhận được giúp ta biết được số gói tin cần nhận được trong khoảng thời gian giữa 2 bản tin. Tỷ lệ thất lạc gói tin trongkhoảng thời gian này chính là tỷ số của 2 giá trị trên. Nếu 2 bản tin là liên tiếp thì tỷ số này sẽ bằng giá trị của fraction lost field. Ta cũng có thể tính tỷ lệ thất lạc gói tin trong 1s bằng cách chia tỷ số này cho khoảng thời gian chênh lệch giữa 2 nhãn thời gian NTP (đơn vị tính bằng s). Điều này rất quan trọng, bởi các giá trị thống kê được tính trong thời gian dài luôn có ý nghĩa hơn các giá trị tức thời. Việc 200 gói thất lạc trong số 1000 gói có ý nghĩa hơn nhiều so với việc 1 gói thất lạc trong 5 gói. Bởi con số thứ nhất có thể nói lên đặc tính của mạng, còn con số thứ 2 chỉ nói lên một giá trị tức thời, không thể nói là mạng đó tốt hay dở.
Từ những thông tin của người gởi, nhà quản trị mạng có thể tính toán tốc độ tải dữ liệu trung bình và tốc độ gói trung bình trong một khoảng thời gian mà không cần phải phân tích bất kỳ gói dữ liệu RTP nào. Dựa vào hai tỷ số này ta có thể biết được kích thước tải trung bình của gói RTP. Nếu ta giả sử rằng việc thất lạc gói không phụ thuộc vào kích thước của tải, khi đó số gói tin nhận được bởi 1 thành viên nhân với kích thước tải trung bình cho ta biết được thông lượng khả dụng của thành viên đó.
Như vậy ta thấy, việc thêm biến đếm tích luỹ cho phép ta tính toán sự mất gói trong khoảng thời gian dài. Điều này trở lên rất có ý nghĩa trong trường hợp có nhiều thành viên tham gia 1 phiên RTP. Khi đó các thông tin trạng thái sẽ không thể được nhận một cách liên tục từ tất cả các nguồn.
Trường interarrival jitter cung cấp cho ta phép đo trong thời gian ngắn sự tắc nghẽn trên mạng. Packet loss cho phép ta theo dõi sự tắc nghẽn trên mạng trong thời gian dài, trong khi đó jitter giúp ta theo dõi sự tăc nghẽn tức thời trên mạng.
Để có thể so sánh giữa các thành viên khác nhau, việc tính toán jitter phải được thực hiện theo cùng một công thức cho mọi thành viên. jitter được tính toán dựa trên nhãn thời gian RTP, ghi lại thời điểm mà tại đó gói dữ liệu được lấy mẫu lần đầu. Do vậy bất kỳ sự biến đổi thời gian trễ nào trong quá trình lấy mẫu và trong quá trình truyền lan gói dữ liệu đều được tính vào jitter. Sự biến đổi trong thời gian trễ sẽ dẫn đến sự “mấp mô” của tín hiệu audio nhận được. Điều này cũng xảy ra trong quá trình mã hoá tín hiệu video. Nhãn thời gian sẽ được gắn giống nhau cho mọi gói tin chứa cùng 1 khung hình, tuy nhiên các gói dữ liệu này lại không được truyền đi đồng thời mà được gởi đi lần lượt, điều này sẽ làm giảm độ chính xác của việc tính toán jitter với mục đích phân tích hoạt động của mạng. Nhưng nó sẽ hợp lý nếu ta giả thiết rằng quá trình xảy ra hoàn toàn tương tự tại bộ đệm của người nhận. Khi đó hằng số thời gian trễ do việc chờ đến lượt truyền sẽ bị loại trừ. Vì vậy chúng ta có thể kiểm soát được jitter xảy ra trong
quá trình lan truyền trên mạng.
4.7 GÓI TIN MÔ TẢ CÁC THÔNG TIN CỦA NGUỒN:
(SDES: Source Description RTCP Packet)
Cấu trúc bản tin như hình vẽ:
Chunk2 SSRC/CSRC_2 SDES items ...
Hình 4.6: Cấu trúc gói tin SDES-RTCP
Gói SDES bao gồm phần tiêu đề, kèm theo là các đoạn chứa các thông tin về các nguồn SSRC/CSRC _i (ở đây ta gọi tắt là các đoạn SSRC/CSRC). Trong một gói SDES
00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
Header V=2 P RC PT=SDES=202 length SSRC of packet sender
Chunk1SSRC/CSRC_1 SDES items ...
có thể có không hoặc nhiều đoạn thông tin này. Các thông tin trong từng đoạn riêng lẻ là hoàn toàn độc lập.
- version (V), padding (P), length: hoàn toàn tương tự như trong các gói RTCP khác.
- packet type (PT): 8 bits. Có giá trị bằng 202, dùng xác định đây là một gói SDES RTCP.
- source count (SC): 5 bits. Xác định số các đoạn SSRC/CSRC được chứa trong gói SDES này. Trường này có thể nhận giá trị nhỏ nhất bằng 0 khi không có thông tin về một nguồn nào được mô tả, tuy nhiên điều này thường không xảy ra. Mỗi đoạn SSRC/CSRC bao gồm 1 phần định danh nguồn SSRC/CSRC, tiếp theo là một loạt các thông tin về nguồn SSRC/CSRC đó. Mỗi đoạn sẽ bắt đầu bằng 1phần 32-bit.
Mỗi phần thông tin (SDES item) sẽ có trường định kiểu 8-bit, 8-bit dùng xác định chiều dài của phần thông tin (không chứa 2-byte đầu tiên này). Tiếp theo là phần thông tin cụ thể (text). Chú ý rằng phần text không thể vượt quá 255-byte, nhưng điều này hoàn toàn phù hợp với giới hạn của băng thông RTCP.
Phần text được mã hoá theo tiêu chuẩn mã hoá UTF-8 được đưa ra trong bản RFC- 2279. Chuẩn này hoàn toàn đáp ứng được cá yêu cầu của chuẩn ASCII của Mỹ.
Hình 4.7: Cấu trúc SDES item.
Mỗi hệ thống đầu cuối sẽ phát đi gói SDES mang thông tin định danh nguồn của mình (tương tự như giá trị SSRC trong phần tiêu đề của gói RTP). Sau đó bộ trộn (mixer) sẽ gộp các thông tin này lại từ các nguồn phân tán, phân chúng thành từng đoạn trong một gói SDES chung và gởi đi. Nếu có nhiều hơn 31 nguồn thì các thông tin sẽ được chứa trong nhiều gói SDES chung. Chung ta sẽ nói cụ thể hơn trong phần Mixer.
Bây giờ ta sẽ định nghĩa từng loại thông tin mang trong gói SDES. Trong đó chỉ có CNAME là bắt buộc. các thông tin còn lại có thể có hay không tuỳ thuộc vào từng ứng dụng cụ thể. Các loại được thông tin nêu ra ở đây đều phổ biến, đã được đăng ký với IANA [] 15.
a. CNAME: Canonical End-Point Identifier:
00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31…
Type field length text
Đây là một trường thông tin bắt buộc trong gói SDES, dùng để nhận dạng một đầu cuối.
Hình 4.8: Cấu trúc CNAME-SDES . CNAME có các thuộc tính sau:
- Một định danh SSRC được phân phối một cách ngẫu nhiên và có thể thay đổi trong một phiên RTP, khi phát hiện sự xung đột, hoặc khi chương trình khởi tạo lại. Do vậy, CNAME được sử dụng để liên kết một định danh SSRC với một định danh không đổi dành cho một nguồn xác định.
- Cũng giống như SSRC, giá trị của CNAME của mỗi thành viên phải là duy nhất trong một phiên RTP.
- Giá trị của CNAME được dùng cố định cho một thành viên nào đó. Điều này giúp ta có thể kết nối giữa các luồng dữ liệu khác nhau được gởi đi từ cùng một thành viên nhưng sử dụng 2 phiên RTP riêng. Ví dụ, khi mà một thành viên gởi đồng thời tín hiệu video và tín hiệu audio với qua 2 cặp cổng UDP khác nhau.
- Để thuận tiện cho nhà quản trị mạng trong việc định vị nguồn, CNAME nên tương ứng với với sự xác định một cá nhân nào đó
Vì vậy, CNAME sẽ được nhận theo một thuật toán nào đó, không được nhập vào một cách tuỳ ý bởi người dùng.
Để thoả mãn các yêu cầu trên, ta sẽ đưa ra một định dạng của CNAME. Tuy nhiên định dạng này không hề có tính bắt buộc, nó có thể được định nghĩa khác, tuỳ vào từng trường hợp cụ thể.
CNAME xác định dựa trên "user@host" (Ví dụ: doe@sleepy.example.com
, hoặc “host” trong trường hợp “user name” không được xác định trên hệ thống đơn người dùng. Việc xác định “host“ là hoàn toàn đơn trị. Tuy nhiên trong trường hợp, một “host” có thể đồng thời tạo ra nhiều nguồn, cú pháp này không giúp ta phân biệt được từng nguồn cụ thể trong số đó. Việc này sẽ được giải quyết ở lớp ứng dụng, ta sẽ không đề cập đến ở đây.
00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31…
CNAME=1 length user and domain name