Luận văn tốt nghiệp: 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

CHƯƠNG 0: GIỚI THIỆU................................................................................................4

CHƯƠNG 1: TÌM HIỂU CÁC CHUẨN NÉN ÂM THANH..........................................6

2.1. 2.2. 2.3. 2.4. 2.5. 2.6. 2.7.

3.1. 3.2. 3.3.

4.1. 4.2.

1. Giới thiệu: ...............................................................................................................6 2. Chuẩn nén G.711: ...................................................................................................6 Giới thiệu:......................................................................................................6 Tốc độ lấy mẫu: .............................................................................................6 Quy luật mã hoá: ...........................................................................................7 Truyền tín hiệu ký tự:.....................................................................................7 Mối liên hệ giữa luật mã hóa và cấp độ âm thanh:.......................................7 Sự chuyển đổi giữa A-law và µ-law : ............................................................8 Sự chuyển đổi giữa µ-law và A-law: .............................................................9 3. Chuẩn nén G.723: .................................................................................................12 Giới thiệu:....................................................................................................12 Cơ chế mã hóa:............................................................................................12 Cơ chế giải mã:............................................................................................14 4. Chuẩn nén G.729: .................................................................................................15 Giới thiệu:....................................................................................................15 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

2.1. 2.2. 2.3.

3.1. 3.2.

1. Giới thiệu: .............................................................................................................20 2. Chuẩn nén H.261: .................................................................................................20 Giới thiệu:....................................................................................................20 Đinh dạng ảnh nguồn của chuẩn H.261 ......................................................20 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 Giới thiệu:....................................................................................................26 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

2.1. 2.2. 2.3. 2.4. 2.5. 2.6.

1. Giới thiệu về VoIP: ...............................................................................................28 2. Ưu điểm của VoIP so với PSTN:..........................................................................28 Tiết kiệm băng thông: ..................................................................................28 Đơn giản hóa:..............................................................................................29 Khả năng tích hợp: ......................................................................................29 Uyển chuyển trong quản lý:.........................................................................29 Quản lý tốt: ..................................................................................................29 Giá thành thấp:............................................................................................30 3. Các hình thức truyền thoại trên mạng IP: .............................................................30

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

3.1. 3.2. 3.3.

4.1. 4.2.

5.1. 5.2. 5.3. 5.4. 5.5. 5.6.

6.1.

6.2.

PC-PC : .......................................................................................................30 PC – Phone :................................................................................................30 Phone - Internet - Phone : ...........................................................................30 4. Nguyên tắc và mô hình hoạt động của VoIP: .......................................................31 Quá trình thiết lập một kết nối VoIP : .........................................................31 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 Giao thức UDP (User Datagram Protocol):...............................................31 Giao thức RTP (Realtime Protocol): ...........................................................32 Giao thức RTCP ( RTP Control Protocol ): ................................................32 Giao thức RSVP:..........................................................................................32 SGCP: ..........................................................................................................33 MGCP:.........................................................................................................34 6. Các vấn đề liên quan đến chất lượng dịch vụ : .....................................................34 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 Trễ gói..........................................................................................................35 6.2.1.Tổng quan ...................................................................................................35 6.2.2.Có hai giải pháp: ........................................................................................35 Network Jitter ..............................................................................................35 Kết luận: ......................................................................................................36

6.3. 6.4.

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

4.1. 4.2. 4.3.

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 Thứ tự byte, alignment và định dạng thời gian: ....................................................40 3. 4. Nghi thức truyền dữ liệu RTP (RTP Data Transfer Protocol): .............................40 Các trường cố định trong RTP header:.......................................................40 Ghép kênh các phiên RTP (Multiplexing RTP sessions): ............................43 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 Cấu Trúc của gói RTP (RTP Packet Format): ............................................47 Các thông báo của bên gửi và bên nhận ( Sender and Receiver reports ):.49

5.1. 5.2.

CHƯƠNG 5: TÌM HIỂU CHUẨN H.323 VÀ THƯ VIỆN OPENH323 ......................56

2.1. 2.2.

2.3.

1. Giới thiệu: .............................................................................................................56 2. Chuẩn H.323: ........................................................................................................56 Các ưu điểm của chuẩn H.323: ...................................................................56 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 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

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

2.4.

2.5.

2.6. 2.7. 2.8.

3.1. 3.2.

Đ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 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 Quy trình thiết lập cuộc gọi qua mạng H.323: ............................................71 Mối quan hệ giữa nghi thức H323 và mô hình OSI: ...................................77 Tổng kết: ......................................................................................................77 Thư viện OpenH323..............................................................................................78 Giới thiệu:....................................................................................................78 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 Phương thức hoạt động: ..............................................................................85

3.3.

CHƯƠNG 6: XÂY DỰNG ỨNG DỤNG TRUYỀN THÔNG ĐA PHƯƠNG TIỆN THỂ NGHIỆM ..................................................................................................................88

2.1. 2.2. 2.3.

3.1. 3.2.

4.1. 4.2.

1. Mô hình thực tế: ....................................................................................................88 2. Xác định các yêu cầu: ...........................................................................................88 Các yêu cầu chức năng:...............................................................................88 Các yêu cầu phi chức năng: ........................................................................89 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 Đặc tả chung cho hệ thống:.........................................................................91 Sơ đồ khối của một vài chức năng của client: .............................................92 Thiết kế cơ sở dữ liệu:.........................................................................................100 Các trường của bảng lưu thông tin user như sau:.....................................100 Các trường của bảng lưu thông tin danh sách các user trong contact list101 Thiết kế giao diện:...............................................................................................101 5. 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

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

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

Trần Thanh Long - Nguyễn Thành Nam

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

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. Độ

Trần Thanh Long - Nguyễn Thành Nam

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

Trần Thanh Long - Nguyễn Thành Nam

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

Table 1

Table 2

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

Trần Thanh Long - Nguyễn Thành Nam

bit 1 đến bit 7.

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

• 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:

Trần Thanh Long - Nguyễn Thành Nam

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

Table 3

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

Table 4

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

Trần Thanh Long - Nguyễn Thành Nam

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 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ể

Trần Thanh Long - Nguyễn Thành Nam

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

Biểu đồ khối của bộ mã hóa tín hiệu thoại

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

Trần Thanh Long - Nguyễn Thành Nam

này được kích hoạt để đưa vào bộ lọc tổng hợp.

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

Biểu đồ khối của bộ giải mã tín hiệu thoại

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à

Trần Thanh Long - Nguyễn Thành Nam

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

Nghiên cứu và xây dựng chương trình truyền thông đa phương tiện 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

Biểu đồ khối của mô hình quan niệm tổng hợp CELP

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

Trần Thanh Long - Nguyễn Thành Nam

số đáp ứng không thay đổi. Sự kích hoạt các tham số (các tham số cố định và

Nghiên cứu và xây dựng chương trình truyền thông đa phương tiện 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

Trần Thanh Long - Nguyễn Thành Nam

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

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

Trần Thanh Long - Nguyễn Thành Nam

4.2.2. Nguyên lý giải mã:

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

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ỷ

Trần Thanh Long - Nguyễn Thành Nam

lệ.

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

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à

Trần Thanh Long - Nguyễn Thành Nam

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

Y Y

H.1

Y Y

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

Trần Thanh Long - Nguyễn Thành Nam

toán vector chuyển động không tùy thuộc và sự chuẩn hóa. Thành

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

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

PSC TR PTYPE PEI

PSPARE

PEI

GOB Data

H.2 Structure of picture layer

Trần Thanh Long - Nguyễn Thành Nam

như sau:

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

• 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

1 2 3 QCIF

1 3 5 7

2 4 6 8

9 11

10 12

CIF

H.3 Trật tự của một GOB trong một ảnh

Trần Thanh Long - Nguyễn Thành Nam

(Quarter Common Image Format)

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

Dữ liệu cho một group of block bao gồm một GOB header theo sau là

GBSC GN GQUANT GEI

GSPARE GEI

MB Data

H.4 Structure of GOB Layer

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

10 11

12 13 14 23 24 25

15 16 17 26 27 28

18 19 20 21 22 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

Trần Thanh Long - Nguyễn Thành Nam

16*16 pixel của cường độ sáng và 2 thành phần màu (8*8).

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

• 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

(cid:57) Macroblock 1,12,23

(cid:57) Các macroblock mà MBA có độ sai lệch khác 1

(cid:57) 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

Trần Thanh Long - Nguyễn Thành Nam

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

1 3

2 4

trong một macroblock như sau:

TCOEFF EOB

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 đã

Increasing cycle per picture width

Increasing cycle per picture height

2 5 9 12 20 23 35 37

1 3 4 10 11 21 22 36

6 8 13 19 24 34 38 49

7 14 18 25 33 39 48 50

15 17 26 32 40 47 51 58

16 27 31 41 46 52 57 59

28 30 42 45 53 56 60 63

29 43 44 54 55 61 62 64

đượ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

Trần Thanh Long - Nguyễn Thành Nam

giữa hai chuẩn này.

Nghiên cứu và xây dựng chương trình truyền thông đa phương tiện 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ã

Trần Thanh Long - Nguyễn Thành Nam

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

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

Trần Thanh Long - Nguyễn Thành Nam

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

Trần Thanh Long - Nguyễn Thành Nam

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

Đượ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

Trần Thanh Long - Nguyễn Thành Nam

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

Trần Thanh Long - Nguyễn Thành Nam

đườ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 đủ 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

Trần Thanh Long - Nguyễn Thành Nam

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

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

Trần Thanh Long - Nguyễn Thành Nam

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

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

Trần Thanh Long - Nguyễn Thành Nam

• 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

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

Trần Thanh Long - Nguyễn Thành Nam

• 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

• 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

Trần Thanh Long - Nguyễn Thành Nam

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

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

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

Trần Thanh Long - Nguyễn Thành Nam

video data).

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

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

Trần Thanh Long - Nguyễn Thành Nam

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

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 để

Trần Thanh Long - Nguyễn Thành Nam

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 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):

0 1 2 3 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

Sequence number

4.1. Các trường cố định trong RTP header:

Timestamp Synchronization source (SSRC) identifier Contributing source (CSRC) identifiers ………………………

Định dạng RTP Header

V = 2 P X

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

Trần Thanh Long - Nguyễn Thành Nam

cuối dữ liệu. Octet cuối cùng của phần thêm vào cho biết có bao

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

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,

Trần Thanh Long - Nguyễn Thành Nam

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

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

Trần Thanh Long - Nguyễn Thành Nam

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

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ó

Trần Thanh Long - Nguyễn Thành Nam

đượ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

(cid:131) 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ể.

(cid:131) 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.

(cid:131) Bên nhận cài đặt các xử lý riêng cho mỗi loại dữ liệu.

(cid:131) 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

Trần Thanh Long - Nguyễn Thành Nam

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

• 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ợ

0 1 2 3 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

defined by profile

length

header extension ………………………

Định dạng RTP Header Extension

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

Trần Thanh Long - Nguyễn Thành Nam

mở rộng vào RTP header. Tuy nhiên 16 bit đầu tiên của phần header mở rộng

Nghiên cứu và xây dựng chương trình truyền thông đa phương tiện đượ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

Trần Thanh Long - Nguyễn Thành Nam

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

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.

Trần Thanh Long - Nguyễn Thành Nam

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

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

Trần Thanh Long - Nguyễn Thành Nam

đượ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

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

Trần Thanh Long - Nguyễn Thành Nam

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 đượ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:

0 1 2 3 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

header

V = 2 P

PT = SR = 200

Length

