Video Conference là một phương thức thông tin liên lạc mới, được kết hợp bởi những đặc tính của công nghệ viễn thông và công nghệ thông tin nhằm đem đến cho người sử dụng nhiều tiện ích hơn một cuộc điện thoại bình thường. Về cơ bản Video Conference giống như liên lạc bằng điện thoại nhưng được bổ xung hàng loạt các tiện ích khác như:

* Những người đàm thoại có thể nhìn thấy nhau

* Cùng chia sẻ dữ liệu trên máy tính như văn bản, bảng tính, cơ sở dữ liệu

* Có thể kết nối bằng bất kỳ phương thức nào như: kênh thuê riêng (Leased-Line), ISDN hay IP (Internet Protocol)

Do những tiện ích rất ưu việt như đã kể trên nên Video Conference được ứng dụng trong rất nhiều ngành kinh tế, xã hội cũng như an ninh, quốc phòng. Phổ biến nhất Video Conference được ứng dụng trong hội họp từ xa giúp những người tham gia không tốn thời gian đi lại mà vẫn có thể gặp mặt nhau, hơn nữa lại tiết kiệm nhiều chi phí khác.

Vì sao cần lắp đặt Hệ thống này:

Với mỗi lĩnh vực, dịch vụ Hội nghị Truyền hình luôn là lựa chọn số một khi khoảng cách giữa các điểm liên lạc với nhau là khá xa, không thuận lợi cho việc đi lại để trực tiếp gặp mặt nhau trao đổi công việc. Dịch vụ Hội nghị Truyền hình đặc biệt hiệu quả trong việc giảng dạy và đào tạo trực tuyến từ xa.

Ngày nay, với sự phát triển mạnh mẽ của Công nghệ thông tin - Viễn thông, đã có khá nhiều giải pháp cho dịch vụ Hội nghị Truyền hình. Tuy nhiên với cơ sở hạ tầng mạng tại Việt Nam hiện nay thì các giải pháp phù hợp và khả thi cho Hội nghị Truyền hình là giải pháp dựa trên công nghệ IP và giải pháp dựa trên công nghệ ISDN.

Lợi ích của việc lắp đặt hệ thống này:

Dịch vụ này cung cấp khả năng truyền hình ảnh, âm thanh trực tuyến giữa nhiều điểm trên mạng, giúp tăng cường khả năng tương tác, trao đổi giữa các thành viên trong hội nghị

Tiết kiệm được thời gian và chi phí nhưng công việc vẫn hiệu quả

Truyền giọng nói qua Internet là công nghệ gọi điện thoại rẻ tiền đang được cá nhân và doanh nghiệp dần dần chấp nhận sử dụng rộng rãi. Khác với đường dây điện thoại thông thường, hệ thống VoIP có thể kết hợp hình ảnh video và giọng nói để tổ chức các cuộc hội nghị từ xa.

Trong công nghệ VoIP, tín hiệu thoại sau khi nén xuống tốc độ thấp được đóng gói lại để truyền đi trong mạng chuyển mạch gói. Có nhiều cách thức đóng gói tín hiệu thoại để truyền trong mạng IP. Một trong những cách thức được áp dụng nhiều nhất là bộ giao thức RTP/RTCP nhờ tính linh hoạt và khả năng giám sát trạng thái dòng thông tin một cách hiệu quả của nó.

Các lĩnh vực có thể áp dụng dịch vụ này:

Hội nghị, giao ban, trao đổi công việc của các đơn vị có vị trí địa lý cách xa nhau

Dạy và học trực tuyến từ xa theo mô hình học trên mạng (E-Learning)

Chăm sóc y tế từ xa: người bệnh có thể được khám bệnh, chẩn đoán hay thậm chí phẫu thuật gián tiếp từ các chuyên gia y tế tại những nơi rất xa

Các công việc và lĩnh vực yêu cầu trao đổi thông tin, hình ảnh, âm thanh thời gian thực khác.

T×nh h×nh ph¸t triÓn c«ng nghÖ Video conference ë viÖt nam hiÖn nay .

