b. Gĩi tin RR:
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ẽ:
Chunk 2
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. 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
- version (V), padding (P), length: hồn tồ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 hồn tồn phù hợp với giới hạn của băng thơng RTCP.
Phần text được mã hố theo tiêu chuẩn mã hố UTF-8 được đưa ra trong bản
RFC-2279. Chuẩn này hồn tồ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…
59
Đâ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 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à hồn tồ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…
60