SSRC of sender

NTP timestamp, most significant word

sender info

NTP timestamp, least significant word RTP timestamp sender’s packet count sender’s octet count

SSRC_1 (SSRC of first source)

report block 1

cumulative number of packets lost

a. SR – Sender Report RTCP packet format:

extended highest sequence number received iterarrival jitter last SR (LSR) delay since last SR (DLSR)

report block 2

SSRC_2 (SSRC of second source) ……………….

profile-specific extensions

Định dạng SR

fraction lost

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

Trần Thanh Long - Nguyễn Thành Nam

dữ liệu RTP và RTCP.

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

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

Trần Thanh Long - Nguyễn Thành Nam

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

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.

0 1 2 3 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

header

PT = SR = 201

Length

b. RR – Receiver Report RTCP packet format:

SSRC of sender

SSRC_1 (SSRC of first source)

report block 1

fraction lost

cumulative number of packets lost

extended highest sequence number received iterarrival jitter

last SR (LSR) delay since last SR (DLSR)

report block 2

SSRC_2 (SSRC of second source) ……………….

profile-specific extensions

Định dạng RR

Trần Thanh Long - Nguyễn Thành Nam

V = 2 P

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

0 1 2 3 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

PT = SR = 202

Length

c. SDES – Source Description RTCP packet format:

SSRC/CSRC_1 SDES items ……..

SSRC/CSRC_2 SDES items ……..

Định dạng SDES

V = 2 P

0 1 2 3 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

CNAME = 1

length

user and domain name …

Định dạng CNAME

d. CNAME – Canonical end point identifier SDES item:

0 1 2 3 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

NAME = 2

length

common name source …

Định dạng NAME

e. NAME – Uer name SDES item:

0 1 2 3 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

EMAIL = 3

length

mmail address of source …

Định dạng EMAIL

f. EMAIL – Electronic mail address SDES item:

0 1 2 3 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

PHONE = 4

length

phone number of source …

Định dạng PHONE

Trần Thanh Long - Nguyễn Thành Nam

g. Phone – phone number SDES item:

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

0 1 2 3 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

length

geographic location of source …

h. LOC – Geographic user location SDES item:

Định dạng LOC

LOC = 5

0 1 2 3 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

TOOL = 6

length

name/ version of source appliaction…

Định dạng TOOL

i. TOOL – Application or tool name SDES item:

0 1 2 3 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

NOTE = 7

length

note about the source…

Định dạng NOTE

j. NOTE – Notice/status SDES item:

0 1 2 3 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

length

prefix length

prefix string…

k. PRIV – Private extensions SDES item:

value string…

Định dạng PRIV

PRIV = 8

0 1 2 3 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

PT = BYE = 203

length

l. BYE – Goodbye RTCP packet:

SSRC/CSRC

……..

reason for leaving

length

Định dạng BYE

Trần Thanh Long - Nguyễn Thành Nam

V = 2 P

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

0 1 2 3 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

subtype

PT = APP = 204

length

m. APP – Application defined RTCP lacket:

SSRC/CSRC name (ASCII) application dependent data

Định dạng APP

Trần Thanh Long - Nguyễn Thành Nam

V = 2 P

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

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ợ

Trần Thanh Long - Nguyễn Thành Nam

chung.

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

• 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:

Trần Thanh Long - Nguyễn Thành Nam

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

• 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

H.323 Zone

H.323 Terminal

H.323 MCU

H.323 Gatekeeper

H.323 Gateway

mạng đó là: Terminal, Gateway, Gatekeeper và MCU.

H.323 Terminal

H.323 Router

Các thành phần trong hệ thống H.323

Trần Thanh Long - Nguyễn Thành Nam

H.323 Terminal

Nghiên cứu và xây dựng chương trình truyền thông đa phương tiện 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

H.323 Terminal Equipment

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à:

Trần Thanh Long - Nguyễn Thành Nam

• Giao thức Q.931 dùng cho báo hiệu và thiết lập cuộc gọi.

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

• 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

H.323/PSTN Gateway

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

Trần Thanh Long - Nguyễn Thành Nam

sang H.242). Ngoài ra, Gateway cũng biên dịch giữa các bộ mã hoá âm thanh

Nghiên cứu và xây dựng chương trình truyền thông đa phương tiện 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.

Gateway Function

H.323 Terminal Function

SCN Terminal Function