ViÖc øng dông c«ng nghÖ th«ng tin cña n­íc ta hiÖn nay so víi c¸c n­íc trªn thÕ giíi th× chung ta con tôt hËu, xong thêi gian gÇn ®©y chóng ta còng ®• cã nhiÒu cè g¾ng, b»ng chøng lµ chóng ta ®ang ®Èy m¹nh ®µo t¹o nguån nh©n lùc cho ngµnh c«ng nghÖ th«ng tin vµ ®• cã nhiÒu øng dông thùc tiÔn cña c«ng nghÖ th«ng tin vµo sinh ho¹t còng nh­ s¶n xuÊt vµ còng ®• ®¹t ®­îc nh÷ng thµnh tùu to lín vµ cßn tiÕt kiÖm ®­îc rÊt nhiÒu kinh phÝ cho nhµ n­íc, tæ chøc, c¸c c«ng ty...Vµ víi sù ph¸t triÓn m¹nh mÏ cña c«ng nghÖ th«ng tin ®• kÐo theo ph¸t triÓn cña c¸c ngµnh c«ng nghÖ kh¸c mµ ®Æc biÖt hiÖn nay lµ sù ph¸t triÓn cña c«ng nghÖ Video conference ®• ®em l¹i mét c¸ch nh×n míi mÏ vµ nh­ chóng ta ®• biÕt vÒ c«ng nghÖ nµy nh­ phÇn ®• tr×nh bµy ë trªn. Trªn thÕ giíi th× c«ng nghÖ nµy ®• ®­îc hä ®em vµo nghiªn c­u vµ øng dông l©u råi xong nãi ë ViÖt Nam chóng cã lÏ vÉn con h¬i míi mÎ v× thùc chÊt chóng ta còng chi ®em vµo nghiªn cøu vµ øng dông mÊy n¨m gÇn ®©y. Tuy v©y chóng ta vÉn ®¹t ®­îc nh÷ng kÕt qu¶ kh¶ quan vµ ®­îc rÊt nhiÒu ngµnh, tæ chøc, c«ng ty...,®em vµo ¸p dông vµ sau ®©y lµ mét vµi m×nh ho¹ ®Ó kh¼ng ®Þnh sù ph¸t triÓn, tÇm quan träng cña c«ng nghÖ Video conference.

MÔ HÌNH KẾT NỐI HỘI NGHỊ TRUYỀN HÌNH TRỰC TUYẾN

Một thiết bị đầu cuối hội nghị truyền hình sẽ có ba giao tiếp cơ bản là: giao tiếp với màn hình để hiển thị hình ảnh hội nghị, giao tiếp Camera và giao tiếp âm thanh với Microphone. Bên cạnh đó còn có giao tiếp dữ liệu với hệ thống mạng làm việc để trao đổi và truyền dữ liệu. Camere và Mic thu hình ảnh và âm thanh của phòng họp, được mã hóa qua khối codec và truyền qua mạng theo giao thức thời gian thực đến đầu xa, tại đầu xa, khối Codec giải nén và tách biệt tín hiệu hiển thị ra màn hình và hệ thống trang âm.

CÁC THÀNH PHẦN CƠ BẢN CỦA HỆ THỐNG HỘI NGHỊ TRUYỀN HÌNH

KHỐI CODEC

Camera thu hình và CODEC thực hiện việc nén/giải nén tín hiệu âm thanh, hình ảnh sang dạng thức thời gian thực để truyền đến đầu xa Bộ Speaker và điều khiển từ xa

Speaker: hiển thị âm thanh đầu xa truyền đến

Remote control: Điều khiển camera, cấu hình thông số hệ thống

Màn hiển thị nội dung

Hiển thị hình ảnh và nội dung cuộc họp, có thể là TV, máy chiếu hoặc màn hình máy tính Tùy chọn thiết bị chia sẻ dữ liệu .

Sử dụng khi người dùng muốn chia sẻ nội dung trên máy tính với đầu xa. Ví dụ khi cần trình chiếu slides, đồ họa..

Microphone

Thu giọng nói từ cuộc họp, bán kính vòng cầu lên đến khoảng cách 3m Phụ kiện phụ kiện kết nối hệ thống bao gồm các loại dây nối đi kèm

