Luận văn Nghiên cứu và xây dựng chương trình truyền thông đa phương tiện

chính xác và đo lường tốc độ đến của các gói RTP. Tần số đồng hồ phụ thuộc vào dữ liệu được truyền và được đặc tả một cách tĩnh trong profile hoặc trong đặc tả của định dạng payload, tần số này cũng có thể được xác định một cách linh động qua các phương tiện khác RTP. Giá trị ban đầu của timestamp cũng là một số ngẫu nhiên như sequence number. Về mặc logical, vài gói RTP liên tiếp có thể có cùng timestamp nếu chúng được tạo ra cùng một lúc. SSRC: 32 bit Trường SSRC định danh một nguồn đồng bộ. Định danh này là ngẫu nhiên nhằm mục đích để bất cứ hai nguồn đồng bộ nào trong cùng một phiên RTP không có cùng một định danh. Tuy nhiền, các cài đặt của RTP phải chuẩn bị cho việ phát hiện và xử lý đụng độ. Danh sách CSRC: Có từ 0 đến 15 mục, mỗi mục có chiều dài 32 bits. Danh sách CSRC xác định các nguồn kết hợp cho payload được chứa trong mỗi gói RTP. Số lượng các định danh được xác định bởi trường Nghiên cứu và xây dựng chương trình truyền thông đa phương tiện Trần Thanh Long - Nguyễn Thành Nam 43 CC. Nếu có nhiều hơn 15 nguồn kết hợp thì chỉ có 15 nguồn đầu được định danh. Các định danh CSRC được thêm vào gói RTP bởi các mixer. 4.2. Ghép kênh các phiên RTP (Multiplexing RTP sessions): Để xử lý một cách hiệu quả thì số lượng các phiên RTP được đem ghép kênh càng nhỏ càng tốt. Trong RTP, sự ghép kênh thực hiện được nhờ vào địa chỉ truyền đích (distination transport address) xác định nên một phiên RTP. Ví dụ: trong một cuộc hội thảo từ xa bằng âm thanh và hình ảnh mà các dữ liệu này được mã hóa bởi hai bộ phận riêng biệt cho âm thanh và hình ảnh, thì các dữ liệu này nên được truyền trên hai phiên RTP khác nhau với địa chỉ đích và số hiệu port riêng. Nếu truyền chung trong một phiên RTP, việc xen kẽ các gói với các kiểu payload khác nhau nhưng cùng một định danh SSRC sẽ dẫn đến một số vấn đề sau: 1. Nếu một kiểu payload được chuyển đổi trong một phiên, sẽ không có cách thức tổng quát để xác định được kiểu payload cũ và kiểu payload mới trong việc thay thế. 2. SSRC được định nghĩa để xác định một cách tính giờ và không gian số thứ tự riêng. Do đó, việc truyền xen kẽ nhiều loại payload sẽ cần nhiều cách tính giờ khác nhau nếu xung nhịp đồng hồ của mỗi kiểu payload khác nhau và cũng sẽ cần nhiều không gian số thứ tự hơn để biết các packet của loại payload nào bị mất. 3. Thông báo của bên gửi và bên nhận RTCP có thể chỉ mô tả một cách tính giờ và một không gian số thứ tự riêng cho mỗi một SSRC và không chứa trường kiểu của payload. 4. RTP mixer không thể kết hợp các luồng dữ liệu xen kẽ không tương thích nhau thành một luồng. 5. Truyền nhiều loại dữ liệu trong cùng một RTP session sẽ không có được các khả năng: Nghiên cứu và xây dựng chương trình truyền thông đa phương tiện Trần Thanh Long - Nguyễn Thành Nam 44 ƒ Sử dụng sự phân phối các đường mạng và tài nguyên mạng khác nhau nếu có thể. ƒ Chỉ nhận được một số loại dữ liệu trong số nhiều loại yêu cầu ví như chỉ nhận được âm thanh nếu tín hiệu hình ảnh vượt quá băng thông. ƒ Bên nhận cài đặt các xử lý riêng cho mỗi loại dữ liệu. ƒ Ngoài ra, việc dùng nhiều RTP session cho phép các cài đặt xử lý đơn hay đa xử lý. 4.3. Những thay đổi trong đặc tả profile của RTP Header: Cấu trúc của RTP header hiện tại được coi là đầy đủ để đáp ứng tất cả các chức năng cho mọi lớp ứng dụng mà RTP có thể hỗ trợ. Tuy nhiên, với nguyên lý thiết kế ALF, RTP header có thể được cải tiến bằng cách chỉnh sửa hoặc thêm vào các định nghĩa mới vào đặc tả profile của nó trong khi vẫn cho phép các công cụ quản lý và ghi nhận hoạt động độc lập với profile. • Bit đánh dấu (marker) và trường kiểu payload mang các thông tin đặc tả của profile, nhưng chúng được định vị cố định trong header vì có nhiều ứng dụng rất cần đến chúng và nếu không thì có thể đã dành riêng một word (32 bit) chỉ để lưu trữ nó. Các octet chứa những trường này có thể được định nghĩa lại bằng một profile để phù hợp với các yêu cầu khác nhưu ví dụ như thêm hoặc bớt các bit marker. Nếu có nhiều bit marker, thì một bit sẽ được đặt ở vị trí quan trọng nhất của octet vì các bộ giám sát độc lập với profile có thể sử dụng bit marker để quan sát việc mất gói. • Các thông tin yêu cầu thêm vào cho một định dạng payload cụ thể, ví dụ như mã hóa video, nên được lưu trong phần payload của gói tin. Các thông tin thêm vào header đều nằm ở phần bắt đầu của payload hiện tại hoặc là được chỉ định bởi một giá trị dành riêng trong phần data. Nghiên cứu và xây dựng chương trình truyền thông đa phương tiện Trần Thanh Long - Nguyễn Thành Nam 45 • Nếu một lớp cụ thể của ứng dụng cần thêm vào các chức năng độc lập với định dạng của payload thì profile bên dưới của các ứng dụng này sẽ định nghĩa thêm các trường cố định ngay sau trường SSRC trong phần header chuẩn. Những ứng dụng này sẽ có thể truy xuất nhanh chóng và trực tiếp đến các trường thêm vào này, trong các bộ phận điều khiển và ghi nhận độc lập profile vẫn có thể xử lý các gói RTP chỉ với 12 octet đẩu tiên. Nếu đến lúc nào đó các chức năng phụ được nhận thấy là cần thiết độc lập profile thì một phiên bản mới hơn của RTP sẽ được xây dựng để cố định các thay đổi trong header. 4.3.1. Phần RTP header mở rộng (RTP Header Extension): Một cơ chế mở rộng được cung cấp để cho phép thử nghiệm thực thi những chức năng độc lập định dạng payload mới yêu cầu các thông tin bổ sung cần được mang theo trong RTP header. Cơ chế này được thiết kế để phần header mở rộng có thể được bỏ qua bởi các thực thi khác không hỗ trợ phần header mở rộng. Nếu bit X trong RTP header bật thì một phần header mở rộng với kích thước không cố định được nối thêm vào sau phần header chuẩn, ngay sau phần danh sách CSRC nếu danh sách này có trong header. Phần header mở rộng có một trường dài 16 bit cho biết chiều dài của nó tính theo word (32 bit) trừ phần header phụ dài 4 byte. Chỉ có thể thêm được một phần header mở rộng vào RTP header. Tuy nhiên 16 bit đầu tiên của phần header mở rộng 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 defined by profile header extension ……………………… Định dạng RTP Header Extension length Nghiên cứu và xây dựng chương trình truyền thông đa phương tiện Trần Thanh Long - Nguyễn Thành Nam 46 được dành cho mục đích nhận ra định danh hoặc tham số. Định dạng của 16 bit này được định nghĩa bởi đặc tả của profile tương ứng với header mà chúng ta đạng thực thi các hoạt động bên dưới. 5. Giao thức điều khiển RTP (RTP Control Protocol – RTCP): Giao thức điều khiển RTP dựa trên việc truyền các gói điều khiển theo chu kỳ cho mỗi thành viên trong phiên làm việc, sử dụng cùng một cơ chế phân phối như đối với các gói dữ liệu. RTCP thực hiện bốn chức năng sau: 1. Chức năng chính là cung cấp các phản hồi về chất lượng của quá trình phân phối dữ liệu. Đây là phần không thể thiếu trong vai trò chuyển tải của RTP và có liên hệ với các chức năng điều khiển luồng và điều khiển nghẽn mạch của các nghi thức chuyển tải khác. Các phản hồi có thể hữu dụng một cách trực tiếp cho việc kiểm soát việc mã hóa nhưng những thí nghiệm với IP multicasting cho thấy rằng cũng khó để lấy được các phản hồi từ bên nhận để tìm lỗi trong quá trình phân phối. Việc gửi đi các thông tin phản hồi cho các thành phần tham gia cho phép một người có khả năng thấy được các vấn để và xác định vấn đề đó là cục bộ hay chung. Với một cơ chế phân phối như IP multicast, các thực thể không liên quan đến session có thể nhận được các thông tin phản hồi và hoạt động như là một bộ phận điều hành thứ ba để dự đoán các vấn đề về mạng. Chức năng phản hồi này được thực hiện nhờ vào các thông tin của bên gửi và bên nhận. 2. RTCP mang theo một đinh danh ở mức transport cho một nguồn RTP được gọi là CNAME (canonical name). Vì các định danh SSRC có thể thay đổi nếu có xung đột hoặc có một chương trình bị khởi động lại nên bên nhận cần có CNAME để “giữ vết” của mỗi thành phần tham gia. Bên nhận cũng cần CNAME để kết hợp các Nghiên cứu và xây dựng chương trình truyền thông đa phương tiện Trần Thanh Long - Nguyễn Thành Nam 47 phiên RTP có liên hệ với nhau, ví dụ như để đồng bộ âm thanh với hình ảnh. 3. Hai chức năng trên yêu cầu các thành phần tham gia phải gửi các gói RTCP, do đó tốc độ phải được kiểm soát để RTP có thể phục vụ cho một số lượng lớn các thành phần tham gia. Bằng cách gửi các gói điều khiển đến mọi thành phần khác, một thành phần tham gia có thể theo dõi số lượng các thành phần khác một cách độc lập. Con số này được dùng để tính toán tốc độ gửi các gói tin. 4. Chức năng thứ tư là truyền tối thiểu các thông tin kiểm soát phiên làm việc, ví dụ như các thông tin nhận diện của một thành phần tham gia có thể được hiển thị trên giao diện người dùng. Điều này có thể có ích trong các session được kiểm soát lỏng lẻo (là các session mà các thành phần tham gia vào và ra mà không thông báo rõ ràng). RTCP phục vụ như một cách để đến được các thành phần tham gia nhưng không nhất thiết phải hỗ trợ tất cả các yêu cầu về thông tin điều khiển của một ứng dụng. 5.1. Cấu Trúc của gói RTP (RTP Packet Format): Phần này mô tả định nghĩa của một vài loại gói RTCP mang một thông tin điều khiển khác nhau: SR (Sender report): Các thông báo về tình trạng của quá trình truyền và nhận từ các thành phần tham gia đóng vai trò là người gởi. RR (receiver): Các thông báo về trạng thái tiếp nhận từ các thành phần tham gia đóng vai trò là người nhận. SDES (source description items): Các trường mô tả nguồn, bao gổm cả CNAME. BYE: Cho biết kết thúc sự tham dự của một thành phần. APP: Các chức năng cụ thể của ứng dụng. Nghiên cứu và xây dựng chương trình truyền thông đa phương tiện Trần Thanh Long - Nguyễn Thành Nam 48 Mỗi gói RTCP có một phần header cố định, theo sau là các thành phần có cấu trúc với số chiều dài không cố định, tùy vào từng loại gói RTCP, nhưng luôn là bội số của 32 bit. Nhờ sự sắp xếp và chiều dài của một trường cố định trong mỗi thành phần thêm vào giúp cho các gói RTCP có khả năng “stackable”. Một gói RTCP tổng hợp được truyền trong một gói tin đơn của nghi thức nền dưới, ví dụ như UDP, có thể được nối lại từ nhiều gói RTCP khác mà không cần phải tách biệt từng gói. Mỗi gói RTCP riêng trong một gói RTCP tổng hợp có thể được xử lý một cách độc lập không cần dựa trên thứ tự hay cách tổng hợp. Tuy nhiên, để thực hiện các chức năng của giao thức, các điều kiện sau phải được thỏa mãn: 1. Trạng thái tiếp nhận trong các gói SR hay RR nên được truyền càng nhiều càng tốt ở mức giới hạn cho phép của băng thông để cho mức phân giải của các trạng thái là cao nhất. Do đó mỗi gói RTCP tổng hợp được truyền định kì nên có một gói SR hay RR. 2. Những thành viên mới cần nhận được thông tin CNAME của nguồn càng sớm càng tốt để có thể xác định được nguồn và bắt đầu kết hợp các tín hiệu đa phương tiện nhằm nhiều mục đích ví như đồng bộ hóa. Do đó, mỗi gói RTCP kết hợp nên bao gồm thêm một gói SDES CNAME. 3. Số lượng các kiểu packet mà có thể xuất hiện đầu tiên trong gói RTCP kết hợp nên được giới hạn để tăng lượng các bit hằng trong word đầu tiên và tăng xác suất thành công của việc kiểm tra tính đúng đắn của các gói RTCP đối với các gói RTP sai địa chỉ hoặc các gói không liên quan. Do vậy, cần phải gửi ít nhất hai gói RTCP riêng biệt trong một gói RTCP kết hợp, với các định dạng đề nghị như sau: a. Encryption prefix: Đây là một số ngẫu nhiên 32 bit được đặt trước mỗi một gói kết hợp được truyền nếu và chỉ nếu gói kết hợp này được mã hoá. Nghiên cứu và xây dựng chương trình truyền thông đa phương tiện Trần Thanh Long - Nguyễn Thành Nam 49 b. SR hay RR: Gói RTCP đầu tiên trong gói RTCP kết hợp phải luôn là gói thông báo để quá trình kiểm tra header được dễ dàng. Điều này vẫn đúng nếu không có dữ liệu truyền và nhận, trường hợp gói RR rỗng được gởi, và chỉ duy nhất một trường khác trong gói RTCP kết hợp là BYE. c. Thêm các gói RR: Nếu số lượng nguồn được thông báo vượt quá 31 (là lượng tối đa mà một gói RR hay SR có thể chứa) thì các gói RR dư ra nên được đặt ngay sau gói thông báo khởi đầu. d. SDES: Một gói SDES chứa mục NNAME phải luôn có trong một gói RTCP kết hợp. Các mục mô tả nguồn khác tuỳ ý có thể được gộp vào nếu cần thiết bởi một ứng dụng cụ thể, tùy vào các ràng buộc về băng thông. e. BYE hoặc APP: Các kiểu gói RTCP khác, kể cả các kiểu chưa được định nghĩa, có thể được đặt theo thứ tự bất kỳ trong gói kết hợp, ngoại trừ gói BYE nên được đặt cuối cùng. 5.2. Các thông báo của bên gửi và bên nhận ( Sender and Receiver reports ): Bên nhận RTP thông qua các gói RTCP để cung cấp các thông tin phản hồi về tình trạng nhận dữ liệu của mình ở một trong hai dạng tùy thuộc vào việc bên nhận có đồng thời là bên gửi hay không. Ngoài mã kiểu, sự khác biệt duy nhất giữa thông tin bên nhận (RR) và bên gửi (SR) là: thông tin bên gửi bao gồm phần thông tin người gửi dài 20 bytes được sử dụng cho những người gửi đang hoạt động. SR được phát ra nếu một vị trí nào đó gửi bất cứ gói dữ liệu nào trong khoảng thời gian chờ giữa hai lần gửi thông báo, ngược lại là RR. Cả SR và RR có thể có hoặc không các khối thông tin nhận (reception report blocks), mỗi khối đại diện cho mỗi nguồn kết hợp (synchronization source) mà từ đó bên nhận đã nhận được các gói dữ liệu RTP kể từ thông báo Nghiên cứu và xây dựng chương trình truyền thông đa phương tiện Trần Thanh Long - Nguyễn Thành Nam 50 được gửi gần nhất. Các thông báo không được sử dụng cho các nguồn kết hợp (contributing source) được liệt kê trong danh sách CSRC. Mỗi khối nhận cho biết thông tin về tình trạng dữ liệu nhận được từ một nguồn cụ thể được chỉ định rõ trong khối đó. Vì mỗi gói RR hay SR chỉ có thể chứa tối đa 31 khối, nếu cần thiết cho các gói thông báo, các khối dư ra có thể được gắn sau gói SR hay RR thiết lập. Dưới đây, ta sẽ tìm hiểu về định dạng của các gói thông báo RTCP: a. SR – Sender Report RTCP packet format: Gói thông báo bên nhận gồm ba phần, có thể có thêm phần đặc tả profile mở rộng nếu được định nghĩa. Phần đầu có chiều dài 8 octet. Ý nghĩa của các trường: Version (V): 2 bit Định danh của version của RTP. Giá trị này giống nhau cho các gói dữ liệu RTP và RTCP. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 V = 2 P RC PT = SR = 200 Length SSRC of sender NTP timestamp, most significant word profile-specific extensions Định dạng SR NTP timestamp, least significant word RTP timestamp sender’s packet count sender’s octet count SSRC_1 (SSRC of first source) fraction lost cumulative number of packets lost extended highest sequence number received iterarrival jitter last SR (LSR) delay since last SR (DLSR) SSRC_2 (SSRC of second source) ………………. header sender info report block 1 report block 2 Nghiên cứu và xây dựng chương trình truyền thông đa phương tiện Trần Thanh Long - Nguyễn Thành Nam 51 Padding (P): 1 bit Nếu bit padding bật, thì gói RTCP này được nối thêm các octets vào cuối phần dữ liệu, octet cuối cùng trong số các octet được nỗi thêm vào cho biết có bao nhiêu octet cần được bỏ qua. Trong gói RTCP kết hợp, chỉ cần thêm các octet vào gói RTCP đơn cuối cùng vì gói kết hợp được mã hóa toàn bộ. Reception report count (RC): 5 bit Số lượng các khối thông báo nhận được chứa trong gói này. Trường này có thể bằng 0. Packet type (PT): 8 bit Mang giá trị 200 để xác định gói này là gói RTCP kiểu SR. Length: 16 bit Độ dài tính theo word 32 bit của gói RTCP trừ đi một, bao gồm cả phần header và phần padding. SSRC: 32 bit Định danh của nguồn đồng bộ của nơi gửi gói RTCP này. Phần thứ hai dài 20 octet là phần thông tin người gửi (sender information) có trong mọi gói thông báo bên gửi (sender report packet). NTP timestamp: 64 bit Chỉ ra thời điểm gói này được gửi đi. RTP timestamp: 32 bit Mang cùng giá trị với NTP timestamp nhưng chỉ cùng đơn vị và cùng một độ dời với RTP timestamp trong gói dữ liệu. Sender’s packet count: 32 bit Tổng số gói RTCP đã truyền bởi bên gửi kể từ khi bắt đầu truyền cho đến thời điểm gói này được tạo. Số đếm này sẽ được khởi tạo lại mỗi khi bên gửi thay đổi định danh SSRC. Nghiên cứu và xây dựng chương trình truyền thông đa phương tiện Trần Thanh Long - Nguyễn Thành Nam 52 Sender’s octet count: 32 bit Tổng số payload octet (không bao gồm header và phần padding) đã truyền trong gói dữ liệu RTP bởi bên gửi kể từ khi bắt đầu truyền cho đến thời điểm gói tin này được tạo. Số đếm này sẽ được khởi tạo lại mỗi khi bên gửi thay đổi định danh SSRC của nó. Trường này có thể được dùng để ước lượng tốc độ truyền dữ liệu payload trung bình. Phần thứ ba chứa hoặc không các khối thông báo nhận phụ thuộc vào số lượng nguồn khác mà bên gởi nghe được từ thông báo cuối. Mỗi gói thông báo lưu tình trạng nhận của gói tin RTP từ một nguồn đồng bộ đơn. b. RR – Receiver Report RTCP packet format: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 V = 2 P RC PT = SR = 201 Length SSRC of sender profile-specific extensions Định dạng RR SSRC_1 (SSRC of first source) fraction lost cumulative number of packets lost extended highest sequence number received iterarrival jitter last SR (LSR) delay since last SR (DLSR) SSRC_2 (SSRC of second source) ………………. header report block 1 report block 2 Nghiên cứu và xây dựng chương trình truyền thông đa phương tiện Trần Thanh Long - Nguyễn Thành Nam 53 c. SDES – Source Description RTCP packet format: d. CNAME – Canonical end point identifier SDES item: e. NAME – Uer name SDES item: f. EMAIL – Electronic mail address SDES item: g. Phone – phone number SDES item: Định dạng SDES 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 V = 2 P RC PT = SR = 202 Length SSRC/CSRC_1 SDES items …….. SSRC/CSRC_2 SDES items …….. Định dạng CNAME 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 length user and domain name … CNAME = 1 Định dạng NAME 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 length common name source … NAME = 2 Định dạng EMAIL 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 length mmail address of source … EMAIL = 3 Định dạng PHONE 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 length phone number of source … PHONE = 4 Nghiên cứu và xây dựng chương trình truyền thông đa phương tiện Trần Thanh Long - Nguyễn Thành Nam 54 h. LOC – Geographic user location SDES item: i. TOOL – Application or tool name SDES item: j. NOTE – Notice/status SDES item: k. PRIV – Private extensions SDES item: l. BYE – Goodbye RTCP packet: Định dạng LOC 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 length geographic location of source … LOC = 5 Định dạng TOOL 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 length name/ version of source appliaction… TOOL = 6 Định dạng NOTE 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 length note about the source… NOTE = 7 Định dạng PRIV 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 length PRIV = 8 value string… prefix length prefix string… Định dạng BYE 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 V = 2 P SC PT = BYE = 203 length SSRC/CSRC …….. length reason for leaving Nghiên cứu và xây dựng chương trình truyền thông đa phương tiện Trần Thanh Long - Nguyễn Thành Nam 55 m. APP – Application defined RTCP lacket: Định dạng APP 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 V = 2 P subtype PT = APP = 204 length SSRC/CSRC name (ASCII) application dependent data Nghiên cứu và xây dựng chương trình truyền thông đa phương tiện Trần Thanh Long - Nguyễn Thành Nam 56 CHƯƠNG 5: TÌM HIỂU CHUẨN H.323 VÀ THƯ VIỆN OPENH323 1. Giới thiệu: Đây là một khuyến cáo của ITU, được phê chuẩn vào năm 1996 (phiên bản 2 được phê chuẩn vào tháng 1 năm 1998), nó đề những tiêu chuẩn cho truyền thông đa phương tiện qua mạng LAN mà không đảm bảo chất lượng dịch vụ. Cung cấp nền tảng cho việc truyền thông dữ liệu, hình ảnh, âm thanh qua mạng IP. Dựa vào chuẩn H.323, các sản phẩm và ứng dụng truyền thông đa phương tiện từ nhiều nhà cung cấp có thể liên kết hoạt động được với nhau, cho phép người dùng giao tiếp với nhau mà không cần xem xét đến sự tương thích. H.323 là một bộ phận của một loạt các chuẩn truyền thông đa phương tiện trên các mạng khác như H.324 cho mạng SCN, H.321 cho mạng B_ISDN, H.320 cho mạng ISDN v.v… nhờ vậy cung cấp sự tương thích giữa mạng LAN và các mạng khác. Và OpenH323 là một lớp thư viện bổ sung cho giao thức H.323. Thư viện này được sử dụng để phát triển các ứng dụng sử dụng giao thức H.323 trong truyền thông đa phương tiện. Chúng ta sẽ lần lượt đi sâu vào các vấn đề trên để hiểu rõ thêm về chuẩn H.323 và thư viện OpenH323. 2. Chuẩn H.323: 2.1. Các ưu điểm của chuẩn H.323: • Cung cấp các bộ mã hoá đã được chuẩn hoá: H.323 thiết lập các chuẩn nén và giải nén luồng dữ liệu audio và video, bảo đảm cho các thiết bị từ các nhà cung cấp khác nhau có sự hỗ trợ chung. Nghiên cứu và xây dựng chương trình truyền thông đa phương tiện Trần Thanh Long - Nguyễn Thành Nam 57 • Tính tương thích cao: Người sử dụng có thể trao đổi dữ liệu mà không phải lo lắng về tính tương thích ở bên nhận. Bên cạnh việc đảm bảo bên nhận có thể giải nén thông tin nhận được, H.323 còn thiết lập một phương thức cho phép bên nhận có thể trao đổi khả năng nhận thông tin của mình với bên gởi. • Độc lập phần cứng: H.323 được thiết kế để chạy ở tầng trên của kiến trúc mạng. Những giải pháp cơ bản của H.323 cho phép tận dụng được những cải tiến về kỹ thuật mạng và sự phát triển băng thông. • Độc lập với ứng dụng và hệ điều hành: H.322 không bị ràng buộc với phần cứng hay hệ điều hành. • Hỗ trợ đa điểm: Tuy H.323 có thể quản lý được những cuộc hội nghị có nhiều kết nối mà không cần sử dụng thêm một trình điều khiển đa điểm chuyên dụng nào, nhưng việc sử dụng MCU (Multipoint Control Unit – trình điều khiển đa điểm) sẽ cung cấp một kiến trúc mạnh và linh hoạt hơn cho hội nghị kiểu nhiều kết nối. • Quản lý được băng thông: Việc truyền các dữ liệu truyền thông đa phương tiện đòi hỏi băng thông rất lớn và có thể làm nghẽn mạch. Để giải quyết vấn đề này, H.323 đưa ra trình quản lý băng thông. Nhân viên quản trị mạng có thể giới hạn số kết nối H.323 hay giới hạn băng thông cho các ứng dụng sử dụng H.323. Điều này đảm bảo cho sự lưu thông trên mạng không bị tắt nghẽn. • Hỗ trợ khả năng quản bá thông tin: Giúp cho việc sử dụng băng thông hiệu quả hơn. Nghiên cứu và xây dựng chương trình truyền thông đa phương tiện Trần Thanh Long - Nguyễn Thành Nam 58 • Linh hoạt: Một hội nghị sử dụng chuẩn H.323 có khả năng tiếp nhận các thiết bị đầu cuối khác nhau. Ví du: một terminal chỉ hỗ trợ khả năng truyền và nhận âm thanh có thể tham gia hội nghị với các máy hỗ trợ khả năng truyền dữ liệu và hình ảnh. Máy sử dụng chuẩn H.323 có thể chia sẽ dữ liệu, âm thanh, hình ảnh với các máy khác. • Khả năng hội nghị liên mạng: Nhiều người dùng muốn kết nối từ mạng LAN đến một đầu xa chẳng hạn như kết nối giữa hệ thống LAN với hệ thống ISDN. H.323 cũng hỗ trợ khả năng này và sử dụng kỹ thuật mã hoá chung từ các chuẩn hội nghị khác nhau để giảm thiểu thời gian chuyển đổi mã và tạo một hiệu suất tối ưu cho hội nghị. 2.2. Kiến trúc hệ thống H.323: Chuẩn H.323 của ITU là một tập hợp các tiểu chuẩn, giao thức liên quan đến truyền thông âm thanh và hình ảnh trong mạng LAN mà chất lượng dịch vụ không bảo đảm. Kiến trúc của H.323 không bao gồm cả mạng LAN hay tầng transport dùng để kết nối giữa các mạng LAN khác mà chỉ có những thành phần cần thiết cho việc tương tác với mạng chuyển mạch điện tử SCN (Switched Circuit Network). H.323 gồm có bốn thành phần chính cho một hệ thống truyền tin trên mạng đó là: Terminal, Gateway, Gatekeeper và MCU. H.323 Terminal H.323 Terminal H.323 Terminal H.323 MCU H.323 Gateway H.323 Gatekeeper H.323 Router H.323 Terminal H.323 Terminal H.323 Router H.323 Zone Các thành phần trong hệ thống H.323 Nghiên cứu và xây dựng chương trình truyền thông đa phương tiện Trần Thanh Long - Nguyễn Thành Nam 59 2.2.1. Terminal: Terminal là các máy khách hay các thiết bị đầu cuối trên mạng LAN tham gia truyền thông thời gian thực. Một H.323 terminal có thể là một máy điện thoại hay một PC chạy ứng dụng H.323. Một H.323 terminal phải hỗ trợ tối thiểu truyền thông thoại còn dữ l