Translation ( Translation Format / Conmmunication procedure

LAN SCN

Protocol Conversion and Transmission Translation

SCN Terminal Function

H.323 Terminal Function

IP/PSTN Gateway

PSTN

(cid:11)

Các chức năng của Gateway

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ụ

Trần Thanh Long - Nguyễn Thành Nam

điều khiển cuộc gọi cho các Endpoint. Hay có thể coi Gatekeeper H.323 hoạt

Nghiên cứu và xây dựng chương trình truyền thông đa phương tiện độ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

Trần Thanh Long - Nguyễn Thành Nam

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

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

Call Signalling (Q 931)

Call Control (H.245)

Media Stream (RTP)

Terminal Gateway

Address Translation Admission Control Bandwidth Control (RAS)

Chức năng của Gatekeeper

GateKeeper

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

Trần Thanh Long - Nguyễn Thành Nam

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.

Nghiên cứu và xây dựng chương trình truyền thông đa phương tiện 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

Terminal 1

Terminal 2

Gatekeeperl 1

Gatekeeper 2

Gatekeeper 3

MC MP

Gateway 1

MC MP Gateway 2

Gateway 3

MC MP MCU 1

MCU 2

Các vị trí của MC và MP trong hệ thống H.323

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.

Video Codec H.261, H.263

2.3. Sơ đồ cấu trúc phân lớp:

Video I/O Equipment

Receive Path Delay

Audio Codec G.711, G.723 G.729

Local Area Network Interface

System Control

H.255.0 Layer

Audio I/O Equipment

H.245 Control

Call Control H.255.0

System Control User Interface

RAS Control H.255.0

Sơ đồ cấu trúc phân lớp

Trần Thanh Long - Nguyễn Thành Nam

User Data Applications T.120, etc

Nghiên cứu và xây dựng chương trình truyền thông đa phương tiện 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ì cũng hỗ trợ H.261 CIF. Tất cả đầu cuối hỗ trợ H.263 sẽ hỗ trợ

H.263 QCIF. Các bộ mã hóa hình ảnh khác và các dạng hình ảnh khác cũng

có thể được dùng thông qua thoả thuận trong H.245. Nhiều kênh hình ảnh

được truyền và nhận qua kênh điều khiển H.245.

Các tuỳ chọn về tốc độ truyền bit ảnh, dạng ảnh và giải thuật truyền có

thể được chấp nhận bởi bộ giải mã được định nghĩa trong suốt thời gian trao

đổi khả năng sử dụng H.245.Các đầu cuối H.323 có thể hoạt động ở các tốc

độ bit hình ảnh, tốc độ khung không cân đối và các giải pháp hình ảnh nếu có

nhiều giải pháp hình ảnh hỗ trợ. Chẳng hạn cho phép một đầu cuối CIF

truyền hình ảnh QCIF trong khi nhận hình ảnh CIF. Dòng hình ảnh được định

dạng như mô tả trong chuẩn H.225.0

Trong những trường hợp các đầu cuối H.323 nhận nhiều kênh hình

ảnh, đầu cuối cần thực hiện chức năng trộn hoặc chuyển mạch hình ảnh để

truyền báo hiệu hình ảnh đến người dùng. Chức năng này có thể bao gồm

truyền nhiều hình ảnh đến người dùng.

2.3.2. Audio Codec:

Mọi đầu cuối H.323 đều cần có một bộ mã hóa âm thanh. Khả năng mã

hóa và giải mã âm thanh của các đầu cuối H.323 dựa theo chuẩn G.711 (64

Kbps). Tất cả thiết bị đầu cuối đều có khả năng phát và nhận theo luật A và

µ. Một thiết bị đầu cuối có thể tùy chọn mã hóa và giải mã âm thanh dựa trên

các chuẩn khác của ITU như G.722 (64 Kbps, 56 Kbps và 48 Kbps), G.728

Trần Thanh Long - Nguyễn Thành Nam

(17 Kbps), G.729 (8 Kbps), MPEG và G.723.1 (5.3 Kbps và 6.3 Kbps). Giải

Nghiên cứu và xây dựng chương trình truyền thông đa phương tiện thuật mã hóa âm thanh được bộ mã hóa sử dụng sẽ được cung cấp trong quá

trình trao đổi khả năng sử dụng H.245. Đầu cuối H.323 phải có khả năng hoạt

động không cân đối trong mọi khả năng âm thanh mà nó đã được khai báo

trong cùng tập hợp khả năng đó, chẳng hạn như gởi G.711 và nhận G.728.

Đầu cuối H.323 có thể gởi một hoặc nhiều kênh âm thanh cùng lúc.

2.3.3. Data Channel (Kênh dữ liệu):

Một hoặc nhiều kênh dữ liệu là tuỳ chọn. Kênh dữ liệu có thể là đơn

hướng hoặc đa hướng. Chuẩn T.120 là nền tảng mặc định cho khả năng liên

kết hoạt động dữ liệu với nhau giữa đầu cuối H.323 và các đầu cuối H.323,

H.324, H.320 hoặc H.310 khác. Bất kỳ ứng dụng dữ liệu nào sử dụng một

hoặc nhiều chuẩn ITU-T đều có thể được thoả thuận thông qua H.245.

2.4. Điều khiển hệ thống:

2.4.1. Chức năng điều khiển H.245:

Chức năng điều khiển H.245 sử dụng kênh điều khiển H.245 để mang

thông điệp điều khiển End - to - End, điều khiển hoạt động của thực thể

H.323 bao gồm: trao đổi khả năng, mở và đóng kênh logic, yêu cầu chế dộ ưu

tiên, thông điệp điều khiển dòng và tạo những lênh, chỉ thị.

Báo hiệu H.245 được thiết lập giữa hai Endpoint, giữa một Endpoint

và một MC, hoặc giữa một Endpoint và một Gatekeeper. Endpoint thiết lập

chính xác một kênh điều khiển H.245 cho mỗi cuộc gọi mà nó tham gia.

Kênh này sử dụng các thông điệp và thủ tục trong chuẩn H.245. Một

Terminal, MCU, Gateway, hoặc Gatekeeper có thể hỗ trợ nhiều cuộc gọi, do

đó có nhiều kênh điều khiển H.245.

Khuyến cáo H.245 chỉ ra một số phương thức độc lập hỗ trợ báo hiệu

Endpoint – to – Endpoint. Một phương thức được chỉ rõ bởi cú pháp, ngữ

nghĩa, và một tập các thủ tục của nó để chỉ rõ sự trao đổi thông điệp và sự

tương tác với người dùng. Các Endpoint H.323 sẽ hỗ trợ cú pháp, ngữ nghĩa

Trần Thanh Long - Nguyễn Thành Nam

và các thủ tục bởi các giao thức sau:

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

• Xác định chủ tớ.

• Trao đổi khả năng.

• Báo hiệu kênh logic.

• Báo hiệu kênh logic hai chiều.

• Báo hiệu đóng kênh logic.

• Yêu cầu chế độ.

• Xác định độ trì hoãn.

• Báo hiệu vòng bảo tri.

Các thông điệp của H.245 gồm: Request, Respone, Command, và

Indication.

2.4.2. Chức năng báo hiệu RAS H.225.0:

Chức năng báo hiệu RAS sử dụng thông điệp H.225.0 để thực hiện

đăng ký, đăng nhập thay đổi băng thông trạng thái và xoá các thủ tục giữa các

Endpoint và Gatekeeper. Kênh này độc lập với kênh báo hiệu cuộc gọi và

kênh điều khiển H.245. Thủ tục mở kênh logic H.245 không dùng để thiết lập

kênh báo hiệu RAS. Trong môi trường mạng không có Gatekeeper thì không

sử dụng kênh báo hiệu RAS. Nếu có Gatekeeper thì kênh báo hiệu RAS được

mở giữa Endpoint và Gatekeeper và được mở trước khi thiết lập các kênh

khác giữa các H.323 Endpoint.

Kênh báo hiệu RAS H.225.0 là kênh không tin cậy, mang thông điệp

dùng trong quá trình tìm Gatekeeper và đăng ký Endpoint liên quan đến địa

chỉ định danh của Endpoint trong địa chỉ chuyển tải kênh báo hiệu cuộc gọi.

Vì kênh báo hiệu RAS không tin cậy nên chuẩn H.225.0 đưa ra thời gian

Timeout và được đếm lại cho mỗi thông điệp khác nhau. Một Endpoint hay

Gatekeeper không đáp ứng được yêu cầu trong thời gian Timeout thì có thể

dùng thông điệp RIP (Request In Progress) để thông báo rằng nó vẫn đang

tiếp tục yêu cầu. Một Endpoint hay Gatekeeper nhận RIP sẽ xoá Timeout của

Trần Thanh Long - Nguyễn Thành Nam

nó và đếm lại.

Nghiên cứu và xây dựng chương trình truyền thông đa phương tiện 2.4.3. Chức năng báo hiệu cuộc gọi H.225.0:

Dùng để thiết lập kết nối giữa hai H.323 Endpoint. Kênh báo hiệu cuộc

gọi độc lập với kênh RAS và kênh điều khiển H.245. Không dùng thủ tục mở

kênh logic H.245 để thiết lập kênh báo hiệu cuộc gọi. Kênh báo hiệu cuộc gọi

được mở trước khi thiết lập kênh H.245 và các kênh logic giữa các H.323

Endpoint. Kênh báo hiệu cuộc gọi là một kênh tin cậy, được dùng để mang

thông điệp điều khiển cuộc gọi H.225.0.

Trong hệ thống không có Gatekeeper , kênh báo hiệu cuộc gọi được

mở giữa hai Endpoint liên quan đến cuộc gọi. Thông điệp báo hiệu cuộc gọi

được truyền trực tiếp giữa hai Endpoint chủ gọi và Endpoint bị gọi sử dụng

địa chỉ chuyển tải kênh báo hiệu. Trong trường hợp này, xem như Endpoint

chủ gọi đã biết địa chỉ chuyển tải kênh báo hiệu cuộc gọi của Endpoint bị gọi

nên có thể truyền trực tiếp.

Trong hệ thống có Gatekeeper, kênh báo hiệu cuộc gọi được mở giữa

Endpoint và Gatekeeper, hoặc giữa các Endpoint với nhau ( do Gatekeeper

quyết định).

Định tuyến kênh báo hiệu cuộc gọi:

a. Gatekeeper tìm đường báo hiệu cuộc gọi. Thông điệp báo hiệu cuộc

gọi giữa các Endpoint được định tuyến qua Gatekeeper.

4 5 6

1 2 3 8

Gatekeeper Cloud

1 ARQ 2 ACF/ARJ 3 Set-up 4 Set-up 5 ARQ 6 ACF/ARJ 7 Connect 8 Connect

Call Signalling Channel Message

RAS Channel Messages

Gatekeeper tìm đường báo hiệu cuộc gọi

Trần Thanh Long - Nguyễn Thành Nam

Endpoint 1 Endpoint 2

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

b. Báo hiệu cuộc gọi trực tiếp giữa các Endpoint, thông điệp báo hiệu

cuộc gọi được truyền trực tiếp giữa các Endpoint.

1 ARQ 2 ACF/ARJ 3 Set-up 4 ARQ

Gatekeeper Cloud

5 ACF/ARJ 6 Connect

Call Signalling Channel Message

RAS Channel Messages

Báo hiệu cuộc gọi trực tiếp giữa các Endpoint

Endpoint 1 Endpoint 2

Định tuyến kênh điều khiển:

Khi báo hiệu cuộc gọi được định tuyến bởi Gatekeeper, có hai phương

pháp định tuyến kênh điều khiển H.245 được dùng:

a. Kênh điều khiển H.245 được thiết lập trực tiếp giữa các Endpoint.

4 5 6

1 2 3 8

Gatekeeper Cloud

1 ARQ 2 ACF/ARJ 3 Set-up 4 Set-up 5 ARQ 6 ACF/ARJ 7 Connect 8 Connect 9 H.245 Channel

H.245 Control Channel Message

Call Signalling Channel Message RAS Channel Messages Thiết lập kênh điều khiển H.245 trực tiếp giữa các Endpoint

Trần Thanh Long - Nguyễn Thành Nam

Endpoint 1 Endpoint 2

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

b. Kênh điều khiển H.245 được định tuyến giữa các Endpoint thông

qua Gatekeeper. Phương pháp này cho phép Gatekeeper gởi lại

kênh điều khiển H.245 vào cho MC khi hội nghị chuyển từ điểm -

điểm sang đa điểm. Khi báo hiệu cuộc gọi được thực hiện trực tiếp

giữa các Endpoint, kênh điều khiển H.245 chỉ được kết nối trực tiếp

với các Endpoint.

1 2 3 8

4 5 6

Gatekeeper Cloud

H.245 Control Channel Message

Call Signalling Channel Message RAS Channel Messages

Gatekeeper định tuyến kênh điều khiển H.245

Endpoint 1 Endpoint 2

1 ARQ 2 ACF/ARJ 3 Set-up 4 Set-up 5 ARQ 6 ACF/ARJ 7 Connect 8 Connect 9 H.245 Channel 10 H.245 Channel

2.5. Hội nghị đa điểm:

Khả năng hội nghị đa điểm theo chuẩn H.323 được tổ chức bằng nhiều

phương pháp và cấu hình phong phú. Chuẩn H.323 đưa ra ba mô hình hội

nghị đa điểm: hội nghị đa điểm tập trung, hội nghị đa điểm phân tán, hội nghị

đa điểm tập trung và phân tán kết hợp.

2.5.1. Hội nghị đa điểm tập trung:

Dùng MCU để làm linh hoạt hội nghị đa điểm. Các đầu cuối gởi các

dòng âm thanh, hình ảnh, dữ liệu và tín hiệu điều khiển đến MCU theo mô

hình điểm - điểm. MCU quản lý hội nghị đa điểm tập trung sử dụng các chức

Trần Thanh Long - Nguyễn Thành Nam

năng điều khiển H.245. MP thực hiện trộn âm thanh, phân phối dữ liệu, trộn

Nghiên cứu và xây dựng chương trình truyền thông đa phương tiện hoặc chuyển mạch các hình ảnh và gởi kết quả cho đầu cuối tham gia trong

mạng, cung cấp sự chuyển đổi giữa các bộ mã hoá tốc độ bit khác nhau và có

thể dùng chế độ quảng bá thông tin để phân phối hình ảnh xử lý được. MCU

tiêu biểu hỗ trợ hội nghị đa điểm tập trung gồm một MC và một MP.

2.5.2. Hội nghị đa điểm phân tán:

Dùng kỹ thuật quãng bá thông tin. Các đầu cuối H.323 tham gia trong

mạng truyền quảng bá âm thanh và hình ảnh đến các đầu cuối khác không

qua MCU. Tuy nhiên, dữ liệu điều khiển vẫn được xử lý tập trung bởi MCU,

thông tin điều khiển H.245 vẫn được truyền theo mô hình điểm - điểm đến

MC.

2.5.3. Hội nghị đa điểm tập trung và phân tán kết hợp:

Báo hiệu H.245 hoặc âm thanh hoặc hình ảnh được xử lý thông qua

thông điệp truyền điểm - điểm đến MCU. Báo hiệu còn lại ( hình ảnh hoặc

âm thanh) truyền đến đầu cuối theo kiểu quảng bá.

Một lợi điểm của hội nghị tập trung là tất cả đầu cuối H.323 đều hỗ trợ

truyền thông điểm - điểm. Một MCU có thể truyền đi nhiều dòng tín hiệu đơn

đến các đầu cuối tham gia hội nghị mà không cần yêu cầu khả năng đặc biệt

nào của mạng. Ngược lại, MCU có thể nhận nhiều tín hiệu đơn, sau đó thực

hiện trộn âm thanh, chuyển mạch hình ảnh và truyền thành luồng quảng bá,

duy trì băng thông cho mạng.

H.323 cũng hỗ trợ hội nghị đa điểm hỗn hợp, trong đó một số thiết bị

đầu cuối là tập trung, một số thiết bị đầu cuối là phân tán và MCU là cầu nối

giữa hai mạng này. Các đầu cuối tham gia trong hội nghị không biết được bản

chất thật sử của hội nghị hỗn hợp mà chỉ hiểu đơn giản đó là một kiểu kết nối

mà trong đó nó gởi và nhận.

2.6. Quy trình thiết lập cuộc gọi qua mạng H.323:

Trần Thanh Long - Nguyễn Thành Nam

• Endpoint đăng ký với Gatekeeper.

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

• Gatekeeper nhận đăng ký của endpoint và cho phép Endpoint thiết

lập cuộc gọi và thực hiện chuyển đổi địa chỉ (ARP)

• Thiết lập các báo hiệu cuộc gọi tương ứng, khởi động cuộc gọi nếu

thành công hoặc từ chối cuộc gọi nếu không thể kết nôis

• Điều chỉnh các chức năng của hệ thống trong suốt cuộc gọi, trao đổi

thông tin và xác định chế độ hoạt động của hệ thống

• Định dạng và mở kênh truyền, thu và phát dòng dữ liệu

• Thay đổi người gọi, các thông số, phương tiện truyền thông

ARQ(1)

H.225 Signalling

RAS Message

ACF(2)

SETUP(3)

ARQ(5)

ACF(6)

Connect (8)

H323 Call Establishment

• Kết thúc cuộc gọi và loại bỏ đăng ký ban đầu ở Gatekeeper.

Mô hình như sau: Call Proceeding (4) Alerting (7) Endpoint1 gởi thông điệp RAS ARQ trên kênh điều khiển RAS đến 1.

gatekeeper để đăng ký. Endpoint1 yêu cầu báo hiệu cuộc gọi trực tiếp.

2. Gatekeeper xác nhận sự kết nối của Endpoint1 bằng cách gởi thông

điệp ACF cho Endpoint1. Gatekeeper chỉ thị cho Endpoint1 có thể sử

Trần Thanh Long - Nguyễn Thành Nam

dụng báo hiệu cuộc gọi trực tiếp.

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

Endpoint1 gởi thông điệp báo hiệu cuôc gọi H.225 SETUP đến cho

Endpoint2 để yêu cầu tạo kết nối.

4. Endpoint2 gởi trả lời thông điệp H225 Call Proceeding đến Endpoint1.

5. Endpoint2 đã đăng ký với Gatekeeper, và gởi thông điệp RAS ARQ

trên kênh điều khiển RAS đến cho Gatekeeper.

6. Gatekeeper xác nhận sự đăng kỹ bằng cách gởi thông điệp RAS ACF

đến cho Endpoint2.

7. Endpoint2 thông báo cho Endpoint1 biết kết nối đã được thiết lập bằng

cách gởi thông điệp Alerting đến cho Endpoint1.

8. Sau đó, Endpoint2 xác nhận sự thiết lập kết nối bằng cách gởi thông

TerminalCapabilitySet(9)

TerminalCapabilitySetAck(10)

H245 Message

TerminalCapabilitySetAck(12)

OpenLogicalChannel(13)

OpenLogicalChannelAck(14)

OpenLogicalChannelAck(16)

H.323 Control Signaling Flows

điệp Connect đển Endpoint1.

TerminalCapabilitySet(11) OpenLogicalChannel(15) Kênh điều khiển H.245 được thiết lập giữa Endpoint1 và Endpoint2. 9.

Endpoint1 gởi thông điệp H245 TerminalCapabilitySet đến Endpoint2

để cho Endpoint2 biết khả năng của mình.

10. Endpoint2 báo nhận cho Endpoint1 bằng cách gởi thông điệp H245

TerminalCapabilitySetAck cho Endpoint1.

11. Endpoint2 gởi thông điệp H245 TerminalCapabilitySet đến Endpoint1

Trần Thanh Long - Nguyễn Thành Nam

để cho Endpoint1 biết khả năng của mình.

Nghiên cứu và xây dựng chương trình truyền thông đa phương tiện 12. Endpoint1 báo nhận cho Endpoint2 bằng cách gởi thông điệp H245

TerminalCapabilitySetAck cho Endpoint2.

13. Endpoint1 mở kênh truyền thông với Endpoint2 qua thông điệp H245

OpenLogicalChannel. Địa chỉ chuyển tải của kênh điều khiển RTCP

bao gồm trong thông điệp này.

14. Endpoint2 xác nhận sự thiết lập này và gởi thông điệp H245

OpenLogicalChannelAck. Trong thông điệp này bao gồm địa chỉ

chuyển tải RTP được chỉ định bởi Endpoint2 được sử dụng để

Endpoint1 gởi các dòng dữ liệu RTP và địa chỉ RTCP nhận được từ

Endpoint1 trước đó.

15. Endpoint2 mở một kênh truyền thông với Endpoint1 qua thông điệp

H245 OpenLogicalChannel. Địa chỉ chuyển tải của kênh điều khiển

RTCP bao gồm trong thông điệp này.

16. Endpoint1 xác nhận sự thiết lập này và gởi thông điệp H245

OpenLogicalChannelAck. Trong thông điệp này bao gồm địa chỉ

chuyển tải RTP được chỉ định bởi Ep1 được sử dụng để Endpoint2 gởi

các dòng dữ liệu RTP và địa chỉ RTCP nhận được từ Endpoint2 trước

RTP Media Stream (17)

RTP Media Stream (18)

RTCP Messages (19)

RTCP Messages (20)

RTP media stream and RTCP Messages

H.323 Media Stream and Media Control Flows

đó.

Trần Thanh Long - Nguyễn Thành Nam

17. Endpoint1 gởi dòng dữ liệu RTP đã được thiết lập đến cho Endpoint2

Nghiên cứu và xây dựng chương trình truyền thông đa phương tiện 18. Ep2 gởi dòng dữ liệu RTP đã được thiết lập đến cho Ep1.

19. Endpoint1 gởi thông điệp RTCP đến cho Endpoint2.

End Session Command (21)

End Session Command (22)

Release Complete (23)

DRQ (24)

DCF (25)

H.225 Signaling Message

H.245 Message

RAS Message

H.323 Call Release

20. Endpoint2 gởi thông điệp RTCP đến cho Endpoint1.

21. Endpoint2 bắt đầu huỷ cuộc gọi. Nó gởi thông điệp End Session

Command đến cho Endpoint1.

22. Endpoint1 huỷ cuộc gọi và xác nhận bằng thông điệp End Session

Command gởi cho Endpoint2.

23. Endpoint2 hoàn thành việc huỷ cuộc gọi và gởi lại thông điệp Release

Complete đến cho Endpoint1.

24. Endpoint1 và Endpoint2 huỷ đăng ký ở Gatekeeper bằng cách gởi

thông điệp DRQ đến cho Gatekeeper.

25. Gatekeeper huỷ đăng ký của Endpoint1 và Endpoint2 và xác nhận bằng

thông điệp DCF đến cho Endpoint1 và Endpoint2 .

Phương thức thiết lập hội thoại giữa các người dùng máy:

Để thiết lập một cuộc hội thoại, cần phải có một MCU. MCU bao gồm

một MC và có thể có hoặc không có MP. Có nhiều cách để thiết lập một cuộc

Trần Thanh Long - Nguyễn Thành Nam

hội thoại. Các đầu cuối có thể quảng bá thông tin của mình cho các đầu cuối

Nghiên cứu và xây dựng chương trình truyền thông đa phương tiện khác hoặc gởi đến MP, MP thực hiện trộn và phân phối, chuyển các dữ liệu

này đến các thành phần khác tham gia trong cuôc hội thoại. MCU quản lý hội

thoại bằng cách sử dụng các chức năng điều khiển của H.245. Các thông tin

điều khiển được truyền đến MC trên kênh điều khiển H.245. Trong trường

hợp các đẩu cuối tham gia hội thoại quảng bá thông tin của mình đến cách

đầu cuối khác thì MP không được sử dụng để trộn và xử lý dữ liệu, trong khi

đó, các thông tin điều khiển cuộc hội thoại vẫn được truyền trên kênh điều

khiển H.245.

Trên đây là phương thức thiết lập cuộc gọi nói chung, có rất nhiều

trường hợp thiết lập cuộc gọi giữa hai Ep:

• Cả hai Endpoint thiết lập cuộc gọi không thông qua Gatekeeper.

• Cả hai Endpoint đăng ký cùng một Gatekeeper và báo hiệu cuộc gọi

trực tiếp giữa hai Endpoint với nhau.

• Cả hai Endpoint đăng ký cùng một Gatekeeper và Gatekeeper báo

hiệu cuộc gọi.

• Chỉ có Endpoint gọi đăng ký với Gatekeeper và sử dụng báo hiệu

trực tiếp.

• Chỉ có Endpoint gọi đăng ký với Gatekeeper và Gatekeeper báo

hiệu cuộc gọi.

• Chỉ có Endpoint được gọi đăng ký với Gatekeeper và sử dụng báo

hiệu trực tiếp.

• Chỉ có Endpoint được gọi đăng ký với Gatekeeper và Gatekeeper

báo hiệu cuộc gọi.

• Cả hai Endpoint đăng ký hai Gatekeeper khác nhau và sử dụng báo

hiệu cuộc gọi trực tiếp.

• Cả hai Endpoint đăng ký hai Gatekeeper khác nhau và hai

Trần Thanh Long - Nguyễn Thành Nam

Gatekeeper báo hiệu cuộc gọi

Nghiên cứu và xây dựng chương trình truyền thông đa phương tiện 2.7. Mối quan hệ giữa nghi thức H323 và mô hình OSI:

2.8. Tổng kết:

Truyền thông theo chuẩn H.323 có thể xem như kết hợp và truyền các

tín hiệu âm thanh, hình ảnh, dữ liệu. Các thành phần trong hệ thống –

Terminal, Gateway, Gatekeeper, MCU - được quản lý bằng những giao thức

điều khiển, báo hiệu như H.245, H.225.0, Q.931, RAS v.v… Trước khi

truyền các tín hiêu truyền thông đa phương tiện, các tín hiệu này đều được

nén theo chuẩn của các video codec và audio codec được cung cấp bởi chuẩn

H.323. Ngoài ra, các hội nghị hoạt động một cách linh hoạt nhờ vào MCU

Trần Thanh Long - Nguyễn Thành Nam

của hệ thống theo chuẩn H.323.

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

Thư viện OpenH323

3.1. Giới thiệu:

Thư viện hàm OpenH323 là một lớp thư viện bổ sung cho giao thức

H.323 của ITU-T. Thư viện hàm OpenH323 được đưa ra đầu tiên bởi một

công ty của Úc, Equivalence Pty Ltd, năm 1998 – 2000. Thư viện này nhằm

mục đích cung cấp cho các nhà lập trình bộ API để phát triển các ứng dụng

dựa trên chuẩn H.323.

3.2. Cấu trúc phân lớp và phương thức hoạt động:

3.2.1. Cấu trúc phân lớp:

• H245Negotiator

o H323NegTerminalCapabilitySet

o H245NegRoundTripDelay

o H245NegRequestMode

o H245NegMasterSlaveDetermination

o H245NegLogicalChannels

o H245NegLogicalChannel

• H323Capability

o H323_UserInputCapability

o H323RealTimeCapability

(cid:131) H323VideoCapability

+ H323_H261Capability

+ H323NonStandardVideoCapability.

(cid:131) H323AudioCapability

+ H323_LIDCapability

+ H323_GSM0610Capability

+ H323_G711Capability

+ H323_ACMG7231Capability.

Trần Thanh Long - Nguyễn Thành Nam

+ H323NonStandardAudioCapability

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

- H323_ACMCapability.

o H323DataCapability

(cid:131) H323_T120Capability

(cid:131) H323NonStandardDataCapability

• H323CapabilityList

• H323CapabilitySet

• H323Channel

o H323UniDirectionalChannel

(cid:131) H323_RTPChannel

o H323BiDirectionalChannel

• H323ChannelNumber

• H323Codec

o H323VideoCodec

(cid:131) H323_H261Codec

o H323AudioCodec.

(cid:131) H323_LIDCodec

(cid:131) H323FramedAudioCodec

+ H323_GSM0610Codec

+ H323_ACMCodec

+ H323StreamedAudioCodec

- H323_ µLawCodec

- H323_ALawCodec.

• H323Connection

• H323ControlPDU

• H323Endpoint

• H323GateKeeper

• H323GloballyUniqueID

Trần Thanh Long - Nguyễn Thành Nam

• H323Listener

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

o H323ListenerTCP

• H323NonStandardCapabilityInfo

o H323NonStandardVideoCapabilityInfo

o H323NonStandardDataCapabilityInfo

o H323NonStandardAudioCapabilityInfo

(cid:131) H323_ACMCapabilityInfo

• H323SignalPDU

• H323Transport

• H323TransportIP

o H323TransportUDP

• H323TransportAddress

• H323VideoDevice

o PPMVideoOutputDevice

o NulVideoOutputDevice

• OpalLineChannel

• OpalLineInterfaceDevice

o OpalVpbDevice

o OpalIxJDevice

• Q931

• RTP_ControlFrame

• RTP_DataFrame

• RTP_Session.

o RTP_UDP

• RTP_SessionManager

• RTP_UserData

o H323_RTP_Session

(cid:131) H323_RTP_UDP.

Trần Thanh Long - Nguyễn Thành Nam

• X224

Nghiên cứu và xây dựng chương trình truyền thông đa phương tiện 3.2.2. Ý nghĩa một số lớp trong thư viện:

• Class H323Connection:

Class này trình bày một kết nối H.323 cụ thể giữa hai Endpoint. Có ít

nhất hai tiểu trình được sử dụng, một tiểu trình được dùng để lắng nghe các

tín hiệu trên kênh báo hiệu, tiểu trình còn lại được dùng để lắng nghe các tín

hiệu trên kênh điều khiển. Cứ mỗi kênh dữ liệu được tạo ra bởi kênh điều

khiển thì tương ứng có một tiểu trình được tạo ra để quản lý.

o Tạo một kết nối mới:

H323Connection(

H323EndPoint & endpoint, unsigned callReference,

unsigned options = 0);

o Hiểu một kết nối:

~H323Connection();

• Class H323EndPoint:

Lớp này quản lý một H.323 Endpoint. Một Endpoint có thể không có

hoặc có nhiều Listener để tạo kết nối đến hoặc kết nối đi được thiết lập thông

qua hàm MakeCall(). Một kết nối tồn tại được quản lý bởi lớp này. Mỗi ứng

dụng có thể tạo một lớp kế thừa từ lớp này và overide hàm

CreateConnection() nếu cần thiết.

o Tạo một Endpoint mới:

H323EndPoint();

o Hủy một Endpoint:

~H323EndPoint();

• Class H323Listener:

Lớp này mô tả một “listener” trên một giao thức chuyển tải. Một

“listener” là một đối tượng lắng nghe các kết nối đến trên một kênh chuyển

tải cụ thể. Nó được thực thi như là một tiểu trình riêng biệt.

Hàm Main() được sử dụng để quản lý các kết nối H.323 đến và gởi

Trần Thanh Long - Nguyễn Thành Nam

chúng đến các tiểu trình mới dựa trên vào lớp H323Transport. Điều này được

Nghiên cứu và xây dựng chương trình truyền thông đa phương tiện định nghĩa trong lớp dẫn xuất sử dụng các mức chuyển tải bên dưới, ví như

H323ListenerIP for the TCP/IP protocol. Một ứng dụng có thể tạo dẫn xuất từ

lớp này và overide các hàm cần thiết cho hoạt động của kênh giao thức.

o Tạo mới một Listener:

H323Listener(H323EndPoint & endpoint );

• Class H323ListenerTCP:

Lớp này quản lý các kết nối H323 dùng kênh TCP/IP Transport.

o Tạo mới một Listener cho giao thức TCP/IP:

H323ListenerTCP(

H323EndPoint & endpoint,

PIPSocket::Address binding,

WORD port,

BOOL exclusive = FALSE );

o Hủy một Listener:

~H323ListenerTCP();

• Class H323Gatekeeper:

Lớp này mô tả giao thức H.255.0 RAS đến Gatekeeper.

o Tạo mới một Gatekeeper:

H323Gatekeeper(

H323EndPoint & endpoint,

H323Transport * transport );

o Hủy một Gatekeeper:

~H323Gatekeeper();

• Class H323Channel:

Lớp này mô tả một kênh Logic giữa hai Endpoint. Những kênh này

được tạo và hủy theo yêu cầu trong giao thức H245. Ứng dụng có thể tạo lớp

dẫn xuất của lớp này và overide các hàm cần dùng cho hoạt động của giao

thức.

Trần Thanh Long - Nguyễn Thành Nam

o Tạo mới một kênh H323:

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

H323Channel(

H323Connection & connection,

const H323Capability & capability );

o Hủy một kênh H323.:

Để tránh trường hợp sử dụng những đối tượng đã bị xóa trong tiểu

trình nền, do đó phải chờ tiểu trình H323LogicalChannelThread kết thúc

trước khi tiếp tục.

~H323Channel();

• Class H323_RTPChannel:

Lớp này sử dụng cho giao tiếp IETF Real Time Protocol.

o Tạo mới kênh H323_RTPChannel:

H323_RTPChannel(

H323Connection & connection,

const H323Capability & capability,

Directions direction, RTP_Session & rtp );

o Hủy một kênh H323_RTPChannel:

~H323_RTPChannel();

• Class H323CapabilityList:

Lớp này mô tả toàn bộ khả năng của một Endpoint, thường là các

codec, được sử dụng để chuyển đổi dữ liệu qua các kênh logic được mở và

quản lý bởi kênh điều khiển H323.

Lưu ý rằng bản thân lớp này không phải là thể hiện của một codec. Chỉ

đơn thuần là mô tả các codec. Ứng dụng có thể tạo ra dẫn xuất từ lớp này và

overide một số hàm cần thiết.

• Class H323CapabilitySet:

Định nghĩa cấu trúc hỗn hợp cho khả năng trao đổi và các kết hợp các

Trần Thanh Long - Nguyễn Thành Nam

khả năng này.

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

• Class H323Codec:

Lớp này đưa ra sự thực hiện của một thể hiện codec cụ thể được dùng

để chuyển đổi dữ liệu được truyền qua các kênh logic được mở và quản lý

bởi kênh điều khiển H323. Ứng dụng có thể tạo lớp dẫn xuất từ lớp này và

overide những hàm cần dùng.

o Hàm khởi tạo:

H323Codec(

const char * mediaFormat,

Direction direction );

o Mở codec:

virtual BOOL Open(H323Connection & connection );

o Đóng codec:

virtual void Close() = 0;

• Class H323AudioCodec:

Lớp này định nghĩa một lớp Codec sẽ sử dụng cho các thiết bị đầu ra

theo chuẩn PCM.

o Tạo mới một audio codec:

Hàm này tạo ra một codec ở các thiết bị âm thanh chuẩn PCM để mã

hóa và giải mã các tín hiệu đến, đi và cho phép các lớp dẫn xuất gởi tín hiệu

ra thiết bị audio I/0.

H323AudioCodec(

const char * mediaFormat,

Direction direction );

o Hủy một audio codec:

~H323AudioCodec();

• Class H323VideoCodec:

Lớp này định nghĩa một lớp Codec sẽ sử dụng cho các thiết bị đầu ra

Trần Thanh Long - Nguyễn Thành Nam

theo chuẩn hình ảnh.

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

o Tạo mới một video codec:

Hàm này tạo ra một codec ở các thiết bị hình ảnh chuẩn để mã hóa và

giải mã các tín hiệu đến, đi và cho phép các lớp dẫn xuất gởi tín hiệu ra thiết

bị video I/0.

H323VideoCodec(

const char * mediaFormat,

Direction direction );

o Hủy một video codec:

~H323VideoCodec();

3.3. Phương thức hoạt động:

Đối tượng cơ bản của sự phân cấp là lớp H323Endpoint. Mỗi ứng dụng

có một thể hiện con đặc trưng của lớp này. Ứng dụng định nghĩa thể hiện con

sẽ thiết lập các tham số H323 mặc định ( như Timeout, v. v… ), quan trọng

nhất là bảng khả năng định nghĩa kiểu mã hóa, giải mã và loại kênh mà ứng

dụng có thể sử dụng.

Một thể hiện con của lớp H323Endpoint cũng tạo ra một số thể hiện

con của lớp H323Listener. Mỗi giao thức được hỗ trợ bằng một thể hiện con

của lớp H323Listener này. Chẳng hạn như H323ListenerIP dùng cho Internet.

Mỗi Listener đưa ra một cách thức để giám sát giao thức của nó và tạo ra một

thể hiện của lớp H323Transport khi phát hiện ra một cuôc gọi mới đến. Đối

với mỗi nghi thức hỗ trợ, lớp H323Transport cũng có một lớp dẫn xuất tương

ứng với lớp H323Listener, chẳng hạn như lớp H323TransportIP tương ứng

Trần Thanh Long - Nguyễn Thành Nam

với H323ListenerIP.

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

Sơ đồ lớp Booch của hệ thống:

Khi PDU đầu tiên đến, trên lớp H323Transport sử dụng giao thức

Q.931 và H.225 và một tham chiếu cuộc gọi được thành lập để nhận dạng kết

nối. Các kết nối này để biểu hiện bởi lớp H323Connection. Lớp

H323Connection chứa tất cả thông tin trạng thái của một kết nối giữa các

H323Endpoint. Thể hiện H323Endpoint theo dõi những kết nối đang hoạt

động này. Nếu không có kết nối nào cho số tham chiếu cuộc gọi đã thành lập,

thì một kết nối mới được tạo và quá trình trao đổi báo hiệu H323 bắt đầu.

Trong một ứng dụng, hệ thống tự tạo ra một thể hiện của lớp dẫn xuất

từ lớp H323Connection thay vì chính lớp này tạo ra. Điều này dẫn đến một số

lớn các phương thức ảo có thể bị chồng lấp. Các phương thức ảo này là

những hàm thư viện “callback” cho phép ứng dụng có được thông tin trao đổi

nghi thức hoặc điều chỉnh cách thức trao đổi giao thức.

Trạng thái và chức năng của mỗi lệnh được duy trì bởi các lớp

Trần Thanh Long - Nguyễn Thành Nam

H323Negotiator hoặc các biến chuỗi được định nghĩa H.245. Thật ra, lý do

Nghiên cứu và xây dựng chương trình truyền thông đa phương tiện chính cho sự tồn tại của chúng là để giảm bớt phạm vi của các file H255.h và

H245.h được định nghĩa bởi hàng trăm lớp. Một người dùng của lớp

H323Connection do đó không phải include tất cả các Class này trên mỗi phần

biên dịch.

Trong thời gian trao đổi H.245, các kênh logic có thể được tạo ra, vừa

bởi Endpoint từ xa, vừa bởi ứng dụng trong hệ thống. Lớp dẫn xuất từ lớp

H323Channel sẽ thực hiện điều này. Một ứng dụng tiêu biểu của những lớp

này là để mở dòng dữ liệu âm thanh được mã hóa. Lớp H323Channel sẽ dùng

các thông tin lưu trong H323Capability để tạo ra các H323Codec và các

Trần Thanh Long - Nguyễn Thành Nam

codec này sẽ được chuyển trong quá trình trao đổi giao thức.

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

CHƯƠNG 6: XÂY DỰNG ỨNG DỤNG TRUYỀN THÔNG ĐA

PHƯƠNG TIỆN THỂ NGHIỆM

1. Mô hình thực tế:

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

Trong đề tài này, chúng em không có tham vọng sẽ xây dựng nên một

ứng dụng hoàn chỉnh, hoạt động tốt như trong thực tế mà chỉ xây dựng một

ứng dụng để mô phỏng cho những gì nghiên cứu được về các chuẩn mã hóa /

giải mã, các chuẩn hỗ trợ truyền âm thanh, hình ảnh thời gian thực trong

mạng truyền thông đa phương tiện theo kiểu VoIP.

2. Xác định các yêu cầu:

2.1. Các yêu cầu chức năng:

Các chức năng của Client:

• Đăng ký là thành viên của hệ thống.

• Đăng nhập, xác định tình trạng của mình trong hệ thống.

Trần Thanh Long - Nguyễn Thành Nam

• Thay đổi thông tin của user.

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

• Nhắn tin nhắn ngắn với các client khác trong cùng hệ thống.

• Thực hiện hội thoại thông điệp với các client khác trong cùng hệ

thống (hỗ trợ cho cả di động tham gia thông qua nhắn SMS).

• Nhắn sms đến cho di động.

• Thực hiện một voice call đến một user khác đang online trên mạng

(cho máy di động (hoặc máy để bàn) nếu user hiện không online).

• Thực hiện một cuộc hội thoại thoại với các user khác trên mạng (hỗ

trợ cho cả di động hay điện thoại bàn tham gia).

• Thực hiện một cuộc gọi cho di động hay điện thoại bàn.

• Nhận thông tin từ các kênh video được phát trên mạng và phát lại.

• Thực hiện hội thoại video giữa hai hay nhiều người dùng.

• Cho phép gởi mail đến người user khác.

Các chức năng của Server:

• Quản lý các thông tin user, quản lý địa chỉ của các gateway (SMS

gateway, PSTN gateway, MCU v.v…).

• Xác thực người dùng và xác nhận trình trạng người dùng.

• Tiếp nhận và xử lý các yêu cầu do client gởi đến như tình trạng kết

nối hiện thời của client, địa chỉ IP của user, thông tin về số điện

thoại để bàn, số di động của user.

• Lưu giữ các tin nhắn offline (text, voice) của user, các thông báo

của các user khác gởi đến và phát lại khi user login.

• Quản lý các user hiện đang online trong hệ thống, quản lý các cuộc

hội thoại đang diễn ra trong hệ thống.

2.2. Các yêu cầu phi chức năng:

• Chương trình có thể hoạt động tốt trên mọi hệ điều hành của

Microsoft.

• Có giao diện thân thiện, dễ sử dụng, dễ dàng thay đổi các thông số

Trần Thanh Long - Nguyễn Thành Nam

cấu hình 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

• Thiết kế chương trình có tính mở cao để có thể nâng cấp dễ dàng.

Điều này rất quan trọng vì đây là yếu tố quyết định khả năng phát

triển đề tài theo những hướng phát triển đề xuất.

: Giao tiếp theo giao thức do chúng ta đề ra cho server

: Giao tiếp theo giao thức H323

: Giao tiếp theo giao thức POP3

: Giao tiếp theo giao thức đề ra cho trạm phát công

Trần Thanh Long - Nguyễn Thành Nam

2.3. Mô hình giao tiếp giữa các thành phần trong 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 3.

Đặc tả chung cho hệ thống và sơ đồ khối của các yêu cầu:

3.1. Đặc tả chung cho hệ thống:

Hệ thống được xây dựng thành hai module: module Server và module

Client. Module Server được xây dựng theo mô hình song song hướng kết nối

(Concurrent, Connection-Oriented).

Module Server:

Module Server gồm hai phần: phần dịch vụ (service) chạy nền bên

dưới và phần ứng dụng (giao diện đồ họa) chạy bên trên để cấu hình hệ thống

cho service hoạt động đồng thời thực thi một số chức năng của Server như:

Quản lý hội thoại (Conference Management), v.v…

Khi service được khởi động (Start), một tiểu trình chính được khởi tạo

chịu trách nhiệm mở kho dữ liệu (database) dùng cho chương trình, đọc file

chứa các thông số khởi tạo cho service hoạt động (như địa chỉ IP của các

Gateway sử dụng trong hệ thống, v.v…), đồng thời thiết lập hai tiểu trình

con, một tiểu trình chịu trách nhiệm lắng nghe và phục vụ cho các yêu cầu

của user thông thường và tiểu trình còn lại chịu trách nhiệm lắng nghe và

phục vụ cho các yêu cầu của user admin. Tiểu trình chính này chỉ kết thúc khi

service kết thúc hoạt động (stop).

Tiểu trình phục vụ cho các yêu cầu của client lắng nghe trên cổng dịch

vụ 45000. Mỗi khi có một yêu cầu gởi đến từ phía client, tiểu trình này xác

định loại của yêu cầu (yêu cầu đăng nhập hay thoát khỏi hệ thống v.v…), sau

đó tạo ra một tiểu trình tương ứng với yêu cầu vừa xác định được và truyền

cho tiểu trình các thông tin cần thiết (socket gởi nhận dữ liệu) để tiếp tục

phục vụ cho client.

Trong các tiểu trình con được tạo ra bởi tiểu trình phục vụ client, mọi

thông tin liên quan đến yêu cầu được client gởi đến và tiểu trình sử dụng các

thông tin này để xử lý (truy vấn dữ liệu, v.v… ) và gởi trả các kết quả xử lý

được về cho client. Sau khi một yêu cầu từ client được đáp ứng hoàn tất, tiểu

Trần Thanh Long - Nguyễn Thành Nam

trình sẽ được hủy.

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

Tiểu trình phục vụ cho các yêu cầu của server (phần giao diện dùng để

cấu hình service và quản lý hệ thống) lắng nghe trên cổng dịch vụ 40000.

Cũng tương tự như tiểu trình phục vụ client, mỗi khi có một yêu cầu nào từ

server gởi đến, tiểu trình này tạo ra một tiểu trình con tương ứng để phục vụ

cho yêu cầu đó và kết thúc tiểu trình khi yêu cầu được thực hiện xong.

Cả hai tiểu trình phục vụ cho client và tiểu trình phục vụ cho server

đều kết thúc khi service kết thúc hoạt động.

Module Client:

Các thành viên trong hệ thống sử dụng account của mình để đăng nhập

vào hệ thống, sau khi đăng nhập thành công, các thành viên có thể sử dụng

các dịch vụ được ứng dụng client hỗ trợ. Khi đăng nhập thành công, ứng

dụng client cũng tạo ra một tiểu trình để lắng nghe mọi thông báo hoặc yêu

cầu gởi về từ server như có yêu cầu trò chuyện từ một client khác đang

“online” trong hệ thống, v.v… Tiểu trình này hoạt động trên cổng dịch vụ

43000. Tiểu trình chính này chỉ kết thúc khi người dùng thoát khỏi hệ thống.

Khi tiểu trình này nhận được một yêu cầu hoặc thông báo từ service gởi về,

nó sẽ tạo ra một tiểu trình tương ứng với thông báo hoặc yêu cầu đó để thông

báo cho client biết và đáp lại thông báo, yêu cầu này.

3.2. Sơ đồ khối của một vài chức năng của client:

Tất cả các giao tiếp giữa client và server đều theo nguyên tắc sau:

Client gởi yêu cầu cho server (ví dụ như “LOGIN”) và client chờ

server gởi trả thông điệp báo nhận cho yêu cầu này (ví dụ như

“LOGINACK”). Khi nhận được thông điệp báo nhận từ server, client gởi lại

thông điệp báo nhận cho server (ví dụ như “LOGINACK) và quá trình trao

đổi thông tin giữa client và server bắt đầu.

Trong quá trình trao đổi giữa client và server, nếu có lỗi xảy ra từ phía

server, server sẽ gởi một thông điệp báo lỗi cho client biết để kết thúc quá

Trần Thanh Long - Nguyễn Thành Nam

trình trao đổi (ví dụ như “LOGINER”). Có nhiều loại lỗi xảy ra trong quá

Nghiên cứu và xây dựng chương trình truyền thông đa phương tiện trình trao đổi và tùy vào thông điệp báo lỗi được gởi về mà client biết để xử

lý hoặc thông báo cho người sử dụng biết.

a. Chức năng đăng nhập, xác định tình trạng hiện thời của user trong hệ

Client

Đăng nhập

Thông tin các user liên quan

Các thông tin về user đăng nhập

thống:

Đăng nhập lại

Xác thực user

Module xử lý của Server

Đặc tả: Client gởi các thông tin về account của mình cho module xử lý

của service để xác thực. Nếu xác thực đúng, module xử lý của service sẽ gởi

trả về cho client các thông tin liên quan đến account của client như danh sách

các thành viên có trong contact list của user, các thông báo của các user khác

gởi đến, các offline message của các client này.

Trong trường hợp xác thực không đúng, module xử lý của service sẽ

gởi về các thông điệp lỗi tương ứng với từng lỗi như không đúng password

hay user này không tồn tại trong hệ thống, v.v…

b. Thay đổi thông tin của user:

Đặc tả: Trong trường hợp client muốn thay đổi các thông tin liên quan,

client gởi các thông tin thay đổi đến cho module xử lý của service . Module

xử lý của service sẽ cập nhật lại các thông tin này trong cơ sở dữ liệu, nếu cập

nhật thành công, module xử lý của service sẽ báo cho client biết đã thay đổi,

nếu thay đổi không thành công, module xử lý của service báo cho client biết

Trần Thanh Long - Nguyễn Thành Nam

có lỗi xảy ra và client thoát khỏi .

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

Client

Xem thông tin về user

Save ?

Thay đổi các thông tin

Thoát khỏi thông tin user

Cập nhật thông tin về user

Module xử lý của Server

Save OK?

Đ S

Client 2

Các dòng message

Client 1

Module xử lý của Server

Yêu cầu Server cho biết IP của Client 2

c. Nhắn tin ngắn với các user khác trong cùng hệ thống:

Online ?

IP của Client 2

Các dòng message

S lưu lại message của C1 nhắn cho C2

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

Đặc tả: Khi một client 1 (C1) muốn trò chuyện với một client 2 (C2)

trên mạng, C1 sẽ yêu cầu module xử lý của service thiết lập cuộc trò truyện,

tiểu trình phục vụ client sẽ tiếp nhận yêu cầu và tạo ra tiểu trình con phục vụ

riêng cho yêu cầu này, trong tiểu trình con này, module xử lý của service sẽ

tính toán cổng dịch vụ thực hiện cuộc trò truyền dựa vào id của C2 so với C1

trong cơ sở dữ liệu. Từ đó module xử lý của service (tiểu trình con) sẽ gởi vể

cho mỗi client cổng dịch vụ và địa chỉ IP của client còn lại. Mỗi client sẽ thiết

lập socket để gởi và nhận các message.

Trong trường hợp C2 offline, module xử lý của service sẽ gởi thông

báo cho C1 biết và tạo tiểu trình con để lưu các tin nhắn offline của C1 gởi

cho C2.

d. Thực hiện hội nghị thông điệp với các client khác trong cùng hệ thống

Client 2

Thông điệp

Client 1

Module xử lý của server

Yêu cầu thiết lập một hội thoại thông điệp

(hỗ trợ cho cả di động tham gia thông qua nhắn SMS)

Set up OK?

Thông điệp

Thông báo thiết lập thành công

SMS gateway

Thông điệp

Thông báo thiết lập không thành công

Di động

Đặc tả: Cũng giống yêu cầu trò truyện, yêu cầu thực hiện hội nghị

thông điệp được gởi đến cho module xử lý của service từ client yêu cầu,

Trần Thanh Long - Nguyễn Thành Nam

module xử lý của service tạo tiểu trình tiếp nhận danh sách các client tham

Nghiên cứu và xây dựng chương trình truyền thông đa phương tiện gia trong cuộc hội nghị. Sau khi nhận hết toàn bộ danh sách các client được

mời tham gia hội nghị, module xử lý của service tạo ra một group mới, tính

toán cổng dịch vụ, địa chỉ multicast và gởi các thông tin này về cho client yêu

cầu, đồng thời gởi thông báo mời tham gia hội nghị đến cho tất cả các user

còn lại trong group. Nếu thiết lập cuộc hội nghị không thành công, module xử

lý của service sẽ gởi thông báo lỗi về cho client yêu cầu biết.

Trong trường hợp thành công và các client được mời đều đã được

thông báo, nếu client nào chấp nhận tham gia hội nghị thì module xử lý của

service gởi về cho client này cổng dịch vụ, địa chỉ multicast sử dụng để trao

đổi thông điệp và danh sách các client hiện đã tham gia vào hội nghị. Khi một

client nhận được thông tin về cổng dịch vụ và địa chỉ ip, nó lập tức phát một

thông điệp “LOGIN” cho toàn bộ client đã tham gia hội nghị biết.

Đối với các client không online sẽ tham gia hội nghị này bằng di động

thông qua SMS Gateway.

Message

SMS gateway

Di động

e. Nhắn sms cho di động:

SMS Gateway IP

Client 1

Module xử lý của Server

SMS Gateway IP ?

Đặc tả: Để gởi tin nhắn đến cho di động, client yêu cầu module xử lý

của service cho biết địa chỉ của SMS Gateway, khi nhận được địa chỉ của

SMS Gateway, client gởi các dòng message đến cho SMS Gateway theo định

Trần Thanh Long - Nguyễn Thành Nam

dạng mà SMS Gateway có thể hiểu được.

Nghiên cứu và xây dựng chương trình truyền thông đa phương tiện f. Thực hiện một voice call đến một client khác đang online trên mạng

Client 2

Các dòng âm thanh gởi đi

Client 1

Module xử lý của Server

Yêu cầu Server cho biết IP của Client 2

(gọi ra máy di động (hoặc máy để bàn) nếu client không online)

Online ?

IP của Client 2

PSTN gateway

(cid:131) Số điện thoại di động hoặc điện thoại để bàn (cid:131) IP của PSTN

Di động

Máy để bàn

gateway

Đặc tả: Client 1 (C1) yêu cầu module xử lý của service cho biết địa chỉ

của Client 2 (C2) để thực hiện một cuộc gọi đến C2. Nếu C2 đang online trên

mạng, module xử lý của service sẽ gởi về cho C1 địa chỉ IP của C2, C1 sử

dụng địa chỉ IP này để thiết lập một cuộc gọi qua mạng H.323 đến C2.

Trong trường hợp C2 không online trên mạng, module xử lý của

service sẽ gởi trả về cho C1 các thông tin: số điện thoại di động hoặc điện

thoại bàn của C2, địa chỉ của máy tính đóng vai trò là PSTN Gateway. Sau

Trần Thanh Long - Nguyễn Thành Nam

khi nhận được các thông tin này, C1 thiết lập cuộc gọi ra PSTN cho C2.

Nghiên cứu và xây dựng chương trình truyền thông đa phương tiện g. Thực hiện một cuộc hội nghị thoại với các user khác đang online trên

mạng (hỗ trợ cho các user không online tham gia hội nghị bằng di

Client 2

Thông điệp thoại

Client 1

Multipoint Control Unit

Yêu cầu thiết lập một cuộc hội nghị thoại

động hoặc điện thoại bàn)

Set up OK?

Thông điệp thoại

Thông báo thiết lập thành công

Thông điệp thoại

Thông báo thiết lập không thành công

Di động

Máy để bàn

PSTN

Đặc tả: Đây là tính năng kèm theo khi tổ chức hội nghị thông điệp. Khi

một client trong danh sách tham gia hội nghị yêu cầu hội nghị thoại, yêu cầu

này được gởi đến module xử lý của service và client này sẽ nhận được địa chỉ

IP của MCU trong hệ thống. Đồng thời chính client yêu cầu sẽ phát thông

điệp yêu cầu hội nghị thoại đến toàn thể client đang tham gia hội nghi. Khi

nhận được thông điệp này, nếu chấp nhận, các client sẽ gởi thông điệp yêu

cầu cho biết địa chỉ của MCU đến cho module xử lý của service. Module xử

lý của service sẽ gởi trả lời cho client biết địa chỉ IP của MCU.

Đối với những client đã biết được địa chỉ IP của MCU, client này sẽ

thiết lập cuộc gọi đến MCU theo địa chỉ thiết lập có dạng như sau: [room +

id@ địa chỉ của MCU] (ví dụ: room1@192.168.0.1 với 1 là số id của cuộc

hội nghị được quản lý bởi module xử lý của service và 192.168.0.1 là địa chỉ

Trần Thanh Long - Nguyễn Thành Nam

IP của MCU trong hệ thống). Tất cả các client trong cùng một cuộc hội nghị

Nghiên cứu và xây dựng chương trình truyền thông đa phương tiện sẽ có cùng một id, do đó, khi thực hiện cuộc gọi với địa chỉ được gọi theo

định dạng trên thì toàn thể các client đều tham gia vào cung một group do

MCU quản lý, từ đây, MCU sẽ nhận các luồng âm thanh và phát lại cho các

client khác trong group.

Khi tất cả các client đều thoát khỏi cuộc hội nghị, MCU sẽ tự xóa

group này đi.

PSTN gateway

Client 1

Tín hiệu thoại

Máy để bàn

Di động

PSTN Gateway IP

h. Thực hiện một cuộc gọi ra PSTN:

PSTN Gateway IP ?

Module xử lý của Server

Đặc tả: Để thực hiện một cuộc gọi ra PSTN, client yêu cầu module xử

lý của service cho biết địa chỉ IP của máy đang đóng vai trò là PSTN

Gateway trong hệ thống. Module xử lý của service sẽ gởi về cho client địa

chỉ của PSTN Gateway trong hệ thống. Client sẽ thực hiện cuộc gọi theo nghi

thức H.323 với địa chỉ đích có định dạng như sau: số điện thoại cần gọi @ địa

chỉ của PSTN Gateway (ví dụ như 1234@192.168.0.1). Sau khi thiết lập

thành công, tín hiệu thoại sẽ được client gởi đến cho PSTN Gateway và từ

Trần Thanh Long - Nguyễn Thành Nam

PSTN Gateway sẽ chuyển cho máy di động hoặc máy để bàn.

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

Thiết kế cơ sở dữ liệu: Dữ liệu của chương trình chỉ bao gồm các dữ liệu để quản lý user. Một

user gồm có các thông tin cần quản lý như sau: họ tên của user, tên tài khoản,

mật mã của tài khoản, địa chỉ email của user, số điện thoại để bàn, số điện

thoại di động của user.

Ngoài ra, khi một user sử dụng tài khoản của mình đăng nhập trong hệ

thống còn có thêm các thông tin về địa chỉ IP của máy mà user đang sử dụng

để đăng nhập vào hệ thống, tình trạng của user trong hệ thống, tên các tập tin

lưu trữ thông tin offline như message offline, voice, các thông báo của các

user khác và danh sách các user có trong contact list của user.

Dữ liệu được tổ chức thành hai bảng, một bảng dùng để lưu thông tin

của user và một bảng dùng để lưu danh sách contact list tương ứng với từng

user.

4.1. Các trường của bảng lưu thông tin user như sau:

Kiểu Mô tả

String String String String String Thuộc tính AccountName Password UserName Status IPAddress

Number Number String String Mobile Phone Email Voice

String Text

String Notify

100

Trần Thanh Long - Nguyễn Thành Nam

Tên user sử dụng để đăng nhập Mật mã dùng với tên đăng nhập trên Tên đầy đủ của user Tình trạng của user trong hệ thống Địa chỉ của máy mà user sử dụng để đăng nhập vào hệ thống Số điện thoại di động của user Số điện thoại cố định của user Địa chỉ email của user Tên tập tin lưu các dòng âm thanh được gửi offline Tên tập tin lưu các message offline của các user khác nhắn lại Tên tập tin lưu các thông báo offline của các user khác gởi đên

Nghiên cứu và xây dựng chương trình truyền thông đa phương tiện 4.2. Các trường của bảng lưu thông tin danh sách các user trong

contact list:

Thuộc tính Kiểu

ID AutoNumber

AccountName String

GroupName FriendName String String

ContactName String list ứng với trong contact

Mô tả Số thứ tự tăng tự động khi thêm một trường mới vào dùng để phân biệt các trường với nhau. Tên của account quản lý contact list này Tên của từng group trong contact list Tên của user trong contact list (cũng là tên đăng nhập) Tên FriendName trên

Lưu ý: Trường AccountName trong bảng này được tham chiếu đến

trương AccountName trong bảng thông tin user.

Thiết kế giao diện:

5. • Giao diện cấu hình: Sử dụng để cấu hình lại địa chỉ IP của các gateway

đang hoạt động trong hệ thống. Màn hình này được sử dụng để cấu hình

101

Trần Thanh Long - Nguyễn Thành Nam

lại địa chỉ các Gateway đang chạy trong 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

• Giao diện login vào hệ thống với vai trò admin: Chỉ có duy nhất user

admin mới có quyền truy cập vào hệ thống bằng chương trình này.

• Giao diện chính của module server : Giao diện chính thể hiện thông tin

của user đang được chọn và danh sách toàn bộ user trong hệ thống.

• Giao diện quản lý các cuộc hội nghị: Quản lý các cuộc hội nghị hiện đang

diễn ra trong hệ thống: Trên giao diện này, người quản trị có thể xem

được hiện thời có bao nhiêu cuộc hội nghị đang diễn ra trong hệ thống.

Khi chọn vào một cuộc hội nghị, bên dưới sẽ xuất hiện các thông tin chi

102

Trần Thanh Long - Nguyễn Thành Nam

tiết về các thành viên tham gia trong hội nghị.

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

• Màn hình cấu hình lại địa chỉ IP của server phục vụ cho hệ thống.

103

Trần Thanh Long - Nguyễn Thành Nam

• Màn hình login vào hệ thống tại ứng dụng client:

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

• Giao diện của chính của ứng dụng Client: Trong cửa sổ thể hiện toàn bộ

danh sách các user nằm trong contact list của một user dưới dạng cây.

104

Trần Thanh Long - Nguyễn Thành Nam

• Màn hình đăng ký là một thành viên của 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

• Màn hình cho biết các thông tin của user và cho phép thay đổi các thông

tin này. Tất cả các thông tin đều có thể được sửa đổi được ngoại trừ thông

tin liên quan đến AccountName là không có thể thay đổi.

• Màn hình gởi tin nhắn cho các client khác trong hệ thống. Có thể có nhiều

thể hiện của màn hình này nếu client đang trò truyện với nhiều thành viên

105

Trần Thanh Long - Nguyễn Thành Nam

khác trong 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

• Màn hình gởi sms đến di động:

• Màn hình đưa ra các tin nhắn offline của các thành viên khác nhắn đến lúc

user đang offline. Những tin nhắn nào chưa được xem qua sẽ được tô xanh

lên. Khi xem xong, trong những lần sau thì tin nhắn này không được tô

đậm lên mà chỉ hiện bình thường. Đây là cách thức chương trình phân biệt

106

Trần Thanh Long - Nguyễn Thành Nam

giữa tin nhắn offline mới (chưa xem) với các tin nhắn cũ (đã xem rồi).

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

• Màn hình thêm một user mới vào trong danh sách contact list.

• Màn hình thông báo cho một user khi có một user khác add chính user này

vào trong danh sách contact list. Trong màn hình này, group được thể hiện

dưới dạng combo box để người dùng có nhiều lựa chọn cho group mà user

này sẽ ở trong contact list. Trong trường hợp trong contact list của user đã

107

Trần Thanh Long - Nguyễn Thành Nam

tồn tại user add thì không có thông báo này.

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

• Màn hình mời các client đang online trên mạng tham gia vào hội thoại

108

Trần Thanh Long - Nguyễn Thành Nam

• Màn hình thông báo cho user khi được mời tham gia vào hội nghị.

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

• Màn hình hội nghị thông điệp có cho phép sử dụng kèm hội nghị thoại

• Màn hình gọi điện thoại ra ngoài hệ thống PSTN cho số máy để bàn hoặc

109

Trần Thanh Long - Nguyễn Thành Nam

số di động

Cách thực thi 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 6. • Khởi động Service để service chạy nền, phục vụ cho hệ thống. Tiếp đến,

service như địa chỉ IP của các Gateway, các Server trong hệ thống.

o Chuyển đến thư mục chứa tập tin thực thi của MIService, thực thi lệnh

sau để chạy service dưới dạng dịch vụ:

MIService –Service

Sau khi thực thi xong lênh trên, chuyển vào trình quản lý các service của hệ

thống, tim service có tên MIService và cho bắt đầu thực thi. Để dịch vụ này

có thể tự động chạy lúc hệ điều hành khởi động, xét kiểu khởi động (Startup

110

Trần Thanh Long - Nguyễn Thành Nam

Type) cho dịch vụ này là Automatic:

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

• Sau khi service đã chạy và đã cấu hình, các client có thể sử dụng chương

trình client để log vào hệ thống.

Cài đặt chương trình: Chương trình được cài đặt hoàn toàn bằng ngôn ngữ C++ trên môi

trường phát triển VC 6.0.

Thư viện hàm sử dụng thêm:

OpenH323: Download miễn phí trên trang www.OpenH323.org.

Đánh giá kết quả xây dựng ứng dụng: Trong thời gian nghiên cứu và xây dựng chương trình, nhóm đã xây

dựng được cơ bản một số các chức năng cần thiết trong hệ thống, xây dựng

hoàn chỉnh server (gồm cả service) phục vụ cho hệ thống và client.

Xây dựng tốt các chức năng quản lý hệ thống như đăng nhập, xác thực

người dùng, quản lý tình trạng của người dùng, tạo mới một thành viên trong

111

Trần Thanh Long - Nguyễn Thành Nam

hệ thống v.v…

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

Xây dựng hoàn chỉnh các ứng dụng về nhắn tin ngắn trong hệ thống

(instance message và text message conference).

Xây dựng hoàn chỉnh khả năng tương tác thoại giữa các thành viên

trong hệ thống như tạo cuộc gọi giữa hai thành viên đang online trong hệ

thống, gọi điện thoại cho di động hoặc máy để bàn thông qua sử dụng PSTN

Gateway. Tín hiệu thoại được nén theo chuẩn nén âm thanh G.711.

Nhóm đang cố gắng hoàn thành chức năng nhắn SMS cho điện thoại di

động thông qua sử dụng server là SMS Server v.3.1.7 được cung cấp trên

trang www.smsdriver.com nhưng vẫn còn một vài trục trặc nên chức năng

này hiện đang disable.

Chương trình hoạt động tốt trên môi trường mạng. Có thể triển khai

ngay để sử dụng trong thực tế.

Xây dựng được mô hình có tính mở cao, dễ dàng phát triển thêm để

hoàn chỉnh các mong muốn đề ra.

Tuy nhiên, với thời gian nghiên cứu ngắn nên nhóm cũng chưa cài đặt

các chức năng liên quan đến hình ảnh như trạm phát công, hội nghị truyền

hình là những chức năng nâng cao trong hệ thống. Đây là hướng phát triển

của hệ thống trong tương lai.

9. Hướng phát triển chương trình:

• Nghiên cứu cải tiến chất lượng của dịch vụ truyền thông đa phương

tiện.

• Phát triển chương trình, hỗ trợ thêm những chuẩn nén âm thanh có

tốc độ nhỏ hơn như G.723, G.729.

• Tích hợp thêm chức năng máy tự trả lời tự động để có thể nhận các

cuộc gọi gọi đến và lưu lại. Hỗ trợ người dùng check các cuộc gọi

này bằng cách đăng nhập hệ thống hoặc thông qua PSTN.

• Phát triển hội nghị truyền hình, hội nghị dữ liệu để tổ chức những

112

Trần Thanh Long - Nguyễn Thành Nam

cuộc hội thảo trên môi trường liên mạng

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

• Phát triển hệ thống trạm phát công cộng, cho phép thu hình các

cuộc họp và nén thành dòng, phát trực tiếp hoặc phát lại theo yêu

cầu của thành viên trong hệ thống.

• Phát triển tính năng tự động thông báo đến điện thoại để bàn các tin

nhắn do các thành viên để lại. Thông báo khi nhận được mail mới

v.v…

• Nghiên cứu thêm về chất lượng dịch vụ của các dịch truyền thông

đa phương tiện khi thực hiện trên môi trường liên mạng và mạng

113

Trần Thanh Long - Nguyễn Thành Nam

internet.

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

TỔNG KẾT

Với sự phát triển xã hội hiện nay, các sản phẩm truyền thông đa

phương tiện trực tuyến ngày càng được xã hội quan tâm hơn. Vấn đề phát

triển và cải thiện chất lượng dịch vụ của các sản phẩm truyền thông đa

phương tiện trực tuyến ngày càng được đặt nặng hơn buộc các nhà phát triển

phải luôn phải quan tâm đến việc cải thiện chất lượng dịch vụ cho sản phẩm

của mình.

Với những gì đã đạt nghiên cứu và trình bày trong luận văn này chưa

phải là hoàn chỉnh nhưng chúng em mong muốn những kết quả nghiên cứu

về lĩnh vực truyền thông đa phương tiện được trình bày trong này sẽ giúp

được cho các nhà phát triển sau này.

Chúng em mong muốn sẽ tiếp tục phát triển tiếp hệ thống này để sản

phẩm ngày một tốt hơn, đáp ứng được yêu cầu của xã hội.

Chúng em xin cảm ơn Thạc sĩ Huỳnh Văn Gia đã hướng dẫn chúng em

thực hiện đề tài này. Cám ơn toàn thể bạn bè đã giúp đỡ trong quá trình thực

hiện luận văn.

Thành phố Hồ Chí Minh, 7 – 2003

114

Trần Thanh Long - Nguyễn Thành Nam

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

BẢNG THAM CHIẾU CÁC TỪ VIẾT TẮT

Admission Confirmation ACF

Acknowledgment ACK

Admission Reject ARJ

Address Resolution Protocol ARP

Admission Request ARQ

ARPA Advanced Research Projects Agency

Asynchronous Transfer Mode ATM

Bandwidth Change Confirmation BCF

Bose, Chaudhuri, and Hocquengham BCH

B-ISDN Broadband-Integrated Services Digital Network

Bandwidth Change Reject BRJ

Badwidth Change Request BRQ

Chanel Associated Signalling CAS

Common Chanel Signalling CCS

Conference Identifier CID

Common Intermediate Dormat CIF

Domain name Server DNS

DTMF Dual-Tone MultiFrequency

Full Intra Request FIR

File Transfer Protocol FTP

Gatekeeper GK

General Switched Telephone Network GSTN

Gateway GW

Internet Control Message Protocol ICMP

Institute of Electrical and Electronic Engineers IEEE

Internet Protocol IP

115

Trần Thanh Long - Nguyễn Thành Nam

Integrated Services Digital Network ISDN

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

International Standard Organization

ISP Internet Service Point

International telecommunication Union – Telecommunication ITU-T

Standardixation Sector

LAN Local Area Network

LCN Logical Channel Number

MC Multipoint Controller

NCU Multipoint Control Unit

MGCP Media Gateway Control Protocol

MP Multipoint Processor

MTP Message Transfer Part

NACK Negative Acknowledge

N-ISDN Narrow-band-Intgrated Services Digital Network

OSI Open System Interconnection

PBN Packet Based Network

PBX Privatee Branch Exchange

PDU Packet Data Unit

POTS Plain Old Telephone Service

PPP Point-To-Point Protocol

PSTN Public Switched Telephone Network

QCIF Quarter CIF

QOS Quality Of Service

RAS Registration, Admission, and Status

RIP Request In Progress

RIP Routing Internet Protocol.

RSVP Resource Reservation Protocol

RTP Real Time Protocol

RTCP Real Time Control Protocol

116

Trần Thanh Long - Nguyễn Thành Nam

SCCP Signalling Connection Control Part

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

Switched Circuit Network

Service Control Point SCP

Simple Gateway Control Protocol SGCP

Simple Mail Transfer Protocol SMTP

Simple Network Monitoring Protocol SNMP

SS No.7 Singalling System No.7

Service Switching Point SSP

Signal Transfer Point STP

Transport Control Protocol TCP

Telephone User Part TUP

User Datagram Protocol UDP

Voice Over IP VOIP

117

Trần Thanh Long - Nguyễn Thành Nam

Wide Area Network. WAN

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

TÀI LIỆU THAM KHẢO

RFC 1889.

RFC 1890.

ITU-T Recommendation H.323 Series H

ITU-T Recommendation H.245

ITU-T Recommendation H.225.0

ITU-T Recommendation H.323

ITU-T Recommendation H.261

ITU-T Recommendation G.723.1

ITU-T Recommendation G.729

ITU-T Recommendation G.711

SMSDriverHelpENG_Rel_3_1_11.pdf

H323 Premier V2.2

OpenH323 Library

www.OpenH323.org

www.smsdriver.com

118

Trần Thanh Long - Nguyễn Thành Nam

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

CHƯƠNG 0: GIỚI THIỆU................................................................................................4

CHƯƠNG 1: TÌM HIỂU CÁC CHUẨN NÉN ÂM THANH..........................................6

CHƯƠNG 2: TÌM HIỂU CÁC CHUẨN NÉN HÌNH ẢNH..........................................20

CHƯƠNG 3: TÌM HIỂU VỀ VOICE OVER IP............................................................28

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

CHƯƠNG 5: TÌM HIỂU CHUẨN H.323 VÀ THƯ VIỆN OPENH323 ......................56

CHƯƠNG 6: XÂY DỰNG ỨNG DỤNG TRUYỀN THÔNG ĐA PHƯƠNG TIỆN THỂ NGHIỆM ..................................................................................................................88

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

Nghiên cứu và xây dựng chương trình truyền thông đa phương tiện 2.3. Quy luật mã hoá:

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

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

Nghiên cứu và xây dựng chương trình truyền thông đa phương tiện 3.2. Những khác biệt giữa H.263 và H.261:

Nghiên cứu và xây dựng chương trình truyền thông đa phương tiện 2.2. Đơn giản hóa:

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

- NotificationRequest: yêu cầu Gateway phát hiện các tín hiệu nhấc

- Notify: Gateway sử dụng lệnh này để báo ngược về Call Agent các

- CreateConnection: Call Agent yêu cầu tạo kết nối giữa cá đầu cuối

- ModifyConnection: Call Agent dùng lệnh này để thay đổi các

- Deleteconnection: Call Agent và Gateway dùng lệnh này để giải

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

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

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

(cid:11)

Nghiên cứu và xây dựng chương trình truyền thông đa phương tiện 2.3.1. Video Codec:

Nghiên cứu và xây dựng chương trình truyền thông đa phương tiện 2.4.3. Chức năng báo hiệu cuộc gọi H.225.0:

Nghiên cứu và xây dựng chương trình truyền thông đa phương tiện 2.7. Mối quan hệ giữa nghi thức H323 và mô hình OSI:

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

Nghiên cứu và xây dựng chương trình truyền thông đa phương tiện 3.2.2. Ý nghĩa một số lớp trong thư viện:

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

Di động

Nghiên cứu và xây dựng chương trình truyền thông đa phương tiện f. Thực hiện một voice call đến một client khác đang online trên mạng

Nghiên cứu và xây dựng chương trình truyền thông đa phương tiện g. Thực hiện một cuộc hội nghị thoại với các user khác đang online trên

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

Nghiên cứu và xây dựng chương trình truyền thông đa phương tiện 4.2. Các trường của bảng lưu thông tin danh sách các user trong

Nghiên cứu và xây dựng chương trình truyền thông đa phương tiện 6. • Khởi động Service để service chạy nền, phục vụ cho hệ thống. Tiếp đến,

Có thể bạn quan tâm

Tài liêu mới

AI tóm tắt

Giới thiệu tài liệu

Đối tượng sử dụng

Từ khoá chính

Nội dung tóm tắt

Giới thiệu

Về chúng tôi

Việc làm

Quảng cáo

Liên hệ

Chính sách

Thoả thuận sử dụng

Chính sách bảo mật

Chính sách hoàn tiền

DMCA

Hỗ trợ

Hướng dẫn sử dụng

Đăng ký tài khoản VIP

093 303 0098

support@tailieu.vn

Phương thức thanh toán

Theo dõi chúng tôi

Facebook

Youtube

TikTok