GĨI TIN MƠ TẢ CÁC THƠNG TIN CỦA NGUỒN:

Một phần của tài liệu Ứng dụng thời gian thực (Trang 57 - 60)

b. Gĩi tin RR:

4.7GĨ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 (adsbygoogle = window.adsbygoogle || []).push({});

(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… (adsbygoogle = window.adsbygoogle || []).push({});

60

Một phần của tài liệu Ứng dụng thời gian thực (Trang 57 - 60)