Đề tài Nghiên cứu và xây dựng chương trình truyền thông đa phương tiệ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 1 CHƯƠNG 0: GIỚI THIỆU................................................................................................4 CHƯƠNG 1: TÌM HIỂU CÁC CHUẨN NÉN ÂM THANH..........................................6 1. Giới thiệu: ...............................................................................................................6 2. Chuẩn nén G.711: ...................................................................................................6 2.1. Giới thiệu:......................................................................................................6 2.2. Tốc độ lấy mẫu: .............................................................................................6 2.3. Quy luật mã hoá: ...........................................................................................7 2.4. Truyền tín hiệu ký tự:.....................................................................................7 2.5. Mối liên hệ giữa luật mã hóa và cấp độ âm thanh:.......................................7 2.6. Sự chuyển đổi giữa A-law và µ-law : ............................................................8 2.7. Sự chuyển đổi giữa µ-law và A-law: .............................................................9 3. Chuẩn nén G.723: .................................................................................................12 3.1. Giới thiệu:....................................................................................................12 3.2. Cơ chế mã hóa:............................................................................................12 3.3. Cơ chế giải mã:............................................................................................14 4. Chuẩn nén G.729: .................................................................................................15 4.1. Giới thiệu:....................................................................................................15 4.2. Mô tả chung về bộ mã CS-ACELP: .............................................................15 4.2.1.Nguyên lý mã hóa: ......................................................................................16 4.2.2.Nguyên lý giải mã: ......................................................................................18 CHƯƠNG 2: TÌM HIỂU CÁC CHUẨN NÉN HÌNH ẢNH..........................................20 1. Giới thiệu: .............................................................................................................20 2. Chuẩn nén H.261: .................................................................................................20 2.1. Giới thiệu:....................................................................................................20 2.2. Đinh dạng ảnh nguồn của chuẩn H.261......................................................20 2.3. Ghép kênh H.261 (H.261 Multiplexing): .....................................................22 2.3.1.Picture layer: ..............................................................................................22 2.3.2.Group of blocks (GOB):..............................................................................23 2.3.3.Macroblocks: ..............................................................................................24 2.3.4.Block: ..........................................................................................................26 3. Chuẩn nén H.263: .................................................................................................26 3.1. Giới thiệu:....................................................................................................26 3.2. Những khác biệt giữa H.263 và H.261:.......................................................27 3.2.1.SubQCIF: ....................................................................................................27 3.2.2.Cách tính độ sai lệch tốt hơn: .....................................................................27 3.2.3.Độ chính xác trong việc dự đoán:...............................................................27 3.2.4.Cách xử lý truyền macroblock: ...................................................................27 CHƯƠNG 3: TÌM HIỂU VỀ VOICE OVER IP............................................................28 1. Giới thiệu về VoIP: ...............................................................................................28 2. Ưu điểm của VoIP so với PSTN:..........................................................................28 2.1. Tiết kiệm băng thông: ..................................................................................28 2.2. Đơn giản hóa:..............................................................................................29 2.3. Khả năng tích hợp: ......................................................................................29 2.4. Uyển chuyển trong quản lý:.........................................................................29 2.5. Quản lý tốt: ..................................................................................................29 2.6. Giá thành thấp:............................................................................................30 3. Các hình thức truyền thoại trên mạng IP: .............................................................30 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 2 3.1. PC-PC : .......................................................................................................30 3.2. PC – Phone :................................................................................................30 3.3. Phone - Internet - Phone : ...........................................................................30 4. Nguyên tắc và mô hình hoạt động của VoIP: .......................................................31 4.1. Quá trình thiết lập một kết nối VoIP : .........................................................31 4.2. Mô hình hoạt động của VoIP:......................................................................31 5. Các nghi thức được sử dụng trong hệ thống VoIP:...............................................31 5.1. Giao thức UDP (User Datagram Protocol): ...............................................31 5.2. Giao thức RTP (Realtime Protocol): ...........................................................32 5.3. Giao thức RTCP ( RTP Control Protocol ): ................................................32 5.4. Giao thức RSVP:..........................................................................................32 5.5. SGCP: ..........................................................................................................33 5.6. MGCP:.........................................................................................................34 6. Các vấn đề liên quan đến chất lượng dịch vụ : .....................................................34 6.1. Mất gói và các giải pháp khắc phục tình trạng này: ...................................34 6.1.1.Tổng quan: ..................................................................................................34 6.1.2.Các giải pháp khắc phục: ...........................................................................34 6.2. Trễ gói..........................................................................................................35 6.2.1.Tổng quan ...................................................................................................35 6.2.2.Có hai giải pháp: ........................................................................................35 6.3. Network Jitter ..............................................................................................35 6.4. Kết luận: ......................................................................................................36 CHƯƠNG 4: TÌM HIỂU CÁC NGHI THỨC TRUYỀN THÔNG THỜI GIAN THỰC RTP (REALTIME PROTOCOL).......................................................................37 1. Giới thiệu giao thức RTP (Realtime Protocol): ....................................................37 2. Các khái niệm và định nghĩa được sử dụng trong RTP: .......................................37 3. Thứ tự byte, alignment và định dạng thời gian: ....................................................40 4. Nghi thức truyền dữ liệu RTP (RTP Data Transfer Protocol): .............................40 4.1. Các trường cố định trong RTP header:.......................................................40 4.2. Ghép kênh các phiên RTP (Multiplexing RTP sessions): ............................43 4.3. Những thay đổi trong đặc tả profile của RTP Header: ...............................44 4.3.1.Phần RTP header mở rộng (RTP Header Extension):................................45 5. Giao thức điều khiển RTP (RTP Control Protocol – RTCP): ...............................46 5.1. Cấu Trúc của gói RTP (RTP Packet Format): ............................................47 5.2. Các thông báo của bên gửi và bên nhận ( Sender and Receiver reports ):.49 CHƯƠNG 5: TÌM HIỂU CHUẨN H.323 VÀ THƯ VIỆN OPENH323 ......................56 1. Giới thiệu: .............................................................................................................56 2. Chuẩn H.323: ........................................................................................................56 2.1. Các ưu điểm của chuẩn H.323: ...................................................................56 2.2. Kiến trúc hệ thống H.323: ...........................................................................58 2.2.1.Terminal:.....................................................................................................59 2.2.2.Gateway: .....................................................................................................60 2.2.3.Gatekeeper: .................................................................................................61 2.2.4.MCU (Multipoint Control Unit): ................................................................63 2.3. Sơ đồ cấu trúc phân lớp: .............................................................................64 2.3.1.Video Codec:...............................................................................................65 2.3.2.Audio Codec:...............................................................................................65 2.3.3.Data Channel (Kênh dữ liệu):.....................................................................66 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 3 2.4. Điều khiển hệ thống:....................................................................................66 2.4.1.Chức năng điều khiển H.245: .....................................................................66 2.4.2.Chức năng báo hiệu RAS H.225.0: .............................................................67 2.4.3.Chức năng báo hiệu cuộc gọi H.225.0: ......................................................68 2.5. Hội nghị đa điểm: ........................................................................................70 2.5.1.Hội nghị đa điểm tập trung:........................................................................70 2.5.2.Hội nghị đa điểm phân tán: ........................................................................71 2.5.3.Hội nghị đa điểm tập trung và phân tán kết hợp: .......................................71 2.6. Quy trình thiết lập cuộc gọi qua mạng H.323: ............................................71 2.7. Mối quan hệ giữa nghi thức H323 và mô hình OSI: ...................................77 2.8. Tổng kết: ......................................................................................................77 3. Thư viện OpenH323..............................................................................................78 3.1. Giới thiệu:....................................................................................................78 3.2. Cấu trúc phân lớp và phương thức hoạt động: ...........................................78 3.2.1.Cấu trúc phân lớp: ......................................................................................78 3.2.2.Ý nghĩa một số lớp trong thư viện:..............................................................81 3.3. Phương thức hoạt động: ..............................................................................85 CHƯƠNG 6: XÂY DỰNG ỨNG DỤNG TRUYỀN THÔNG ĐA PHƯƠNG TIỆN THỂ NGHIỆM ..................................................................................................................88 1. Mô hình thực tế: ....................................................................................................88 2. Xác định các yêu cầu: ...........................................................................................88 2.1. Các yêu cầu chức năng:...............................................................................88 2.2. Các yêu cầu phi chức năng: ........................................................................89 2.3. Mô hình giao tiếp giữa các thành phần trong hệ thống: .............................90 3. Đặc tả chung cho hệ thống và sơ đồ khối của các yêu cầu: ..................................91 3.1. Đặc tả chung cho hệ thống:.........................................................................91 3.2. Sơ đồ khối của một vài chức năng của client: .............................................92 4. Thiết kế cơ sở dữ liệu:.........................................................................................100 4.1. Các trường của bảng lưu thông tin user như sau:.....................................100 4.2. Các trường của bảng lưu thông tin danh sách các user trong contact list101 5. Thiết kế giao diện:...............................................................................................101 6. Cách thực thi hệ thống: .......................................................................................110 7. Cài đặt chương trình:...........................................................................................111 8. Đánh giá kết quả xây dựng ứng dụng: ................................................................111 9. Hướng phát triển chương trình:...........................................................................112 TỔNG KẾT .....................................................................................................................114 BẢNG THAM CHIẾU CÁC TỪ VIẾT TẮT ...............................................................115 CÁC TÀI LIỆU THAM KHẢO ....................................................................................118 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 4 CHƯƠNG 0: GIỚI THIỆU Hiện nay với sự phát triển của xã hội, các dịch vụ, các ứng dụng về truyền thông đa phương tiện như điện thoại, nhắn tin, nghe nhac, xem phim, v.v… không còn xa lạ với mọi người. Song song với sự phát triển của xã hội hiện nay là sự phát triển của mạng máy tính, trong đó có mạng truyền thông đa phương tiện. Trong những năm trước đây, các dịch vụ truyền thông đa phương tiện đều rất khó thực hiện bởi vì ít có sự hỗ trợ về phần cứng, băng thông chính là điểm khó khăn cho việc truyền và nhận các tín hiệu âm thanh và hình ảnh. Tuy nhiên, với kỹ thuật phát triển như hiện nay, các tín hiệu âm thanh và hình ảnh có thể được nén và giải nén môt cách dễ dàng và băng thông không còn là vấn đề trở ngại đối với việc truyền nhận tín hiệu âm thanh, hình ảnh. Hội nghị video (video conference) là một minh chứng rất thuyết phục cho khả năng này của mạng truyền thông đa phương tiện hiện nay. Những kỹ thuật để phục vụ cho mạng truyền thông đa phương tiện hiện nay đã được nhiều người đi trước nghiên cứu chuyên sâu, tuy nhiên việc kết hợp các kỹ thuật này lại là một vấn đề mới, thú vị và rất cần thiết cho cuộc sống hiện nay. Do vậy, chúng em đã chọn đề tài “Nghiên cứu và xây dựng chương trình truyền thông đa phương tiện tích hợp” để làm đề tài luận văn tốt nghiệp của mình. Mục tiêu của đề tài là tìm hiểu các chuẩn truyền thông thời gian thực, các chuẩn nén âm thanh, hình ảnh, nghiên cứu bộ thư viện giao diện lập trình OpenH323 và từ những kết quả tìm hiểu được, xây dựng một hệ thống truyền thông giao tiếp trực tuyến sử dụng máy tính giữa nhiều người dùng trong các tổ chức hoặc công ty hoạt động phân tán tại nhiều vùng địa lý khác nhau, hoặc giữa các trường đại học, sử dụng cơ sở hạ tầng mạng nối kết giữa các vị trí đó (mạng cục bộ, đường truyền thuê bao riêng hoặc Internet). 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 5 Phương thức giao tiếp cho phép đa dạng, gồm nhiều phương thức thông qua nhiều loại phương tiện thông tin khác nhau (thông điệp ngắn, âm thanh, hình ảnh ..) nhằm đáp ứng những nhu cầu thông tin và điều kiện môi trường trong thực tế. Ngoài ra hệ thống còn cần có khả năng nối kết với phương tiện truyền thông truyền thống đang được sử dụng phổ biến như điện thoại để bàn nối kết với hệ thống điện thoại công cộng, điện thoại di động và hệ thống thư điện tử. Sự kết nối tích hợp này sẽ giúp làm tăng khả năng thông tin liên lạc xuyên suốt giữa các người dùng. Với khả năng còn hạn chế, luận văn này vẫn còn nhiều điều chưa hoàn tất, kính mong sự đóng góp ý kiến và giúp đỡ của quý thầy cô. Thành phố Hồ Chí Minh, 7/2003 Trần Thanh Long - Nguyễn Thành Nam 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 6 CHƯƠNG 1: TÌM HIỂU CÁC CHUẨN NÉN ÂM THANH 1. Giới thiệu: Như chúng ta đã biết, các tín hiệu âm thanh có dung lượng rất lớn nên rất khó khăn cho việc truyền dẫn mà vẫn đạt được một chất lượng tương đối trên cơ sở hạ tầng mạng hiện nay. Do vậy, việc nén các luồng âm thanh để có thể truyền trên băng thông thấp với chất lượng dịch vụ cao là một điều rất cần thiết. Hiệp hội viễn thông quốc tế, ITU-T ( International Telecommunication Union – Telecommunication ) đã đưa ra những chuẩn nén âm thanh mới nhất như G728, G729, G723.1 v.v… dành cho băng thông thoại thấp với tần số 300 Hz đến 3,4kHz. Tất cả các chuẩn này đều dựa trên chuẩn mã hóa CELP (Code-Excited Linear Prediction). Chuẩn nén âm thanh đã được tiêu chuẩn hóa trong mã ANSI-C với 2 lý do chính: • Độ tin cậy khi tương tác giữa các thiết bị. • Giá thành thấp và những tiện ích thực thi dựa trên 16 bit fixpoint DSP. 2. Chuẩn nén G.711: 2.1. Giới thiệu: Chuẩn G.711 là một chuẩn nén âm thanh được sử dụng rộng rãi cho các hội nghị âm thanh. Chuẩn này mô tả phương pháp mã hoá và giải mã âm thanh với tốc độ 64Kbps. 2.2. Tốc độ lấy mẫu: Một giá trị được đề nghị của tần số lấy mẫu là 8000 samples/giây. Độ sai sót thường là +/- 50 phần triệu. 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 7 2.3. Quy luật mã hoá: Mỗi mẫu âm thanh là một số nhị phân có tám bit được sử dụng cho phạm vi toàn cầu. ITU – T đưa ra hai quy luật mã hóa là mã hóa theo quy luật A và mã hóa theo quy luật µ. Khi sử dụng luật mã hóa µ trong mạng truyền thông thì việc chặn tất cả các tín hiệu ký tự 0 là yêu cầu nhất thiết. Giá trị lượng tử hóa là kết quả của luật mã hóa. Bất cứ sự chuyển đổi cần thiết giữa các quốc gia đều sử dụng quy luật µ. Sự chuyển đổi PCM: Giá trị ấn định (decision value) và giá trị lượng tử (quantizer value) của A-law được kết hợp với giá trị đồng dạng PCM. Sự chuyển đổi từ A-law hoặc µ-law từ giá trị đồng dạng PCM tương ứng với giá trị ấn đinh là một phần chỉ định của giá trị riêng lẽ. 2.4. Truyền tín hiệu ký tự: Khi tín hiệu ký tự được truyền tuần tự trong một tầng vật lý, bit số 1 (bit dấu) được truyền trước tiên và bit số 8 (bit ít có ý nghĩa nhất) được truyền cuối cùng. 2.5. Mối liên hệ giữa luật mã hóa và cấp độ âm thanh: Tín hiệu sóng hình sin 1kHz ở cấp độ nhỏ của 0 dBm0 được thể hiện ở bất cứ tần số âm thanh nào ở đẩu ra của bộ ghép kênh PCM khi một chuổi tín hiệu định kỳ của A-law (table 1) và µ-law (table 2) được dùng ở đẩu vào của bộ giải mã. Theo kết quả lý thuyết, giá trị Tmax = +3.14 dBm0 ứng với A-law và Tmax = +3.17 dBm0 ứng với µ-law. 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 8 2.6. Sự chuyển đổi giữa A-law và µ-law : Xem Table 3. Ghi chú: • Tín hiệu đầu vào của bộ giải mã A-law sẽ bao gồm sự đảo ngược các bit chẳn của giá trị đưa vào. Do đó tín hiệu đầu ra của bộ chuyển đổi µ-A sẽ có quá trình chuyển đổi các bit chẳn được thể hiện trong bộ chuyển đổi ở đầu ra. • Nếu bộ chuyển đổi µ-A được thay bằng A-µ thì hầu hết các octets sẽ được lưu trữ ở giá trị nguyên thủy của nó. Chỉ có những octet tương ứng với bộ giải mã µ-law ở đầu ra được đánh số 0,2,4,6,8,10,12,14 bị thay đổi (các con số được tăng lên 1). Hơn nữa trong các octets này, chỉ có bit 8 (thường ít giữ vị trí quan trọng trong PCM) thay đổi. Để phù hợp với những điều nói trên, bộ chuyển đổi kép µ-A-µ thường trong suốt đối với bit 1 đến bit 7. Table 1 Table 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 9 • Tương tự như vậy, nếu bộ chuyển đổi A-µ được thay bằng µ-A chỉ có các octet tương ứng với bộ giải mã A-law ở đầu ra có số 26,28,30,32,45,47,63 và 80 bị thay đổi và bit thứ 8 cũng thay đổi. Kết quả là hầu hết dãy tín hiệu tần số âm thanh tương tự được đưa vào lượng tử hóa thường không cho kết quả chính xác bởi vì bộ chuyển đổi kép µ-A-µ hay A-µ-A không cho kết quả tốt hơn bộ chuyển đổi đơn µ-A hay A-µ. 2.7. Sự chuyển đổi giữa µ-law và A-law: Xem Table 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 10 Table 3 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 11 Table 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 12 3. Chuẩn nén G.723: 3.1. Giới thiệu: Chuẩn G.723 giới thiệu một bộ nén có thể dùng để nén tín hiệu thoại hoặc những tín hiệu âm thanh khác của các dịch vụ đa phương tiện ở tốc độ bit rất thấp. Trong thiết kế của chuẩn này, nguyên lý ứng dụng làm việc ở tốc độ truyền bit rất nhỏ. Bộ mã hóa này được tích hợp hai tốc độ khác nhau: 5.3 và 6.3kbit/s. Cả hai tốc độ đều hỗ trợ bởi bộ mã hóa và giải mã. Chúng có thể chuyển đổi qua lại tại bất kì khung truyền (30 ms) nào. Với tốc độ 6.3 kbit/s chất lượng âm thanh tốt hơn. Bộ mã hóa này nén thoại với chất lượng cao ở cả hai tốc độ nhưng ít sử dụng kĩ thuật phức tạp. Các tín hiệu âm thanh khác sau khi được nén cho âm thanh có chất lượng không thực lắm. Về độ trễ, bộ mã hóa này mã hóa tín hiệu thoại và những tín hiệu âm thanh khác bằng những khung 30 ms, thêm độ trễ của phần chuyển đổi giữa các khung 7.5 ms, thời gian trễ tổng cộng là 37.5 ms. 3.2. Cơ chế mã hóa: Bộ mã hóa này được thiết kế để thực thi với một tín hiệu số. Tín hiệu này có được bằng cách thực hiện lọc tín hiệu tương tự đầu vào trong băng tần thoại, sau đó tiến hành lấy mẫu ở tần số 8000 Hz, tiếp theo nó chuyển đổi thành PCM tuyến tính 16 bit để đưa vào đầu vào của bộ mã hóa. Đầu ra của bộ mã hóa phải được chuyển đổi ngược lại sang tín hiệu tương tự bằng những cách tương tự. Những kiểu dữ liệu có đầu vào/đầu ra(input/output) khác, như dữ liệu PCM 64 kbit/s trong Khuyến nghị G711, phải được chuyển đổi sang PCM tuyến tính 16 bit trước khi mã hóa hoặc từ PCM tuyến tính 16 bit đến định dạng đúng sau khi giải mã. Luồng bit từ bộ mã hóa sang bộ giải mã được định nghĩa rõ trong chuẩn này. Bộ mã hóa dựa trên nguyên lý mã hóa phân tích bằng cách tổng hợp( analysis-by-synthesis) dự đoán tuyến tính và cố gắng tối thiểu tín hiệu trọng số lỗi một cách trực quan( conceptual). Bộ mã hóa hoạt động dựa trên những khối (frame 240 mẫu), tương đương với thời gian lấy mẫu là 30 ms ở tố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 13 lấy mẫu 8 kHz. Với mỗi block, trước tiến nó được đưa qua bộ lọc tần số cao để loại bỏ thành phần DC, sau đó chia vào 4 subframe, mỗi subframe có 60 mẫu. Ứng với mỗi subframe, bộ lọc mã hóa dự đoán tuyến tính (LPC filter– Linear Prediction Coder filter) cấp 10 được tính toán dùng những tín hiệu đầu vào chưa được xử lý. LPC filter cho subframe cuối cùng được lượng tử hóa dùng PSVQ (Predictive Split Vector Quantizer). Các hệ số LPC không được lượng tử hóa được sử dụng để xây dựng bộ lọc trọng số ngắn hạn(short-term perceptual weighting filter). Bộ lọc này dùng để lọc toàn bộ frame để nhận được tín hiệu trong số thoại. Ứng với 2 subframe (120 mẫu), vòng lặp mở định kỳ cường độ, LOL, được tính toán dùng tín hiệu trọng số thoại. Sự đánh giá về cường độ âm thanh được thực thi trên một khối 120 mẫu. Định kỳ về cường độ được dò tìm trong một khoảng từ 18 đến 142 mẫu. Từ điểm này âm thoại được xử lí với 60 mẫu trên một subframe. Bằng cách dùng sự ước lượng về cường độ âm thanh được tính toán ở phía trước ta xây dựng được bộ lọc định dạng nhiễu điều hòa( harmonic noise shaping filter). Sự kết hợp của bộ lọc tổng hợp LPC, bộ lọc trọng số và bộ lọc điều hòa tạp âm được dùng để tạo nên các xung hồi đáp sử dụng cho những sự tính toán về sau. Vòng lặp đóng của sự dự đoán cường độ âm thanh được tính toán dựa trên sự ước lượng định kỳ cường độ âm thanh và đáp ứng xung. Chu kì cường độ được tính toán như là một giá trị sai biệt nhỏ xung quanh sự ước đoán cường độ vòng lặp mở. Ứng với trường hợp tốc độ bit cao (6.3 kbit/s), kĩ thuật lượng tử Multi-pulse Maximum Likelihood Quantization( MP-MLQ) được dùng, còn đối với trường hợp tốc độ bit thấp (5.3 kbit/s), sự kích thích các mã đại số được dùng (ACELP). Biểu đồ khối của bộ mã hóa được thể hiện trong hình dưới đây. 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 14 3.3. Cơ chế giải mã: Bộ giải mã được thực thi dựa trên cơ sở frame-by-frame. Trước tiên các chỉ mục LPC đã lượng tử hóa được giải mã, tiếp theo bộ giải mã tạo ra bộ lọc tổng hợp LPC. Ứng với mỗi subframe, cả bộ dự đoán adaptive codebook và fixed codebook được giải mã và được đưa vào bộ lọc tổng hợp. Tín hiệu kích hoạt được đưa vào bộ lọc chuyển (postfilter) cường độ âm thanh, bộ lọc này được kích hoạt để đưa vào bộ lọc tổng hợp. Biểu đồ khối của bộ mã hóa tín hiệu thoại 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 15 4. Chuẩn nén G.729: 4.1. Giới thiệu: Chuẩn này sử dụng thuật toán Conjugate-Structure Algebraic-Code- Excited Linear-Prediction (CS-ACELP) để mã hóa tín hiệu âm thanh với tốc độ 8kbit/s. Bộ mã hóa này được thiết kế để thực thi với tín hiệu số nhận được từ bộ lọc băng thông thoại đầu tiên (được giới thiệu ở chuẩn G.712) của tín hiệu tương tự ở đầu vào, sau đó tiến hành lấy mẫu ở tần số 8000 Hz và chuyển đổi các mẫu âm thanh này thành PCM tuyến tính 16 bits để chuyển đến bộ mã hóa ở đầu vào. Đầu ra của bộ giải mã phải chuyển đổi ngược sang tín hiệu tương tự bằng cách giống như ở đầu vào. 4.2. Mô tả chung về bộ mã CS-ACELP: Bộ mã CS-ACELP được dựa trên nền tảng của mô hình mã hóa CELP (Code-Excited Linear-Prediction). Bộ mã này thực thi trên những khung âm thanh 10 ms tương đương với tốc độ lấy mẫu 8000 sample/s. Cứ mỗi khung 10 ms, tín hiệu âm thanh được phân tích để trích ra những tham số của mô hình CELP, những tham số này được mã hóa và truyền đi Tại bộ phận giải mã, các tham số này được dùng vào việc khởi tạo và tổng hợp các tham số trong bộ lọc. Âm thanh được khôi phục bằng cách lọc Biểu đồ khối của bộ giải mã tín hiệu thoại 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 16 khởi tạo này thông qua các bộ lọc tổng hợp và bộ lọc dự đoán. Sau khi tính toán xong luồng, âm thanh vừa được tổng hợp lại được nâng cao hơn nữa bằng một bộ postfilter. 4.2.1. Nguyên lý mã hóa: Nguyên lý mã hóa được biểu diễn trong hình dưới đây. Tín hiệu đầu vào được chuyển lên bộ lọc chất lượng cao và được chia tỷ lệ trong những khối trước khi xử lý . Tín hiệu tiền xử lý cung cấp như là tín hiệu đầu vào để dùng cho tất cả những việc phân tích tiếp theo. Việc phân tích dự đoán tuyến tính (Linear Prediction - LP) được làm một lần trên một khung 10 ms để tiến hành tính toán hệ số lọc LP. Các hệ số này được chuyển sang dạng quang phổ vạch dạng đôi (Line Spectrum Pairs - LSP) và dạng lượng tử hóa sử dùng dự đoán hai giai đoạn vector lượng tử (Vector Quantization – VQ) 18 bits. Sự kích hoạt tín hiệu được chọn bằng cách dùng một thủ tục tìm kiếm phân tích tổng hợp, trong đó những lỗi giữa âm thanh nguồn và âm thanh sau khi được tổng hợp lại giảm đến mức tối thiểu theo một quan niệm về việc đo lường trọng lượng không chính xác. Việc này được thực hiện bằng cách lọc những tín hiệu lỗi theo quan niệm về trọng lượng mà các hệ số của nó nhận được từ bộ lọc LP chưa được lượng tử hóa. Hầu hết các quan niệm về trọng lượng được tương thích hóa để cải thiện hiệu năng của tín hiệu đầu vào với một tần số đáp ứng không thay đổi. Sự kích hoạt các tham số (các tham số cố định và Biểu đồ khối của mô hình quan niệm tổng hợp CELP 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 17 tương thích các ký hiệu điện tử) được xác định trên mỗi khung phụ (subframe) 5 ms (40 mẫu). Các hệ số trong bộ lọc LP đã được lượng tử hóa và chưa được lượng tử hóa được sử dụng trong một khung phụ thứ hai, trong khi khung phụ thứ nhất được tự động thêm vào các hệ số trong bộ lọc LP để sử dụng ( cả hệ số lượng tử và hệ số chưa được lượng tử hóa). Một vòng lặp mở với độ delay của chất lượng tiếng nói được đánh giá một lần trên một khung 10 ms dựa trên quan niệm về trọng lượng của tín hiệu tiếng nói. Sau đó các thao tác này được lặp lại cho mỗi khung phụ. Tín hiệu cần đạt đến x(n) được tính toán bằng cách lọc LP còn dư lại qua một bộ lọc phân tích trọng lượng W(z)/Â(z). Trạng thái khởi tạo của các bộ lọc này được cập nhật bằng cách lọc các lỗi giữa LP còn dư và LP kích thích, nó tương đương với việc trừ đi những tín hiệu zero ở đầu vào của bộ lọc tổng hợp trọng lượng từ trọng lượng của tín hiệu tiếng nói. Những xung đáp ứng h(n) của bộ lọc tổng hợp trọng lượng được tính toán. Sau đó vòng lặp đóng của chất lượng âm thanh được thi hành (để tìm độ delay của bộ mã tương thích các ký hiệu điện tử và tăng tốc cho nó), dùng x(n) và h(n), và bằng cách tìm kiếm xung quanh những giá trị của vòng lặp mở độ delay của chất lượng âm thanh. Độ trể của chất lượng âm thanh được mã hóa 8 bits rong khung phụ thứ nhất và mã hóa 5 bit cho khung phụ thứ hai. Tín hiệu đạt được x(n) được cập nhật bằng cách trừ đi (lọc) các codebook tương thích tham gia vào, và một tín hiệu đạt được khác x’(n) được dùng trong việc tìm kiếm các fixed_codebook để tìm ra một sự kích thích tương thích nhất. Codebook đại số 17 bits được dùng cho sự kích thích fixed_codebook. Sự gia tăng của độ tương thích và những mã cố định đóng góp vào là một vector lượng tử hóa 7 bits. Cuối cùng bộ nhớ của bộ lọc được cập nhật lại dùng tín hiệu kích thích đã được xác định trướ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 18 4.2.2. Nguyên lý giải mã: Cơ chế mã hóa của bộ mã hóa CS-ACELP Cơ chế giải mã của bộ mã hóa CS-ACELP 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 19 Trước tiên, tham số chỉ mục được trích ra từ luồng bits nhận được. Những tham số chỉ mục này được giải mã để nhận được tham số mã hóa tương ứng với các khung thoại 10 ms. Các tham số này đều là các hệ số LSP (Line Spectrum Pairs), hai phân số độ trễ chất lượng âm thanh, 2 vector fixed-codebook, và 2 tập hợp tính tương thích và fixed-codebook được tăng lên. Các hệ số LSP được tự động thêm vào và chuyển đổi sang hệ số bộ lọc LP (Linear Prediction) cho mỗi khung phụ. Sau đó các bước sau được thực hiện cho mỗi subframe 5 ms: Sự kích thích được xây dựng bằng cách thêm độ tương thích và chia tỷ lệ các vector fixed-codebook bằng cách tăng những phần riêng của nó. Âm thanh được khôi phục lại bằng cách lọc sự kích thích thông qua một bộ lọc tổng hợp LP. Tín hiệu thoại sau khi đã được tái tạo, nó được chuyển qua công đoạn post-processing, nó bao gồm bộ tương thích postfilter dựa trên bộ lọc tổng hợp ngắn hạn và dài hạn, chuyển sang bộ lọc high-pass và tiến hành chia tỷ lệ. 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 20 CHƯƠNG 2: TÌM HIỂU CÁC CHUẨN NÉN HÌNH ẢNH 1. Giới thiệu: Cũng giống như các tín hiệu âm thanh, tín hiệu hình cũng gặp rất nhiều khó khăn trong việc truyền dẫn tín hiệu do sự hạn chế về băng thông. Về điều này, Hiệp hội viễn thông quốc tế ITU-T cũng đưa ra một vài chuẩn nén dùng cho video như H.261, H.263 v.v… để có thể truyền các tín hiệu hình ảnh trên băng thông thấp nhưng vẫn đạt được chất lượng dịch vụ tốt. Các chuẩn kỹ thuật này đang được sử dụng rộng rãi trong các hội nghị truyền hình. Ngoài ra, chúng ta có thể sử dụng các kỹ thuật nén hình khác như MPEG I & II phục vụ cho nhu cầu mã hoá chung các hình ảnh động. Tuy nhiên, luận văn này đi sâu vào nghiên cứu hai chuẩn nén do ITU-T đưa ra là H.261 và H.263. 2. Chuẩn nén H.261: 2.1. Giới thiệu: Chuẩn H.261được ITU-T đưa ra vào năm 1990. Chuẩn này đưa ra những phương pháp mã hoá và giải mã hình ảnh, dùng trong việc truyền hình ảnh video của các dịch vụ nghe nhìn với tốc độ px64Kbps ( p = 1- 30 ). Chuẩn này thực sự hiệu quả khi sử dụng cho các ứng dụng sử dụng trong mạng chuyển mạch điện tử (SCN). H.261 thường được dùng với các chuẩn khác như: H221, H230, H242 và H320 hoặc những chuẩn mới. 2.2. Đinh dạng ảnh nguồn của chuẩn H.261 Bộ mã nguồn chỉ có tác dụng với loại ảnh không đan xen (non- interlaced). Ảnh được mã hoá theo độ sáng và hai thành phần màu khác nhau (Y, Cb,Cr). Ma trận Cb, Cr có kích thước bằng một nửa ma trận Y. H261 hỗ trợ hai độ phân giải ảnh khác nhau: QCIF(144*176 pixel) và CIF(288*352 pixel). 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 21 Trong bộ mã hoá H.261, có ba thành phần chính là prediction, block tranformation, quantization & entropy coding. Chúng ta sẽ đi sau vào các phần trên đây. a. Prediction: H261 định nghĩa hai loại mã khác nhau: • INTRA coding: mỗi block 8*8 pixel được mã hoá một cách độc lập và được gởi đi trực tiếp đến tiến trình chuyển đổi block (block transformation process). • INTER coding: mỗi frame được mã hoá có sự liên quan đến các frame khác. Độ sai lệch được tính toán giữa một vùng 16*16 pixel (gọi là macroblock) với một macroblock của frame trước. b. Block transformation: H261 hỗ trợ việc bù đắp những mất mát của quá trình chuyển động trong bộ mã hoá như một tùy chọn. Trong việc bồi thường chuyển động, một vùng tìm kiếm được xây dựng dựa trên frame trước để xác định macroblock tham chiếu tốt nhất (reference macroblock). Cả độ sai lệch ước tính cũng như vector chuyển động, xác định giá trị và hướng di chuyển giữa macroblock được mã hóa và vùng tham chiếu đã chọn đều được gửi đi. Cùng tìm kiếm cũng như làm thế nào để tính toán vector chuyển động không tùy thuộc và sự chuẩn hóa. Thành Y YY Y Cb Cr H.1 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 22 phần nằm ngang và thẳng đứng của vector phải có giá trị nguyên nằm trong khoảng -15 đến 15. Trong sự biến đổi khối, những frame mã hóa theo kiểu INTRA cũng như những sai số dự đoán đều được đưa vào trong khối 8*8. Mỗi khối sẽ được xử lý bởi một hàm FDCT hai chiều. c. Quantization & Entropy Coding: Mục đích của bước này là đạt được sự nén tốt hơn bằng các hệ số DCT (Discrete Cosine Transform) để đạt được chất lượng đòi hỏi. Số lượng tử hóa là 1 đối với các hệ số INTRA và là 31 cho tất cả các hệ số khác. Mã hóa entropy kéo theo sự nén tốt hơn được thực hiện bằng cách gán những từ mã ngắn hơn cho những sự kiện phổ biến và sử dụng những sự kiện ít phổ biến hơn. Mã hóa Huffman thường được sử dụng trong trường hợp này. Nói cách khác, chúng ta có thể mất một vài hệ số trong việc chuyển đổi bằng cách sử dụng ít bit hơn so với số bit cần thiết cho tất cả các giá trị. Chúng ta sẽ dùng những từ mã ngắn hơn đối với những giá trị thông thường (giống như việc sử dụng 8 bit cho việc mã hóa 3 kí tự trong tiếng Anh). 2.3. Ghép kênh H.261 (H.261 Multiplexing): Dữ liệu trong bộ ghép kênh H.261 được nén thành các luồng bit phân lớp. Hệ thống gồm có 4 lớp sau: 2.3.1. Picture layer: Mỗi một picture layer tương ứng với một khung hình và có cấu trúc như sau: PSC TR PTYPE PEI PSPARE PEI GOB Data H.2 Structure of picture layer 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 23 • PSC : Picture Start Code (20 bit), có giá trị 0000 0000 0001 0000 0000. • TR : Temperal Reference (5 bit): Có 32 giá trị khác nhau, nó được thành lập bằng cách tăng giá trị đó ở header của ảnh đã chuyển trước lên 1 cộng với số lượng ảnh chưa được chuyển kể từ ảnh notice chuyển cuối cùng. • PTYPE : Type Information (6 bit): Thông số này lưu thông tin về toàn bộ ảnh. Bit 1: Split screen indicator, “0”: off , “1”: on Bit 2: Document camera indicator, “0”: off, “1”: on Bit 3: Freeze Picture Release, “0”: off , “1”: on Bit 4: Source Format, “0”: QCIF , “1”: CIF. Bit 5,6 Space. • PEI : Extra Insertion Information (1 bit) Được bật lên 1 nếu có trường data tùy chọn theo sau. • PSPARE : Spare Information (0, 8, 16 …bits) Nếu trường PEI được bật lên 1 thì 9 bits bao gồm 8 bits data và 1 bit PEI dùng để chỉ tiếp 9 bits theo sau và cứ tiếp tục như thế cho đến khi bit PEI = 0. 2.3.2. Group of blocks (GOB): Ứng với 1/12 CIF (Common Image Format) picture hoặc 1/3 QCIF (Quarter Common Image Format) H.3 Trật tự của một GOB trong một ảnh CIF 1 2 3 4 5 6 7 8 9 10 11 12 QCIF 1 2 3 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 24 Dữ liệu cho một group of block bao gồm một GOB header theo sau là macroblock data. Cẩu trúc của nó như sau: • GBSC : Group of Blocks Start Code (16 bits) Một word 16 bits, có giá trị là 0000 0000 0000 0001. • GN : Group of Number (4 bits) 4 bits này dùng để chỉ vị trí của group of blocks • GQUANT : Quantizer Information (5 bits) Dùng để chỉ ra lượng tử hóa (quantizer) được dùng trong group of block cho đến khi bị loại bỏ bởi bất kỳ một MQUANT nào theo sau. Đây là giá trị của lượng tử có trị số từ 1-31. • GEI : Extra Insertion Information (1 bit) Được bật lên 1 khi có trường data. • GSPARE : Spare Information (0,8,16,…bits) Khi thông số GEI bật lên thì 9 bits theo sau sẽ bao gồm 8 bits data và 1 bit GEI khác dùng để 9 bits tiếp theo và cứ tiếp tục như thế cho đến khi gặp bit GEI = 0. 2.3.3. Macroblocks: Mỗi GOB (Group of Block) được chia thành 33 macroblock ứng với 16*16 pixel của cường độ sáng và 2 thành phần màu (8*8). GBSC GN GQUANT GEI GSPARE GEI MB Data H.4 Structure of GOB Layer 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 H.5 Trật tự của các macroblock trong một GOB MBA MTYPE MQUANT MVD CBP Block Data H.6 Cấu trúc một lớp macroblock 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 25 • MBA : Macroblock Address Có độ dài thay đổi dùng để chỉ vị trí của macroblock trong một group of block. Trật tự được truyền đi theo đúng thứ tự như hình 5 ở trên. Đối với macroblock đẩu tiên trong GOB thì MBA chính là địa chỉ tuyệt đối theo như hình 5. Còn đối với các macroblock cuối cùng notice chuyển đi. Những macroblock nào không chứa thông tin của phần ảnh đó sẽ không được chuyển đi. • MTYPE : Type Information Là từ mã có độ dài thay đổi cung cấp thông tin về macroblock và những yếu tố data có mặt. • MQUANT : Quantizer (5 bit) Giá trị của MQUANT cũng giống GQUANT. • MVD : Motion Vector Data Giá trị MVD tính được từ macroblock vector bằng cách trừ đi vector của macroblock đi trước được xem là bằng 0 trong 3 trường hợp sau: 9 Macroblock 1,12,23 9 Các macroblock mà MBA có độ sai lệch khác 1 9 MTYPE của macroblock trước không phải là MC MVD bao gồm một word mã hóa thành phần ngang và theo sau là môt word mã hóa thành phần dọc. • CPB : Coded block pattern Trường này chỉ có khi nó được chỉ định bởi trường MTYPE. Từ mã (codeword) cung cấp 1 con số chỉ định những block ở trong macroblock nào có ít nhất một hệ số biến đổi được truyền đi. 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 26 2.3.4. Block: Ứng với 8*8 pixel. Dữ liệu cho mỗi block bao gồm các codewords cho các hệ số biến đổi theo sau là kí hiệu kết thúc block. Trật tự của các block trong một macroblock như sau: Cấu trúc của block layer như sau: • TCOEFF : (Transform Coefficients) Hệ số biến đổi luôn luôn biểu thị cho tất cả 6 blocks trong một macroblock khi trường MTYPE chỉ định là INTRA. Các hệ số biến đổi đã được lượng tử hóa được truyền đi một cách tuần tự theo một dãy như sau: 3. Chuẩn nén H.263: 3.1. Giới thiệu: H263 ra đời khoảng 5 năm sau chuẩn H261, là phần mới thêm vào trong loạt chuẩn H của ITU và mục đích là để mở rộng khả năng mã hóa video cho việc truyền thông tốc độ thấp (Low Bit Rate Communication). H.263 được thiết kế cho mạng có tốc độ nhỏ hơn 64 Kbps, rất thích hợp cho các mạng truyền thông có băng thông thấp. Chuẩn này chỉ mở rộng thêm một vài phần so với chuẩn H.261 nên trong mục này, ta chỉ nêu lên sự khác biệt giữa hai chuẩn này. 1 2 6 7 15 16 28 29 3 5 8 14 17 27 30 43 4 9 13 18 26 31 42 44 10 12 19 25 32 41 45 54 11 20 24 33 40 46 53 55 21 23 34 39 47 52 56 61 22 35 38 48 51 57 60 62 36 37 49 50 58 59 63 64 1 3 2 4 5 6 Y CB CA TCOEFF EOB Increasing cycle per picture width Increasing cycle per picture height 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 27 3.2. Những khác biệt giữa H.263 và H.261: 3.2.1. SubQCIF: H263 ngoài việc hỗ trợ các độ phân giải QCIF (176*144), CIF(352*288), 4CIF(704*576), 16CIF (1048*1152), nó còn hỗ trợ dạng mới gọi là SubQCIF(352*288). 3.2.2. Cách tính độ sai lệch tốt hơn: H263 xem xét trước tất cả khả năng có thể để lựa chon vùng tham chiếu tốt nhất. Tùy chọn APM (Advanced Prediction Mode) cho phép tính vector chuyển động sử dụng 4 block 8*8 thay vì 1 block 16*16. Nếu tùy chọn này được xác định thì thuật toán tính độ sai lệch sẽ tính 4 vector chuyển động V1,V2,V3,V4. 3.2.3. Độ chính xác trong việc dự đoán: H263 đưa ra một cách tính phần phải chuyển đi (carrier of motion) với độ chính xác cao hơn. Một khi nó quyết định mã hóa INTER và đã tính được vector chuyển động của macroblock, H263 đưa ra một thuật toán để tính một phần chuyển đi mới (carrierer motion) dựa vào search pixel (Half Pixel Search). 3.2.4. Cách xử lý truyền macroblock: Một macroblock sẽ không được chuyển đi nếu nó giống với macroblock trước. H261 truyền MBA (macroblock address) với độ dài từ mã khác nhau trong khi H263 thì chỉ truyền có 1 bit. 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 28 CHƯƠNG 3: TÌM HIỂU VỀ VOICE OVER IP 1. Giới thiệu về VoIP: VoIP là từ viết tắt của Voice Over Internet Protocol. Đúng như tên gọi của chúng, nghi thức truyền âm thanh này sử dụng phương pháp truyền tín hiệu âm thanh thông qua truyền các gói tin thông qua mạng IP. Bằng cách này, VoIP có thể sử dụng tốc độ của phần cứng để hoàn thành mục đích và có thể hữu dụng trên môi trường PC. VoIP có khả năng kết hợp thoại và dữ liệu trong quá trình xử lý truyền, phân phối thông, cuộc gọi điện thoại, hội nghị truyền hình, các trò chơi tương tác trực tuyến cũng như phân phối các ứng dụng truyền thanh, truyền hình và phát quảng bá. Đây là công nghệ viễn thông hấp dẫn và được chú ý nhiều nhất hiện nay. Việc sử dụng VoIP làm cho quá trình phân phối thông tin và dịch vụ toàn cầu hiệu quả hơn và kinh tế hơn so với sử dụng mạng chuyển mạch thoại công cộng truyền thống (PSTN), trong khi đó vẫn cho phép sử dụng các ứng dụng và dữ liệu trước đây. VoIP có thể thực hiện tất cả các chức năng tương tự với mạng truyền thống với chất lượng dịch vụ tốt. 2. Ưu điểm của VoIP so với PSTN: 2.1. Tiết kiệm băng thông: Mạng VoIP hiệu quả hơn mạng PSTN trên cơ sở các kênh chuyên dùng được thiết lập giữa các điểm cuối. Ðối với cuộc gọi thông thường có đến 40% thời gian bị lãng phí bởi những khoảng lặng (không nói chuyện). Trong mạng VoIP, các gói chỉ được gởi qua mạng khi có tín hiệu cần truyền đi. Ðiều này cho phép mạng có thể điều khiển được một lưu lượng nhiều hơn qua độ rộng băng thông sẵn 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 29 2.2. Đơn giản hóa: VoIP là môt mô hình tổng hợp, chấp nhận mọi dạng thông tin cho phép thực hiện việc chuẩn hoá và giảm bớt một phần trang thiết bị dùng riêng cho từng loại hình. Tích hợp các ứng dụng về thoại và dữ liệu. 2.3. Khả năng tích hợp: Khả năng này được minh họa một cách rõ nhất bằng việc hỗ trợ phối hợp giữa mạng không dây và mạng có dây, khả năng hợp nhất các ứng dụng riêng lẽ trong truyền thống qua các giao thức gắn kết. Sự tích hợp qua mạng IP đưa ra các giải pháp truy cập hợp nhất các dịch vụ trong mạng diện rộng WAN bao gồm thoại, dữ liệu, Internet, hình ảnh qua một hệ thống các đường truy cập tốc độ cao dùng chung. 2.4. Uyển chuyển trong quản lý: Được thể hiện qua khả năng mở rộng của địa chỉ IP, có thể mở rộng hay thu hẹp phạm vi của mạng một cách dễ dàng mà không gây nên sự biến đổi lớn nào về phần cứng và phần mềm.. Việc thêm hay bớt người sử dụng điện thoại, sắp xếp lại các số trên mạng IP đều dễ dàng hơn so với hệ thống chuyển mạch thoại truyền thống. Việc định dạng và chuyển nhượng địa chỉ IP có thể được thực hiện bằng cách sử dụng giao thức DHCP, áp dụng cho điện thoại IP qua LAN khiến việc lập và quản lý địa chỉ gần như tự động. Đối với việc kết nối với tổng dài nội bộ (PBX) qua mạng IP được đưa ra bởi PSINet’s Voice iPEnterprise, phân phối lưu lượng thoại nội bộ qua kết nối tượng tự như dữ liệu của Internet, cho phép các nhà kinh doanh truyền các dịch vụ thoại tới văn phòng của họ. 2.5. Quản lý tốt: Giao thức quản lý SNMP có thể áp dụng vào cho dữ liệu và thoại dùng trong VoIP để có thể loại bỏ sai sót và củng cố hệ thố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 30 Được phát triển trên mạng IP, VoIP sử dụng các giải pháp bảo mật cho Internet gồm mã hoá, tạo đường hầm, xác nhận sự xâm nhập tự động, quét virus được thực hiện bởi các máy chủ, firewall, các bộ định tuyến đã giải quyết được các vấn đề về gian lận cước phí, toàn vẹn dữ liệu. 2.6. Giá thành thấp: Việc giảm chi phí tài nguyên mạng, chia sẽ trang thiết bị và chi phí vận hành cho cả tín hiệu thoại và dữ liệu có thể nâng cao hiệu quả sự dụng mạng vì phần băng thông dư trên mạng này có thể tận dụng trên mạng khác, dẫn đến tỷ lệ cước phí khi sử dụng thoại và Fax kết hợp trong truy cập Internet có thể tiết kiệm đáng kể chi phí cho người dùng so với dùng mạng PSTN. 3. Các hình thức truyền thoại trên mạng IP: 3.1. PC-PC : Mỗi PC trang bị thêm các thiết bị truyền thông và được kết nối trực tiếp vào mạng Internet thông qua giao diện NIC với mạng LAN hoặc thông qua Modem / cable modem khi kết nối qua ISP (Internet Sevice Provider). 3.2. PC – Phone : Người dùng PC hình thành cuộc gọi với người dùng mạng thoại PSTN thông thường. Cấu trúc này là đường dẫn tới việc kết hợp giữa mạng IP và PSTN. 3.3. Phone - Internet - Phone : Là mô hình mở rộng của PC – Phone, sử dụng Internet làm cơ sở để tính cước phí điện thoại cho người sử dụng mạng PSTN. Mô hình này sử dụng một mã số đặc biệt là giá trị cổng kết nối giữa PSTN và mạng Internet rồi mới nhấn số điện thoại cần gặp. Mọi quá trình lấy mẫu và mã hoá đều diễn ra ở gateway. 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 31 4. Nguyên tắc và mô hình hoạt động của VoIP: 4.1. Quá trình thiết lập một kết nối VoIP : - Bộ phận ADC chuyển đổi âm thanh dạng tín hiệu tương tự sang tín hiệu số, được biểu diễn bằng các chuỗi bit. - Các chuỗi bit này được nén với một định dạng để truyền bằng các nghi thức nén dữ liệu phù hợp tuỳ chọn. - Đóng gói âm thanh vào gói dữ liệu và truyền đi bằng nghi thức RTP(real-time transport protocol), thông thường sử dụng RTP over UDP. - Dùng nghi thức báo hiệu ITU-T H323 để gọi các user. - Bên RX sẽ mở gói tin, giải nén dữ liệu, chuyển dữ liệu từ tín hiệu số sang tín hiệu âm thanh dạng tương tự và gửi tới card âm thanh (hay phone). 4.2. Mô hình hoạt động của VoIP: 5. Các nghi thức được sử dụng trong hệ thống VoIP: 5.1. Giao thức UDP (User Datagram Protocol): UDP thực hiện truyền dữ liệu với số header hạn chế tối đa vì giao thức này không đòi hỏi kiểm tra qua lại giữa bên nhận và bên phát. Các gói tìm đường độc lập để đến nơi nhận, do đó không đảm bảo dữ liệu được nhận đầy 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 32 đủ và đúng thứ tự. Tuy nhiên, thời gian truyền dữ liệu ngắn với độ hiệu quả sử dụng các gói cao nên UDP được sử dụng là giao thức chính trong VoIP. 5.2. Giao thức RTP (Realtime Protocol): Giao thức này cung cấp các dịch vụ về dữ liệu mang tính thời gian thực như video và audio tương tác. Các ứng dụng này chạy dựa trên nền UDP để tận dụng được khả năng multiplexing và checksum. Cả hai giao thức này góp phần tạo nên các tính năng của nghi thức truyền dữ liệu. RTP có thể được dùng hiệu quả hơn trong các hệ thống mạng hay nghi thức thích hợp. RTP cũng hỗ trợ truyền dữ liệu đến nhiều địa chỉ khác nhau bằng cách dùng cơ chế multicast nếu được sự hỗ trợ của hệ thống mạng. Chúng ta sẽ tìm hiểu rõ hơn về nghi thức này trong phần tìm hiểu về các nghi thức mạng truyền dữ liệu theo thời gian thực. 5.3. Giao thức RTCP ( RTP Control Protocol ): Giao thức điều khiển RTP 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: 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, giữ vết các thành phần tham gia, kiểm soát tốc độ để có thể phục vụ cho một số lượng lớn các thành phần tham gia, kiểm soát phiên làm việc. 5.4. Giao thức RSVP: Hỗ trợ cho giao thức RTP, giao thức RSVP có thể giải quyết tạm thời các lỗi có thể xảy ra trên đường truyền để đảm bảo các tham số chất lượng. Giao thức RTP chỉ kiểm tra sự truyền thông điểm - điểm, không quản lý các tham số liên kết trên mạng trong khi RSVP không những tác động ở máy phát và máy thu mà còn tác động trên các router trên mạng. RSVP thiết lập và duy trì kết nối duy nhất cho một luồng dữ liệu, xác lập một hệ thống quản lý các nguồn tài nguyên của các nút mạng khác nhau. 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 33 RSVP hoạch định một mô hình tối ưu để liên kết các dữ liệu đa điểm ( từ một nguồn đến nhiều điểm đích). RSVP đóng vai trò quản lý một cách độc lập các máy đích để tự thích nghi các tham số chất lượng giữa khả năng cung cấp và yêu cầu đáp ứng. Ðể đảm bảo đường truyền thông suốt, các hệ thống đầu cuối phải hoạt động ở chế độ kết nối. Máy thu phải thường xuyên gởi các thông điệp RSVP đến các router để đảm bảo thông suốt đường truyền. 5.5. SGCP: Giao thức này cho phép các thành phần điều khiển cuộc gọi có thể điều khiển kết nối giữa các trung kế, các Endpoint và cácVoIP gateway. Các thành phần điều khiển gọi là Call Agent. SGCP được dùng để thiết lập duy trì và giải phóng cuộc gọi qua mạng IP. Call Agent thực hiện chức năng báo hiệu cuộc gọi và Gateway cung cấp chức năng truyền tín hiệu âm thanh. SGCP yêu cầu các Gateway thực hiện chức năng thiết lập, điều chỉnh, giải phóng kết nối và báo hiệu về Call Agent các sự kiện xảy ra tại gateway. SGVP có 5 lệnh chính như sau: - NotificationRequest: yêu cầu Gateway phát hiện các tín hiệu nhấc máy và tín hiệu quay số DTMF. - Notify: Gateway sử dụng lệnh này để báo ngược về Call Agent các tín hiệu trên. - CreateConnection: Call Agent yêu cầu tạo kết nối giữa cá đầu cuối tham gia liên lạc trong gateway. - ModifyConnection: Call Agent dùng lệnh này để thay đổi các thông số về kết nối đã thiết lập. Lệnh này để thay đổi các thông số về kết nối đã thiết lập. Lệnh này cũng có thể dùng các gói RTP thay đổi lộ trình từ Gateway này sang Gateway khác. - Deleteconnection: Call Agent và Gateway dùng lệnh này để giải phóng kết nối. 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 34 5.6. MGCP: MGCP xác định cách thức truyền thông giữa các đại lý(call agent) và các cổng điện thoại (telephony gateway). Call agent điều khiển cuộc gọi, quản lý các telephony gateway được dùng để chuyển đổi giao thức. MGCP có bốn lệnh chính như sau: - EndPointConfiguration: Call Agent dùng lệnh này để yêu cầu Gateway xác định kiểu mã hoá ở phía đường dây kết nối tới EndPoint. - AudiEndpoint và AudiConnection: Call Agent kiểm tra trạng thái và kết nối ở một Endpoint. - RestarIn_Progress: Gateway báo hiệu cho Call Agent khi nào các Endpoint ra khỏi dịch vụ hoặc quay lại sử dụng dịch vụ. 6. Các vấn đề liên quan đến chất lượng dịch vụ : Chất lượng của các dịch vụ truyền thông đa phương tiện được xem là vấn đề quan quyết định sự phát triển của dịch vụ đó. Mọi dịch vụ truyền thông đa phương tiện phát triển trên mạng VoIP đều phải khắc phục chất lượng về âm thanh sau khi nén và điều này là một trong những lý do quan trọng nhất khiến VoIP không cạnh tranh được với mạng điện thoại truyền thống PSTN. Có 3 yếu tố chính gây ảnh hưởng trực tiếp đến chất lượng tín hiệu thoại trong VoIP là : mất gói, trễ gói và jitter. 6.1. Mất gói và các giải pháp khắc phục tình trạng này: 6.1.1. Tổng quan: • Là hiện tượng chung trong môi trường chuyển mạch gói. • Các gói được truyền giữa các đầu cuối thông qua các router trung gian. Khi các router này quá tải, nghẽn mạch sẽ dẫn đến mất gói. 6.1.2. Các giải pháp khắc phục: • Nâng cấp mạng • Lấp gói mất bằng khoảng lặ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 35 • Thay thế các gói mất bằng cách chèn nhiễu trắng. • Phát lại gói cuối nhận được với âm lượng nhỏ hơn. • Thêm gói dựa vào đặc tính sóng âm của các gói lân cận. • Chèn khung thoại vào các gói khác nhau. 6.2. Trễ gói 6.2.1. Tổng quan • Giới hạn của delay là 150ms, với đường truyền xa thì delay chấp nhận được là từ 150->400ms. • Trễ gói làm tiếng nói không thực, chồng lấp tiếng nói, tạo tiếng vọng,… • Nguyên nhân: do độ trễ của quá trình mã hoá, giải mã tiếng nói gây ra, thời gian truyền, hay do xếp hàng trong các buffer tại các nút chuyển mạch và nút truyền số liệu, … 6.2.2. Có hai giải pháp: • Nén Header: mỗi gói dữ liệu đều kèm theo các header để tìm đường chuyển các gói đến đúng nơi nhận. • Phân đoạn: các gói thoại sử dụng các giao thức thời gian thực như RTP, RTCP, RSVP sẽ được ưu tiên hơn trong truyền thông. 6.3. Network Jitter • jitter là khoảng thời gian đến nơi nhận khác nhau của các gói thoại, là yếu tố ảnh hưởng nghiêm trọng đến chất lượng thoại trong VoIP. • Để giải quyết vấn đề này, phía thu phải có một bộ đệm jitter để sắp xếp các gói nhận theo đúng thứ tự phát. Thời gian lưu trữ làm tăng thêm thời gian delay. • Các gateway cần có khả năng thay đổi kích thước bộ đệm jitter để thích nghi với thời gian trễ trong mạng. • Kích thước chung của buffer là 50-100ms. 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 36 • Ngoài ra nghẽn mạch trên mạng cũng ảnh hưởng rất lớn đến chất lượng thoại. 6.4. Kết luận: Cần giải quyết tốt các vấn đề nêu trên để chất lượng dịch vụ được cung cấp trên môi trường mạng VoIP được cải tiến, nâng khả năng cạnh tranh với mạng truyền thống PSTN. 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 37 CHƯƠNG 4: TÌM HIỂU CÁC NGHI THỨC TRUYỀN THÔNG THỜI GIAN THỰC RTP (Realtime Protocol) Trong môi trường truyền thông trên mạng hiện nay, việc truyền các tín hiệu được truyền đều được dựa trên các chuẩn kỹ thuật khác nhau. Các nghi thức truyền thông thời gian thực cũng là một trong số các chuẩn kỹ thuật được đưa ra cho hạ tầng mạng hiện nay nhằm truyền các gói tin trong thời gian thực, phục vụ cho các ứng dụng truyền thông đa phương tiện trực tuyến như hội nghị truyền hình (video conference), hội nghị thoại (voice conference) v.v…. Trong chương này, chúng ta sẽ cùng đi sâu tìm hiểu rõ về hai chuẩn kỹ thuật tryền thông thời gian thực hiện nay là RTP và RTCP 1. Giới thiệu giao thức RTP (Realtime Protocol): Realtime Protocol là một chuẩn Internet để truyền các luồng thông tin giữa các thành phần tương tác trên mạng. RTP cung cấp các dịch vụ về dữ liệu mang tính thời gian thực như video và audio. Thông thường các ứng dụng chạy RTP dựa trên UDP để tận dụng khả năng multiplexing và kiểm lỗi. RTP hỗ trợ việc truyền dữ liệu đến nhiều địa chỉ đích bằng cách dùng cơ chế multicast nếu được hỗ trợ bởi hệ thống mạng. RTP không có sẵn các cơ chế để đảm bảo việc truyền theo thời gian hay các kỹ thuật về QoS mà dựa vào các dịch vụ ở lớp dưới để thực hiện những khả năng này. RTP không đảm bảo an toàn hay thứ tự các packet khi truyền, số thứ tự trong RTP packet cho phép bên nhận sắp xếp lại các packet theo thứ tự khi truyền của bên gửi. Ngoài ra số thứ tự cũng có thể được tận dụng để xác định vị trí thích hợp của một packet, ví dụ trong việc giải mã video, mà không cần phải giải mã các packet theo thứ tự. 2. Các khái niệm và định nghĩa được sử dụng trong RTP: RTP payload: Dữ liệu được chuyển trong RTP packet, ví dụ như các mẫu âm thanh (audio samples ) hay các dữ liệu hình ảnh nén (compressed video 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 38 RTP packet: Một gói dữ liệu bao gồm RTP header, danh sách các nguồn cung cấp (contributing sources) có thể rỗng và dữ liệu payload. Một số nghi thức mạng nền có thể yêu cầu phải xác định cơ chế đóng gói cho RTP packet. Thông thường một gói của nghi thức mạng nền chứa một RTP packet, nhưng cũng có thể chứa nhiều tùy theo cơ chế đóng gói (encapsulation). RTCP packet: Một gói điều khiển bao gồm phần header tương tự như của RTP packet, phần còn lại là các thành phần có cấu trúc tùy thuộc loại của gói RTCP. Thông thường nhiều gói RTCP được gởi cùng lúc như một gói RTCP tổng hợp được chứa trong một gói của nghi thức mạng nền. Transport address: Sự kết hợp của địa chỉ mạng và cổng (port) để xác định một điểm cuối (endpoint) ở mức transport, ví dụ như một địa chỉ IP và cổng UDP. Các packets được truyền từ địa chỉ nguồn đến địa chỉ đích. RTP session: Là sự kết hợp của các thành phần tham gia trao đổi thông tin. Đối với mỗi thành phần tham gia, phiên (session) được xác định bởi một cặp địa chỉ truyền đích. Cặp địa chỉ đích này có thể là chung cho mọi thành phần tham gia hoặc riêng cho từng thành phần. Trong một phiên đa phương tiện, mỗi phương tiện được chuyển tải bởi một RTP session riêng cùng với các gói RTCP của nó. Các phiên RTP khác nhau được phân biệt bởi các cặp ports và địa chỉ multicast. Synchronization source (SSRC): Nguồn của luồng các gói RTP được xác định bởi một số định danh 32 bit trong header của gói RTP để độc lập với địa chỉ network. Mỗi gói từ nguồn đồng bộ (SSRC) có cùng một không gian về thời gian và số thứ tự, do đó bên nhận có thể nhóm các gói để phát lại (playback). Một nguồn đồng bộ có thể thay đổi định dạng dữ liệu của nó vào bất cứ lúc nào. Định danh nguồn đồng bộ là một giá trị ngẫu nhiên, giá trị này mang ý nghĩa duy nhất (không trùng lắp) trong một RTP session riêng biệt. Một thành viên tham gia hội thảo không cần phải dùng cùng một định danh SSRC trong một phiên đa phương tiệ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 39 Contributing source (CSRC): Là nguồn của luồng các gói RTP đã góp phần tạo nên luồng kết hợp thông qua một bộ trộn RTP (RTP mixer). Bộ trộn RTP chèn một danh sách các định danh nguồn đồng bộ (SSRC identifier) của các nguồn vào RTP header của một gói RTP. Danh sách này được gọi là danh sách CSRC. End system: Là một ứng dụng có khả năng tạo ra các nội dung để truyền trong các gói RTP, hay nhận và xử lý nội dung của gói RTP. Một endsystem có thể hoạt động như một hoặc nhiều nguồn đồng bộ trong một phiên RTP riêng, nhưng thường là một. Mixer: Là một hệ thống trung gian nhận các gói RTP từ một hay nhiều nguồn, có thể thay đổi định dạng dữ liệu rồi kết hợp các gói đó lại theo một cách thức nào đó tạo thành một gói RTP mới và truyền đi. Vì sự phối hợp thời gian giữa các nguồn có thể không hoàn toàn đồng bộ nên bộ trộn sẽ đồng bộ thời gian giữa các nguồn và sau đó, luồng ra sẽ có một sự định thời của mixer. Do đó các gói được tạo ra từ một mixer đều xác định mixer là nguồn đồng bộ. Translator: Là một hệ thống trung gian có nhiệm vụ chuyển tiếp các gói RTP mà không làm thay đổi các nguồn đồng bộ. Monitor: Là một ứng dụng tiếp nhận các gói RTCP được gửi từ các thành viên của một phiên RTP, báo cáo cụ thể sự tiếp nhận, ước lượng chất lượng của dịch vụ hiện thời và dự đoán lỗi. Chức năng monitor thường được xây dựng trong các ứng dụng tham gia trong phiên, hoặc cũng có thể được xây dựng như một ứng dụng tách biệt, có thể là thành viên hoặc không và không gởi, nhận các gói dữ liệu RTP. Chúng được gọi là những monitor tham gia thứ ba. Non-RTP means: Là các nghi thức hay cơ chế có thể được dùng để thêm vào RTP để làm tăng tính khả dụng của các dịch vụ. 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 40 3. Thứ tự byte, alignment và định dạng thời gian: Tất cả các trường số nguyên đều được truyền theo thứ tự byte chuẩn trên mạng, có nghĩa là byte dấu nằm trước. Các hằng số đều ở dạng thập phân trừ các trường hợp đặc biệt. Tất cả các dữ liệu trong header được sắp xếp theo độ dài tự nhiên của nó, ví dụ: các trường 16 bit được đặt ở các vị trí chẵn, các trường 32 bit được đặt ở các vị trí chia hết cho 4…Các octets nối thêm mang giá trị 0. Giờ tuyệt đối được biểu diễn theo nghi thức NTP (Network Time Protocol), tính theo giây kêt từ 0 giờ ngày 01/01/1900. Ta dùng một số không dấu 64 bit để biểu diễn, trong đó 32 bit đầu là phần nguyền và 32 bit sau là phần thập phân. Một số trường có thể chỉ dùng 32 bit giữa do nhu cầu nén dữ liệu, nghĩa là 16 bit thấp của phần nguyên và 16 bit cao của phần thập phân. 4. Nghi thức truyền dữ liệu RTP (RTP Data Transfer Protocol): 4.1. Các trường cố định trong RTP header: RTP Header bao gồm mười hai octet (mỗi octet gồm 8 bit) đầu tiên luôn có trong mỗi gói RTP, trừ CSRC có thể có hoặc không do được thêm vào bởi RTP mixer. Ý nghĩa của các trường như sau: version (V): 2 bit Trường này xác định version của RTP. padding (P): 1 bit Nếu bit pađing bật nghĩa là có một hay nhiều octet được thêm vào cuối dữ liệu. Octet cuối cùng của phần thêm vào cho biết có bao 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 X CC M PT Sequence number Timestamp Synchronization source (SSRC) identifier Contributing source (CSRC) identifiers ……………………… Định dạng RTP Header 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 41 nhiêu octet thêm vào cần được bỏ qua. Cần phải thêm vào các octet bởi vì có một số thuật toán mã hóa yêu cầu kích thước dữ liệu xác định để có thể thực hiện, hoặc dùng để mang theo mốt số gói RTP ở các tầng nghi thức thấp hơn. extension (X): 1 bit Nếu bit extension bật thì sau phần header cố định sẽ có thêm duy nhất một phần header mở rộng. CSRC count (CC): 4 bits Trường này cho biết số lượng các định danh CSRC có trong danh sách được lưu trữ sau phần header cố định. marker (M): 1 bit Phần diễn giải cho trường marker được định nghĩa bởi một profile. Nó bao gồm các thông tin về các sự kiện quan trọng như việc đánh dấu các biên của frame trong luồng packet. Profile có thể định nghĩa thêm các bit đánh dấu (marker) hoặc xác định rằng không có bit đánh dấu nào bằng cách thay đổi số lượng bit trong trường kiểu payload. payload type (PT): 7 bit Trường này cho biết định dạng của RTP layload và xác định cách thức diễn giải (interpretation) mà ứng dụng sủ dụng. Một profile đặc tả một ánh xạ tĩnh mặc nhiên của các mã kiểu payload cho các định dạng payload. Các mã kiểu payload khác muốn thêm vào có thể được định nghĩa động bằng các cơ chế khác RTP (non RTP means). Mỗi bên gửi RTP chỉ phát ra một kiểu payload nhất định trong suốt thời gian hoạt động. Trường này không dùng trong việc ghép kênh các luồng media riêng biệt. sequence number: 16 bit Số thứ tự được tăng lên một đơn vị cho mỗi gói RTP được gửi đi, bên nhận dựa vào số này để phát hiện các gói dữ liệu bị mất hay sắp 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 42 xếp lại các gói RTP theo thứ tự như khi truyền. Giá trị khởi đầu của số thứ tự là ngẫu nhiên, không thể dự đoán trước làm cho sự tấn công vào dữ liệu mã hóa trong quá trình mã hoá gặp khó khăn hơn bởi vì một gói tin có thể được chuyển qua translator để thực hiện mã hoá mặc dù bản thân bên nguồn không thực hiện mã hoá. Có rất nhiều kỹ thuật tạo ra một số ngẫu nhiên không thể dự đoán trước được. timestamp: 32 bit Timestamp xác định thời điểm lấy mẫu của octet đầu tiên trong dữ liệu của gói RTP. Thời điểm lấy mẫu được xác định nhờ vào một đồng hồ đếm giờ tuyến tính để cho phép sự đồng bộ và tính toán nhanh chóng và chính xác. Tốc độ nhịp đồng hồ phải đủ lớn để có thể đồng bộ một cách 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ữ liệu và hình ảnh có thể tùy chọn. H.323 xác định một hình thức tương tác cho các terminal khác nhau cùng hoạt động với nhau. Tất cả các terminal đều phải hỗ trợ giao thức H.245 được dùng để thống nhất khả năng và cách dùng kênh truyền. Ba thành phần khác mà mỗi terminal đều phải hỗ trợ là: • Giao thức Q.931 dùng cho báo hiệu và thiết lập cuộc gọi. H.323 Terminal Equipment 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 60 • Giao thức RAS (Registration / Admission / Status) để giao tiếp với Gatekeeper. • Giao thức RTP / RTCP để sắp xếp các gói âm thanh và hình ảnh. Những thành phần tùy chọn của một terminal H.323 là mã hóa hình ảnh, giao thức hội nghị dữ liệu T.120, khả năng điều khiển kết nối đa điểm. 2.2.2. Gateway: Gateway là thiết bị kết nối trung gian, thực hiện chức năng chuyển đổi các giao thức cho việc thiết lập và giải phóng cuộc gọi, chuyển đổi dạng truyền thông giữa hai mạng khác nhau (mạng theo chuẩn H.323 và mạng không theo chuẩn H.323) như trong mạng điện thoại IP, Gateway thực hiện kết nối giữa mạng IP và mạng PSTN Gateway là một thành phần tuỳ chọn trong hội nghị H.323, thường là các máy tính có nhiều giao diện với các mạng khác nhau. Gateway cung cấp nhiều dịch vụ, tổng quát nhất là chức năng biên dịch giữa các đầu cuối H.323 và các loại đầu cuối khác. Bằng những bộ chuyển mã thích hợp, Gateway H.323 có thể hỗ trợ những thiết bị đầu cuối tuân theo các chuẩn H.310, H.321, H.322 và V.70. Chức năng này bao gồm biên dịch giữa những khuôn dạng truyền (H.225.0 đến H.221) và giữa những thủ tục truyền thông (H.245 sang H.242). Ngoài ra, Gateway cũng biên dịch giữa các bộ mã hoá âm thanh H.323/PSTN Gateway 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 61 và hình ảnh, thực hiện thiết lập và kết thúc cuộc gọi trên cả đầu mạng LAN và đầu mạng chuyển mạch điện tử SCN. Những ứng dụng cơ bản của Gateway là: • Thiết lập kết nối với đầu cuối PSTN tương tự. • Thiết lập kết nối với đầu cuối tương hợp H.320 đầu xa qua mạng chuyển mạch mạch dựa trên nền ISDN. • Thiết lập kết nối với các đầu cuối tương hợp H.324 đầu xa qua mạng PSTN. Các thiết bị đầu cuối giao tiếp với Gateway sử dụng giao thức H.245 và Q.931. 2.2.3. Gatekeeper: Gatekeeper là thành phần quan trọng nhất của mạng H.323. Nó là trung tâm của mọi cuộc gọi trong vùng H.323. Gatekeeper cung cấp các dịch vụ điều khiển cuộc gọi cho các Endpoint. Hay có thể coi Gatekeeper H.323 hoạt H.323 Terminal Function Translation ( Translation Format / Conmmunication procedure SCN Terminal Function Gateway Function Protocol Conversion and Transmission Translation IP/PSTN Gateway SCN LAN Các chức năng của Gateway H.323 Terminal Function SCN Terminal Function PSTN 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 62 động như một bộ chuyển mạch ảo. Chuẩn H.323 định nghĩa các dịch vụ mà Gatekeeper phải cung cấp và xác định các chức năng tùy chọn khác mà nó có thể cung cấp. Một vùng H.323 được quản lý bởi một Gatekeeper duy nhất. Các chức năng cơ bản của Gatekeeper: • Biên dịch địa chỉ: Cuộc gọi khởi tạo trong mạng H.323 sử dụng một địa chỉ định danh máy đích. Cuộc gọi thiết lập ngoài mạng H.323 và nhận được ở Gateway bằng cách dùng số điện thoại để định địa chỉ đích. Gatekeeper biên dịch số điện thoại hoặc bí danh sang địa chỉ IP sử dụng cho mạng. • Ðiều khiển đăng nhập: Gatekeeper điều khiển việc tiếp nhận các Endpoint bằng cách sử dụng các thông điệp RAS như yêu cầu đăng nhập (ARQ), xác nhận đăng nhập (ARC) và từ chối đăng nhập (ARJ). Ðiều khiển đăng nhập cũng có thể là một hàm rỗng chấp nhận mọi yêu cầu đăng ký của các Endpoint trong mạng. • Ðiều khiển băng thông: Gatekeeper điều khiển băng thông thông qua các thông điệp RAS, yêu cầu, xác nhận hay loại bỏ băng thông (BRQ/BCF/BRJ). Ðiều này có thể dựa vào chức năng quản lý băng thông của Gatekeeper. Ðiều khiển băng thông cũng có thể là một hàm rỗng chấp nhận cho mọi yêu cầu thay đổi băng thông. • Quản lý vùng: Gatekeeper cung cấp tất cả các chức năng trên cho các đầu cuối, MCU và Gateway đăng ký trong vùng điều khiển của nó. Một đặc tính tuỳ chọn nhưng quan trong của Gatekeeper là khả năng định tuyến các cuộc gọi H.323. Endpoint gởi các tín hiệu báo hiệu đến Gatekeeper, sau đó Gatekeeper tìm đường đến Endpoint đích. Một cuộc gọi được định tuyến thông qua một Gatekeeper sẽ hiệu quả hơn. Các chức năng tùy chọn là: • Báo hiệu điều khiển cuộc gọi: Gatekeeper có thể tìm đường cho các tín hiệu báo hiệu giữa hai H.323 Endpoint. Trong một kết nối 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 63 điểm - điểm, Gatekeeper xử lý báo hiệu điều khiển cuộc gọi H.225. Gatekeeper cho phép các thông điệp trên được gởi trực tiếp giữa các Endpoint trong mạng. • Chấp nhận cuộc gọi: Gatekeeper có thể tiếp nhận hoặc từ chối cuộc gọi từ đầu cuối theo khuyến nghị Q.931. Tiêu chuẩn xét không thuộc H.323. • Quản lý băng thông: Gatekeeper có thể từ chối các cuộc gọi từ đầu cuối nếu nó xét thấy lượng băng thông không đáp ứng đủ. Tiêu chuẩn xét băng thông không được định nghĩa trong chuẩn H.323. • Quản lý cuộc gọi: Gatekeeper có thể duy trì danh sách các cuộc gọi H.323 để biểu thị đầu gọi bị gọi đang bận hoặc để cung cấp thông tin cho chức năng quản lý băng thông. 2.2.4. MCU (Multipoint Control Unit): MCU hỗ trợ hội nghị từ ba Endpoint trở lên. Theo H.323, một MCU gồm một bộ điều khiển đa điểm MC, không hoặc nhiều bộ xử lý đa điểm MP. Call Signalling (Q 931) Call Control (H.245) Media Stream (RTP) GateKeeper Address Translation Admission Control Bandwidth Control (RAS) Terminal Gateway Chức năng của Gatekeeper 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 64 MC điều khiển tương tác H.245 giữa các đầu cuối để xác định khả năng chung trong việc xử lý âm thanh và hình ảnh. MC cũng điều khiển tài nguyên hội nghị bằng cách xác định xem có dòng âm thanh và hình ảnh nào là quãng bá không. MC không xử lý trực tiếp bất kỳ dòng truyền thông nào. Việc này được thực hiện bởi MP. MP thực hiện trộn, chuyển mạch và xử lý âm thanh, hình ảnh và các bit dữ liệu. Những khả năng của MP và MC có thể cùng có mặt trong một phần chuyên biệt hoặc một phần của các thành phần H.323 khác. 2.3. Sơ đồ cấu trúc phân lớp: Terminal 1 MC Terminal 2 Gatekeeperl 1 MC Gatekeeper 3 Gatekeeper 2 MC MP Gateway 1 MC Gateway 3 MCU 1 MC MP Gateway 2 MC MP MCU 2 MC Các vị trí của MC và MP trong hệ thống H.323 Video I/O Equipment Audio I/O Equipment User Data Applications T.120, etc System Control User Interface Local Area Network Interface Video Codec H.261, H.263 Audio Codec G.711, G.723 G.729 System Control H.245 Control Call Control H.255.0 RAS Control H.255.0 Receive Path Delay H.255.0 Layer Sơ đồ cấu trúc phân lớp 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 65 2.3.1. Video Codec: Mã hóa hình ảnh là khả năng tùy chọn. Nếu được cung cấp nó sẽ theo các yêu cầu trong khuyến cáo này. Mọi đầu cuối H.323 cung cấp truyền thông hình ảnh đều phải có khả năng mã hóa và giải mã hình ảnh theo chuẩn QCIF H.261. Một đầu cuối cũng có thể tùy chọn khả năng mã hóa và giải mã hình ảnh theo H.261 hoặc H.263. Nếu một đầu cuối hỗ trợ H.263 CIF hoặc cao hơn thì