Sau đây ta tìm hiểu sơ qua về giao thức RTP/RTCP

Khái quát chung về RTP/RTCP:

- RTP: Giao thức chuẩn của IETF về media-stream. RTP mang dữ liệu thoại qua mạng. RTP cung cấp số trình tự và thống số thời gian (time stamp) để xử lý đúng thứ tự của gói tin thoại.

- RTCP: Cung cấp tính năng điều khiền thông tin ngoài băng (out-of-band) cho một luồng RTP. Mỗi luồng RTP có tương ứng luồng RTCP để mà thông báo những số liệu thống kê trên cuộc gọi. RTCP được dùng cho tính năng thông báo QoS.

RTP và RTCP

- RTP cung cấp chức năng mạng vận chuyển end-to-end cho những ứng dụng truyền dữ liệu mà yếu cầu thời gian thực (real-time) như là âm thanh và video. Những chức năng đó bao gồm nhận diện loại dự liệu, số trình tự, tham số thời gian và giám sát tiến trính gởi.

- RTP là thành phần quan trọng của VoIP bởi vì nó cho phép thiết bị đích sắp xếp và điều chỉnh lại thời gian cho gói tin thoại trước khi được gởi đến người dùng. Một header RTP chứa tham số thời gian và số trình tự nhằm để cho thiết bị nhận lưu vào bộ nhớ đệm, khử jitter và góc trể (lacency) bằng cách đồng bộ những gói tin để phát lại (playback) dòng âm thanh liên tục. RTP dùng số trình tự chỉ đế sắp xếp lại thứ tự gói tin. RTP không yêu cầu sự truyền lại nếu một gói tin bị mất.

- Ví dụ: Như những gói thoại khi được gởi đến đích, chúng có thể đi trên những con đường khác nhau để đến đích, mội con đường có thể khác nhau vế khảong cách, tốc độ truyền, kết quà là gói tin đến không đúng thứ thự khi chúng đến đích. Khi ở nguồn tạo ra cuộc gọi, dữ liệu thọai sẽ được đóng gói lại, RTP sẽ gắn vào những gói tin với tham số thời gian và số trình tự và gởi đi. Ở dích dên, RTP sẽ sắp xếp những gói tin và gởi chúng đến bộ xử lý tín hiệu số (digital signal processor-DSP) ở cùng tốc độ khi chúng được gởi đi ở nguồn gọi.

RTCP(Real-Time Transport Control Protocol)

- RTCP giám sát chất lượng của quá trình phân phối dữ liệu và cung cấp tiến trình điều khiển thông tin. RTCP cung cấp thông tin phản hồi dựa theo điều kiện của mạng:

- RTCP cung cấp cơ chế cho những thiết bị liên quan trong phiên (session) RTP trao đổi thông tin về giám sát và điều khiển phiên. RTCP giám sát chất lượng của các yếu tố như là đếm gói (packet count), mất gói, độ trễ, jitter. RTCP truyền gói bằng 1% băng thông của phiên, nhưng ở một tốc độ xác định trong ít nhất mỗi 5 giây.

- Tham số thời gian Network Time Protocol(NTP) dưa vào các xung được đồng bộ. Tham số thời gian RTP tương ứng thì được tạo ngẫu nhiên và dựa vào tiến trính lấy mẫy gói dữ liệu. Cả hai NTP và RTP thì được đặt trong gói RTCP bởi người gởi dữ liệu.

- Ví dụ ứng dụng RTCP:

Trong suốt mỗi cuộc gọi RTP, những gói thông báo thì được tạo ít nhất mỗi 5 giây. Trong điều kiện mạng có chất lượng kém, một cuộc gọi có thể bị ngưng kết nối do lượng lớn gói bị mất. Khi xem xét những gói tin qua hệ htống phân tích gói, người quản trị có thể kiểm tra thông tin trong header của RTCP mà bao gồm số lựng gói mất, jitter....

