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 q 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 tồ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 q 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 tố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 ln 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 tố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 tố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 tố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 tố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 q 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 q trình mã hố 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 tố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 số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 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à hồn tồ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.
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 Chunk 1 SSRC/CSRC_1 SDES items .......... 58
- 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:
Đâ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.
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
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 tố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.