1. 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 chạy giao thức RTP ở bên trên giao thức UDP để sử dụng các dịch vụ ghép kênh (multiplexing) 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 nay đượ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 cho 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 trọng (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.

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

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ã hoá 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 đí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ể thoả thuận với nhau về phương pháp mã hoá thích hợp và việc điều chỉnh băng thông.

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 ngưòi 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.

2.3. Translator (bộ dịch) và Mixer (bộ trộn)

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ã hoá 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 kết nối tố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ã hoá 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.

3. 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.

+ Bits 0-1 2 3 4-7 8 9-15 16-31

0 Ver. P X CC M PT Sequence Number

32 Timestamp

64 SSRC identifier

96 CSRC identifiers (optional)

...

96+(CC×32) Extension header (optional).

96+(CC×32)

+ (X×((EHL+1)×32))

Data

Hình 1: 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ã hoá 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.

Tuỳ từng trường hợp cụ thể mà bít 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, tuỳ 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ã hoá 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.

SSCR 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 bít.

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.

Extension header

32-bit người đầu tiên, chứa một hồ sơ cụ thể định danh (16 bit) và một chiều dài specifier (16 bit) cho biết rằng chiều dài đuôi (EHL mở rộng = chiều dài tiêu đề) ở 32-bit, đơn vị, ngoại trừ 32 bit của mở rộng tiêu đề.

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 phần tiêu đề mở rộng này (mà vẫn không ảnh hưởng tới sự hoạt động) trong khi một số ứng dụng khác lại có thể sử dụng được phần đó.

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

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.

0 2 3 4 8 9 16 31

defined by profile length

header extension

...

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

- 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á 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.

4. 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.

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 đang 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) tương ứ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) dể 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à tuỳ 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 dù cho 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ã hoá (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ã hoá. 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 gói 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.

4.2. Khoảng thời gian giữa hai lần phát hợp gói RTCP

Các hợp gói của RTCP được phát đi một một cách đều đặn sau những khoảng thời gian bằng nhau để thường xuyên thông báo về trạng thái các điểm cuối tham gia. Vấn đề là tốc độ phát các hợp gói này phải đảm bảo không chiếm hết lưu lượng thông tin dành cho các thông tin khác.

Trong một phiên truyền, lưu lượng tổng cộng cực đại của tất cả các loại thông tin truyền trên mạng được gọi là băng thông của phiên (session bandwidth). Lưu lượng này được chia cho các bên tham gia vào cuộc hội nghị. Lưu lượng này được mạng dành sẵn và không cho phép vượt quá để không ảnh hưởng đến các dịch vụ khác của mạng. Trong mỗi phần băng thông của phiên được chia cho các bên tham gia phần lưu lượng dành cho các gói RTCP chỉ được phép chiếm một phần nhỏ và đã biết là 5% để không ảnh hưởng đến chức năng chính của giao thức là truyền các dòng dữ liệu media.

4.3. Khuôn dạng gói SR

Khuôn dạng gói SR (Sender Report) được miêu tả trong hình 3

0 2 3 8 16 31

V=2 P RC PT = 200 length

SSRC của nguồn gửi gói SR

NTP timestamp (32 bits già)

NTP timestamp (32 bits trẻ)

RTP timestamp

Số lượng gói phát đi của nguồn gửi gói SR

Số lượng octets phát đi của nguồn gửi gói SR

SSRC_1 (SSRC của nguồn đồng bộ thứ nhất)

fraction lost cumulative number of packets lost

extended highest sequence number received

interarrival jitter

last SR (LSR)

delay since last SR (DLSR)

SSRC_2 (SSRC của nguồn đồng bộ thứ hai)

...

profile-specific extension

Hình 3: Khuôn dạng gói SR

Gói SR bao gồm 3 phần bắt buộc:

1/Phần tiêu đề dài 8 octets

Ý nghĩa của các trường như sau:

- Version (V) và Padding (P):

Mang ý nghĩa giống như trong tiều đề của gói RTP.

- Reception Report Count (RC): 5 bits.

Số lượng của các khối báo cáo tin chứa trong gói. Nếu trường này mang giá trị 0 thì đây là gói SR rỗng.

- Packet Type (PT): 8 bits:

Chỉ thị loại gói. Với gói SR giá trị này bằng 200 (thập phân).

- Length: 16 bits.

Chiều dài của gói RTCP trừ đi 1 (tính theo đơn vị 32 bits). Chiều dài này bao gồm phần tiêu đề và phần padding thêm vào cuối gói.

- SSRC: 32 bits

Chỉ thị nguồn đồng bộ cho nơi phát ra gói SR này.

2/Phần thông tin bên gửi

Phần thông tin bên gửi dài 20 octets và có trong mọi gói SR. Các trường có ý nghĩa như sau:

- NTP timestamp (tem thời gian NTP): 64 bits.

Chỉ ra thời gian tuyệt đối khi gói báo cáo được gửi đi. Tem thời gian này có khuôn dạng thời gian theo giao thức NTP (Network Time Protocol): Thời gian tính theo giây với mốc là 0h UTC ngày 1-1-1900; phần nguyên của giá trị thời gian là 32 bit đầu tiên; 32 bits còn lại biễu diễn phần thập phân.

- RTP timestamp (tem thời gian RTP): 32 bits.

Giá trị của trường này tương ứng với giá trị của trường NTP timestamp ở trên nhưng được tính theo đơn vị của nhãn thời gian RTP trong gói dữ liệu RTP và với cùng một độ lệch ngẫu nhiên của nhãn thời gian RTP trong gói dữ liệu RTP.

- Số lượng gói phát đi của nguồn gửi gói SR (Sender's packet count): 32 bits.

Số lượng tổng cộng của các gói dữ liệu RTP được truyền từ nguồn gửi gói SR kể từ khi bắt đầu việc truyền thông tin cho tới thời điểm gói SR được tạo ra. Trương này được xoá về không trong trường hợp nguồn gửi đổi số nhận dạng SSRC của nó. Trương này có thể được sử dụng để ước tính tốc độ dữ liệu tải trọng trung bình.

- Số lượng octets đã được nguồn gửi gói SR gửi đi (Sender octets count): 32 bit.

Số lượng tổng cộng của các octets phần payload được truyền đi trong các gói RTP bởi nguồn gửi gói SR kể từ khi bắt đầu việc truyền cho đến thời điểm gói SR này được tạo ra.

3/ Các khối báo cáo thu (Reception Report blocks)

Phần này bao gồm các khối thông tin báo cáo về việc thu các gói từ các trạm trong phiên truyền. Số lượng các báo cáo có thể là 0 trong trường hợp gói báo cáo rỗng. Mỗi khối báo cáo thống kê về việc nhận các gói RTP của một nguồn đông bộ, bao gồm:

- Số nhận dạng nguồn (SSRC_n): 32 bits.

- Tỷ lệ mất gói (fraction lost): 8 bits.

Tỷ lệ mất gói thông tin tính từ lúc gửi gói SR hoặc RR trước đó. Tỷ lệ mất gói được tính bằng cách đem chia giá trị của trường cho 256.

- Số lượng gói mất tổng cộng (cumulative number of packets lost): 24 bits.

Tổng số gói mất kể từ lúc bắt đầu nhận. Số gói mất bao gồm cả những gói đến đích quá muộn.

- Số thứ tự cao nhất nhận được: 32 bits.

16 bit trẻ mang số thứ tự cao nhất nhận được ứng với giá trị khởi đầu là ngẫu nhiên. 16 bits già mang số thứ tự cao nhất tương ứng với giá trị khởi đầu bằng 0.

- Độ Jitter khi đến đích: 32 bits.

Mang giá trị ước tính độ jitter của các gói khi đến đích. Được tính theo đơn vị của trường timestamp và được biểu diễn dưới dạng số nguyên không dấu. Độ Jitter được tính là giá trị làm tròn của độ chênh lệch khoảng cách về thời gian giữa hai gói ở bên thu và bên phát.

- Tem thời gian của gói SR trước đó (LSR): 32 bits.

Mang giá trị tem thời gian thu gọn của gói SR trước đó. Nếu trước đó không có gói SR nào thì trường này bằng 0.

- Độ trễ tính từ gói SR trước đó (DLSR): 32 bits.

Độ trễ (tính theo đơn vị 1/65536 giây) giữa thời điểm nhận gói SR trước đó từ nguồn SSRC_n và thời điểm gửi gói RR chứa thông tin báo cáo chất lượng nhận tín hiệu của nguồn n.

Hai trường LSR và DLSR của khối báo cáo thứ r được sử dụng để xác định độ trễ khứ hồi giữa hai nguồn r và nguồn n là nguồn gửi gói SR. Hình sau minh hoạ việc xác định độ trễ khứ hồi giữa hai nguồn n và r. Thời điểm A nguồn n nhận được gói RR từ nguồn r được ghi lại và trừ đi giá trị của trường LSR của khối báo cáo r để ra được độ trễ tổng cộng. Giá trị thu được lại được trừ đi trường DLSR của khối r để tìm ra độ trễ khứ hồi của gói thông tin giữa n và r.

4.4. Khuôn dạng gói RR

Gói RR (Receiver Reprort) có khuôn dạng giống như gói SR ngoại trừ trường PT mang giá trị bằng 201 và không mang phần thông tin về nguồn gửi. Khuôn dạng gói RR được miêu tả trong hình 5.

0 2 3 8 16 31

V=2 P RC PT = 201 length

SSRC của nguồn gửi gói RR

SSRC_1 (SSRC của nguồn đồng bộ thứ nhất)

fraction lost cumulative number of packets lost

extended highest sequence number received

interarrival jitter

last SR (LSR)

delay since last SR (DLSR)

SSRC_2 (SSRC của nguồn đồng bộ thứ hai)

...

profile-specific extension

Hình 5: Khuôn dạng gói RR

4.5. Khuôn dạng gói SDES

Gói SDES (System Description).

Gói SDES có khuôn dạng như trong hình 6, bao gồm một phần tiêu đề và các đoạn thông tin mô tả nguồn.

1/Phần tiêu đề

- Các trường V (version), P (padding), length, PT (packet type) mang ý nghĩa giống như của gói SR, PT bằng 202.

- SC (Source count): 5 bits.

Số lượng của các đoạn thông tin mô tả nguồn.

0 2 3 8 16 31

V=2 P SC PT = 202 length

SSRC/CSRC_1

SDES các mục mô tả nguồn

...

SSRC/CSRC_2

...

Hình 6: Khuôn dạng gói SDES

2/Phần miêu tả nguồn

Mỗi đoạn thông tin miêu tả nguồn bao gồm một cặp số nhận dạng nguồn SSRC/CSRC theo sau đó là các mục miêu tả (SDES Items). Các mục miêu tả có cấu trúc chung như hình 7.

0 8 16 31

Item length Thông tin mô tả nguồn

Hình 7: Mục miêu tả

- Item (8 bits).

Chỉ thị loại mục mô tả. Giá trị của trường này tương ứng với các loại mục miêu tả sau:

CNAME (Canonical Name) (item = 1): Phần thông tin mô tả mang số nhận dạng tầng giao vận cố định đối với một nguồn RTP.

NAME (item = 2): phần thông tin mô tả mang tên mô tả nguồn.

EMAIL (item = 3): Thông tin mô tả là địa chỉ Email của nguồn.

PHONE (item = 4): Thông tin mô tả là số điện thoại của nguồn.

LOC (item = 5): Thông tin mô tả là địa chỉ của nguồn.

TOOL (item = 6): Thông tin mô tả là tên của ứng dụng tạo ra dòng thông tin media.

NOTE (item = 7): Các chú thích về nguồn.

PRIV (item = 8): Dành cho các thông tin khác.

4.6. Khuôn dạng gói BYE

Gói BYE được sử dụng để thông báo một hay một vài nguồn sẽ rời khỏi phiên truyền. Trường thông tin về lý do rời khỏi phiên là tuỳ chọn (có thể có hoặc không).

0 2 3 8 16 31

V=2 P SC PT = 203 length

SSRC/CSRC

...

Length reson for leaving (opt)

Hình 8: Khuôn dạng gói BYE

4.7. Khuôn dạng gói APP

Khuôn dạng gói APP được miêu tả trong hình 9. Gói này được sử dụng để dành cho các chức năng cụ thể của từng ứng dụng.

0 2 3 8 16 31

V=2 P SC PT = 204 length

Name (ASCII)

Dữ liệu của ứng dụng

Hình 9: Khuôn dạng gói APP