Giải pháp mở rộng hệ thống VOIP với giao thức SIP và các phần mềm mã nguồn mở cho hạ tầng nghiệp vụ ngành thuế

Tiến hành kiểm thử theo các bước đã đề xuất trong giải pháp đã phân tích, tôi rút ra được một số kết quả như sau: - Hệ thống được mở rộng và đáp ứng tốt các yêu cầu của công việc bao gồm

CHO HẠ TẦNG NGHIỆP VỤ NGÀNH THUẾ

LUẬN VĂN THẠC SĨ: CÔNG NGHỆ THÔNG TIN

Hà Nội - 2015

CHO HẠ TẦNG NGHIỆP VỤ NGÀNH THUẾ

Ngành: Công nghệ thông tin

Chuyên ngành: Truyền dữ liệu và mạng máy tính

Mã số:

LUẬN VĂN THẠC SĨ: CÔNG NGHỆ THÔNG TIN

NGƯỜI HƯỚNG DẪN KHOA HỌC: TS HOÀNG XUÂN TÙNG

Hà Nội - 2015

3

LỜI CAM ĐOAN

Tôi xin cam đoan kết quả đạt được trong luận văn là sản phẩm của riêng cá nhân tôi, không sao chép lại của người khác Trong toàn bộ nội dung của luận văn những điều được trình bày hoặc là của cá nhân hoặc là được tổng hợp từ nhiều nguồn tài liệu Tất cả các tài liệu tham khảo đều có xuất xứ rõ ràng và được trích dẫn hợp pháp

Tôi xin hoàn toàn chịu trách nhiệm và chịu mọi hình thức kỷ luật theo quy định cho lời cam đoan của mình

Hà Nội, ngày 26 tháng 03 năm 2015

Nguyễn Thanh Long

4

MỤC LỤC

DANH MỤC CÁC CHỮ VIẾT TẮT 6

DANH MỤC CÁC BẢNG 7

DANH MỤC HÌNH VẼ 7

LỜI CẢM ƠN 9

MỞ ĐẦU 10

CHƯƠNG 1 HIỆN TRẠNG MẠNG VOIP NGÀNH THUẾ 12

1.1 Mô hình kết nối mạng VoIP ngành Thuế 12

1.2 Hiện trạng sử dụng 13

1.3 Các vấn đề tồn tại 13

CHƯƠNG 2 CÁC GIẢI PHÁP THỰC HIỆN 14

2.1 Giải pháp nâng cấp hệ thống 14

2.2 Giải pháp mở rộng hệ thống bằng Opensource 14

2.3 Phân tích lựa chọn giải pháp 15

CHƯƠNG 3 CÔNG NGHỆ HỖ TRỢ 18

3.1 Giao thức báo hiệu 18

3.1.1 Giao thức SCCP 18

3.1.2 Giao thức báo hiệu H.323 21

3.1.3 Giao thức báo hiệu SIP 28

3.1.4 So sánh và lựa chọn giao thức báo hiệu 38

3.2 Phần mềm tổng đài thoại IP hỗ trợ SIP phổ biến 41

3.2.1 Asterisk 41

3.2.2 FreeSWITCH 43

3.3 Lựa chọn các công nghệ hỗ trợ triển khai 45

CHƯƠNG 4 TRIỂN KHAI VÀ ĐÁNH GIÁ 46

4.1 Triển khai giải pháp 46

4.2 Mô hình triển khai 46

4.3 Phần mềm và thông số máy chủ 47

4.3.1 Máy chủ tổng đài thoại (FusionPBX và FreePBX) 47

4.3.2 Máy chủ solarwinds 48

4.3.3 Phần mềm SIPp 50

5

4.4 Đánh giá hệ thống 51

4.4.1 Đánh giá năng lực hệ thống 51

4.4.2 Đánh giá chất lượng cuộc gọi 55

4.5 Thực hiện đánh giá chất lượng hỗ trợ 57

KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN 58

TÀI LIỆU THAM KHẢO 59

6

DANH MỤC CÁC CHỮ VIẾT TẮT

B2BUA Back-to-back user agent

CDR Call Detail Record

CMR Call Management Record

CNTT Công nghệ Thông tin

CUCM Cisco Unified Communications Manager MCU Multipoint Control Unit

MOS Mean Opinion Score

IVR Interactive Voice Response

PBX Private Branch Exchange

TCT Tổng cục Thuế

RTP Real-time Transport Protocol

SCCP Skinny Call Control Protocol

SDP Session Description Protocol

SIP Session Initiation Protocol

VoIP Voice over Internet Protocol

WAN Wide Area Network

7

DANH MỤC CÁC BẢNG

Bảng 2.1 Bảng ước lượng chi phí khi nâng cấp 16

Bảng 3.1 Các bản tin SCCP đăng ký phone 19

Bảng 3.2 Các bản tin SCCP kiểm tra trạng thái và cảnh báo 20

Bảng 3.3 Các bản tin SCCP khi nhấc điện thoại 20

Bảng 3.4 Các bản tin SCCP khi thực hiện cuộc gọi 21

Bảng 3.5 Các bản tin yêu cầu của SIP 30

Bảng 3.6 Tổng thể các bản tin đáp ứng của SIP 30

Bảng 3.7 Chi tiết các bản tin đáp ứng của SIP 31

Bảng 3.8 Các thành phần trong bản tin yêu cầu SIP 33

Bảng 3.9 Các thành phần trong bản tin đáp ứng SIP 33

Bảng 3.10.Bảng so sánh giao thức báo hiệu SIP và H.323 38

Bảng 4.1 Bảng thông số máy chủ tổng đài FreePBX 47

Bảng 4.2 Bảng thông số máy chủ tổng đài FusionPBX 48

Bảng 4.3 Bảng chất lượng cuộc gọi 49

Bảng 4.4 Bảng thông số máy chủ giám sát Solarwinds 49

Bảng 4.5 Bảng thông số máy chủ chạy SIPp 50

Bảng 4.6 Các tham số thực hiện kiểm thử hiệu năng 52

Bảng 4.7 Kết quả kiểm thử hiệu năng trên tổng đài FreePBX 52

Bảng 4.8 Kết quả kiểm thử hiệu năng trên tổng đài FusionPBX 53

Bảng 4.9 Bảng kết quả cuộc gọi giữa 2 IP Phone 55

Bảng 4.10.Bảng kết quả cuộc gọi giữa hệ thống CUCM và FreePBX 56

Bảng 4.11.Các thông số chính trong bản ghi CDR Reports 57

DANH MỤC HÌNH VẼ Hình 1.1 Mô hình kết nối logic mạng VoIP ngành Thuế 12

Hình 2.1 Mô hình giải pháp nâng cấp hệ thống 14

Hình 2.2 Mô hình giải pháp mở rộng 15

Hình 3.1 Các thành phần trong mạng SCCP 18

Hình 3.2 Cấu trúc bản tin SCCP 19

Hình 3.3 Các thành phần trong mạng H.323 22

8

Hình 3.4 Sơ đồ khối thiết bị đầu cuối H.323 22

Hình 3.5 Giao thức báo hiệu H.323 24

Hình 3.6 Thiết lập báo hiệu H.323 trực tiếp giữa hai thiết bị đầu cuối 25

Hình 3.7 Thiết lập báo hiệu H.323 định tuyến qua Gatekeeper 26

Hình 3.8 Báo hiệu được định tuyến thông qua 02 Gatekeeper 27

Hình 3.9 Báo hiệu trực tiếp giữa hai thiết bị đầu cuối trên hai vùng dịch vụ 28

Hình 3.10.Các thành phần trong mạng SIP 29

Hình 3.11.Cơ chế hoạt động theo máy chủ Proxy 35

Hình 3.12.Cơ chế hoạt động theo máy chủ Redirect 36

Hình 3.13.Cơ chế hoạt động theo máy chủ B2BUA 37

Hình 3.14.Sơ đồ tổng quát của Asterisk 42

Hình 3.15.Kiến trúc của Asterisk 42

Hình 3.16.Kiến trúc của FreeSWITCH 45

Hình 4.1 Mô hình triển khai 46

Hình 4.2 Mô hình đánh giá năng lực hệ thống 51

Hình 4.3 Thời gian đáp ứng cho các cuộc gọi của FreePBX 53

Hình 4.4 Thời gian đáp ứng cho các cuộc gọi của FusionPBX 54

Hình 4.5 Mô hình đánh giá chất lượng cuộc gọi 55

9

LỜI CẢM ƠN

Để hoàn thành nội dung luận văn này tôi đã nhận được rất nhiều sự giúp đỡ từ

cơ quan, đoàn thể và cá nhân

Trước hết tôi xin chân thành cảm ơn các thầy giáo, cô giáo trong Khoa Công nghệ thông tin, trường Đại học Công nghệ, Đại học Quốc gia Hà Nội đã tận tình giảng dạy, trang bị cho tôi những kiến thức quý báu trong suốt quá trình học tập tại trường

Tôi xin bày tỏ lòng biết ơn sâu sắc đến Tiến sĩ Hoàng Xuân Tùng – Người thầy đã trực tiếp hướng dẫn tôi trong quá trình xây dựng và hoàn thành luận văn này

Cuối cùng tôi xin bày tỏ lòng biết ơn chân thành đến gia đình, bạn bè những người luôn động viên, giúp đỡ tôi rất nhiệt tình để hoàn thành luận văn

Hà Nội, ngày 26 tháng 03 năm 2015

Học viên

Nguyễn Thanh Long

10

MỞ ĐẦU

Xu hướng thoại qua nền IP (VoIP - Voice over Internet Protocol) ngày càng được phát triển mạnh trong các năm qua, lợi ích của công nghệ này ngày càng được thể hiện rõ Chất lượng cuộc gọi dùng công nghệ này không thua kém công nghệ thoại truyền thống mà còn hỗ trợ nhiều dịch vụ giá trị gia tăng mà điện thoại truyền thống không thể làm được hay chi phí rất đắt Tại việt nam, cùng với sự phát triển mạnh mẽ của mạng Internet với công nghệ cáp quang và chi phí ngày càng giảm nên việc áp dụng Voice over Internet ngày càng phổ biến Một số nhà cung cấp dịch vụ đã phát triển trên hệ thống này từ khá lâu như các dịch vụ giá trị gia tăng, các nhà cung cấp dịch vụ thoại Telco, hệ thống chăm sóc khách hàng

Không nằm ngoài xu hướng phát triển chung, Tổng cục Thuế cũng đã đầu tư

hệ thống VoIP từ những năm 2010 và được mở rộng vào năm 2011 với chức năng tổng đài thoại cho Cục Công nghệ Thông tin - Tổng cục Thuế và tổng đài nội bộ trong ngành từ Tổng cục đến 63 Cục Thuế Việc kết nối thông qua mạng hạ tầng truyền thông thông suốt của ngành Tài chính từ cấp trung ương đến các địa phương (Cục và Chi cục Thuế) Tuy nhiên, đến thời điểm hiện tại hệ thống phát sinh một số vấn đề sau:

- Hệ thống hoạt động trên phiên bản cũ, không cập nhật được các tính năng tối ưu của công nghệ Các thiết bị sử dụng đã hết khấu hao, không còn được hỗ trợ

xử lý các lỗi từ hãng cung cấp

- Một số tính năng yêu cầu cho công việc chưa được đầu tư, số lượng license

đã mua không đủ đáp ứng số lượng người dùng nếu mở rộng đến các phòng ban khác

- Mô hình ứng dụng ngành Thuế đang chuyển dần từ phân tán thành tập trung, nên mọi đầu mối hỗ trợ sẽ tập trung về Tổng cục Thuế Hàng năm, với trên

10000 cuộc gọi hỗ trợ qua điện thoại về ứng dụng và hệ thống (theo thống kê từ báo cáo hàng năm của Cục CNTT) Do đó, vấn đề đáp ứng chất lượng hỗ trợ đòi hỏi ngày càng cao, nhưng hệ thống hiện tại chưa hỗ trợ cho việc đánh giá này Trên cơ sở đó, trong luận văn này tôi đã đề xuất phương án mở rộng hệ thống VoIP hiện tại nhằm đáp ứng một số yêu cầu sau: Mở rộng về số lượng người dùng; Xây dựng một số tính năng mới đáp ứng cho yêu cầu công việc Sau khi phân tích tôi đã chọn phương án mở rộng bằng cách sử dụng giao thức SIP và các phần mềm

mã nguồn mở có thể đáp ứng tốt các yêu cầu trên

Tiến hành kiểm thử theo các bước đã đề xuất trong giải pháp đã phân tích, tôi rút ra được một số kết quả như sau:

- Hệ thống được mở rộng và đáp ứng tốt các yêu cầu của công việc bao gồm: kết nối tốt đến hệ thống tổng đài đang chạy của Tổng cục Thuế qua giao thức SIP, giúp mở rộng số lượng người dùng; Các thông tin của chức năng ghi âm cuộc gọi chi tiết giúp đánh giá được chất lượng hỗ trợ người dùng

12

CHƯƠNG 1 HIỆN TRẠNG MẠNG VOIP NGÀNH THUẾ

Trong chương này tôi đưa ra một số thông tin cơ bản về hiện trạng mạng VoIP ngành Thuế đang sử dụng và các vấn đề còn tồn tại mà luận văn này sẽ tìm hiểu và đưa ra các giải pháp khắc phục

1.1 Mô hình kết nối mạng VoIP ngành Thuế

IP Phone hoặc các softphone cài trên máy trên máy tính (các softphone chỉ được sử dụng tại Cục CNTT)

Hiện tại, các Cục Thuế chỉ sử dụng các IP Phone, không thiết kế riêng voice gateway, việc xử lý cuộc gọi hoàn toàn do CUCM và Voice Gateway tại Tổng cục đảm nhiệm

Việc kết nối từ các Cục Thuế lên Tổng cục được thực hiện qua môi trường mạng WAN ngành Tài chính với công nghệ VPN MPLS layer 3, cáp quang đáp ứng yêu cầu kỹ thuật cho các kết nối thoại

13

1.2 Hiện trạng sử dụng

Hệ thống tổng đài được đặt tại trung tâm dữ liệu Tổng cục Thuế, thực hiện chức năng thoại cho Cục CNTT và trao đổi nội bộ với các Cục Thuế Các IP Phone tại Tổng cục được gọi nội bộ, đến các Cục Thuế và ra ngoài PSTN (riêng các IP Phone tại Cục Thuế chỉ được gọi đến Tổng cục và các Cục Thuế khác - không gọi

ra ngoài PSTN)

Tổng số license hệ thống đã mua là 1500 Unit (theo đơn vị tính của hãng cisco) Tổng số thiết bị đang sử dụng: 405 thiết bị, chiếm 1215 Unit, bao gồm: 198 thiết bị tại Cục Thuế: Cục Thuế lớn (Hà Nội, Hồ Chí Minh, Đà Nẵng) mỗi đơn vị 6

IP Phone, các Cục Thuế còn lại mỗi đơn vị 3 IP Phone; 207 thiết bị tại Cục CNTT - Tổng cục Thuế, sử dụng cho cán bộ Thuế và các đội dự án, hỗ trợ

Các giao thức báo hiệu đang sử dụng: H.323 - giao thức báo hiệu được sử dụng cho kết nối từ CUCM đến voice gateway; SCCP - giao thức báo hiệu được sử dụng cho việc kết nối từ các IP Phone đến CUCM

Mô hình ứng dụng ngành Thuế đang chuyển dần từ phân tán thành tập trung, nên mọi đầu mối hỗ trợ sẽ tập trung về Tổng cục Thuế Hàng năm, với trên 10.000 cuộc gọi hỗ trợ qua điện thoại về ứng dụng và hệ thống (theo thống kê từ báo cáo hàng năm của Cục CNTT)

Nhu cầu sử dụng: số lượng người dùng ngày càng tăng, gồm: Người dùng tại Cục CNTT, các dự án, đội hỗ trợ người sử dụng; Cán bộ tin học tại các Cục Thuế 1.3 Các vấn đề tồn tại

Căn cứ hiện trạng được phân tích trên và nhu cầu sử dụng hiện tại đối với hệ thống, một số yêu cầu cụ thể được xác định cần phải giải quyết sau:

- Mở rộng số lượng người dùng: do số lượng license chưa sử dụng còn hạn chế, trong khi nhu cầu sử dụng của các dự án, của người dùng tại Tổng cục và Cục Thuế ngày càng nhiều

- Trong quá trình sử dụng, việc hỗ trợ người dùng qua hệ thống thoại với hơn 10.000 cuộc gọi hỗ trợ hàng năm vẫn chưa được đánh giá xem chất lượng hỗ trợ có đáp ứng được yêu cầu hay không, có cần phải thay đổi để đáp ứng tốt hơn không

Vì vậy, việc xây dựng một hệ thống có thể hỗ trợ mục tiêu trên là yêu cầu tất yếu

14

CHƯƠNG 2 CÁC GIẢI PHÁP THỰC HIỆN Với các vấn đề còn tồn tại trong chương 1, sau khi tham khảo các công nghệ hiện có và một số tư vấn từ hãng công nghệ Cisco thì trong chương này tôi đưa ra 2 giải pháp phù hợp có thể áp dụng, gồm:

- Chuyển đổi toàn bộ license hiện có sang cách tính license mới của hãng

- Cài đặt thêm máy chủ quản trị: sử dụng phần mềm ghi âm của hãng là Cisco MediaSense [3] và kết nối vào hệ thống hiện tại để lưu các thông tin hỗ trợ người dùng, phục vụ cho việc đánh giá chất lượng cuộc gọi của từng bộ phận và cán bộ (Cisco MediaSense là chuẩn mở, dựa trên nền tảng cơ bản của mạng, hỗ trợ ghi âm, phát lại và lưu trữ các phương tiện truyền thông, bao gồm cả âm thanh và video)

- Cập nhật lại toàn bộ OS cho các thiết bị IP Phone đang chạy (theo khuyến cáo từ hãng)

Mô hình dự kiến cho giải pháp nâng cấp:

Đối với giải pháp này ta vẫn giữ nguyên hệ thống hiện tại và xây dựng thêm

01 tổng đài thoại bằng mã nguồn mở với các yêu cầu sau:

- Phải có giao diện đồ họa để dể dàng quản trị và hỗ trợ thêm tính năng mới đáp ứng mục đích triển khai như ghi âm cuộc gọi

- Hệ thống mới không yêu cầu license cho các tính năng trên và hoàn toàn miễn phí

Mô hình dự kiến cho giải pháp mở rộng:

2.3 Phân tích lựa chọn giải pháp

Với 02 mô hình trên đều có thể đáp ứng được mục đích đề ra ban đầu Tuy nhiên, để có được phương án tối ưu ta cần phân tích ưu nhược điểm của từng phương án:

- Đối với phương án 1:

 Ưu điểm: Đồng bộ với hệ thống hiện tại; Chất lượng đảm bảo, do đã và đang sử dụng trên hệ thống của hãng

 Nhược điểm: Chi phí cao, do phải mua dịch vụ nâng cấp từ phiên bản cũ lên phiên bản mới, mua thêm license để mở rộng được người dùng, mua license cho chức năng mới (Cicso MediaSense) Chi phí khi nâng cấp theo bảng 2.1 (do hãng cung cấp); Thời gian dừng hệ thống để nâng cấp lên hệ

16

thống mới, ảnh hưởng đến toàn bộ người dùng; Nâng cấp OS cho toàn bộ các thiết bị IP Phone đang dùng, do hệ thống mới của hãng chuyển sang chạy chính bằng giao thức SIP (CUCM 10.5 vẫn hỗ trợ SCCP Tuy nhiên, để đồng

bộ thì phải nâng cấp lên phiên bản chạy SIP)

Bảng 2.1 Bảng ước lượng chi phí khi nâng cấp Item Name Description Quantity Price (USD) Selling MIG-CUCM-

USR-A

Migration to UC Manager Enhanced - Less than 1K Users

CON-ECMU-LICCUCME

SWSS UPGRADES UC Manager-10.x Enhanced Single User-Und

Bảng 2.1 bao gồm các thành phần: nâng cấp license hiện có, tính theo công thức license mới của hãng là thiết bị thay cho unit (1500 unit = 500 thiết bị) Mua mới 300 license cho các thiết bị mới License cho MediaSense với record cho 100 devices

- Đối với phương án 2:

 Ưu điểm: Không cần thời gian tạm dừng hệ thống, không thay đổi các thiết bị IP Phone do hệ thống mới được xây dựng chạy song song với hệ thống hiện tại; Không cần chi phí để nâng cấp hoặc mua mới cho hệ thống do chạy

mã nguồn mở miễn phí (riêng phần cứng để cài đặt tổng đài cũng tương đương với phần cứng chạy MediaSense tại phương án 1)

17

 Nhược điểm: Chất lượng cuộc gọi không đảm bảo do chưa được kiểm chứng; Năng lực của hệ thống phụ thuộc vào phần cứng của máy chủ và không được đồng bộ như thiết bị của hãng; Độ trễ của hệ thống sẽ tăng lên khi phải đi qua cả hai hệ thống nếu hai thiết bị trên hai hệ thống gọi cho nhau; Việc cài đặt các softphone gây ảnh hưởng và khó khăn cho người sử dụng đầu cuối

Với các ưu, nhược điểm đã phân tích ở trên và nhu cầu thực tế đối với hệ thống, tôi quyết định chọn phương án 2 để tiến hành nghiên cứu và triển khai cho Tổng cục Thuế với các căn cứ sau:

- Thiết bị tính tới thời điểm hiện tại cũng đã dùng được 4-5 năm, nhưng chưa được thay thế do yêu cầu của Bộ tài chính đối với các thiết bị đặc chủng phải dùng khoảng 6-7 năm nên thời gian còn lại không nhiều, nếu nâng cấp luôn trong năm nay thì khoảng thời gian thay thế giữa các thiết bị lại chênh lệch, rất khó để sau này nếu phải thay thế bằng hệ thống khác

- Để có thể thay thế các thiết bị thì cần phải có dự toán cho năm tiếp theo, trong khi năm 2015 chưa có dự toán cho đầu mục này Nếu dự toán vào giữa năm thì thời gian nhanh nhất đến cuối năm 2015 mới có thể mua sắm và triển khai trong năm 2016

- Yêu cầu của hệ thống phải được đảm bảo liên tục và thông suốt, nếu triển khai phương án 1 sẽ ảnh hưởng rất nhiều đến người sử dụng vì phải nâng cấp tổng đài và cả các thiết bị IP Phone tại Tổng cục và các Cục Thuế

18

CHƯƠNG 3 CÔNG NGHỆ HỖ TRỢ

Để triển khai phương án được lựa chọn tại chương 2, tôi tập trung nghiên cứu các công nghệ hỗ trợ cho hệ thống thoại phổ biến mà cộng đồng mã nguồn mở đang phát triển và sử dụng, gồm:

3.1 Giao thức báo hiệu

Trong tài liệu này tôi chỉ nghiên cứu vào các giao thức báo hiệu đang sử dụng

và được hỗ trợ bởi hệ thống VoIP ngành Thuế gồm: giao thức SCCP (giao thức riêng của hãng Cisco), giao thức H.323 và giao thức SIP

3.1.1.1 Các thành phần trong mạng SCCP

SCCP là giao thức Client - Server nên các thành phần chính trong mạng SCCP của Cisco gồm client là IP Phone và Server là CUCM Phần kết nối ra ngoài PSTN thông qua Voice Gateway

19

dùng, chức năng dịch địa chỉ, điều khiển truy cập, quản lý, xác thực người dùng), luồng dữ liệu sẽ được chạy trên giao thức RTP giữa các IP Phone CUCM hỗ trợ thêm các giao thức báo hiệu khác như H.323 và SIP để thực hiện kết nối đến Voice Gateway (do Voice gateway của Cisco không hỗ trợ giao thức SCCP)

- Voice Gateway: là các thiết bị, chúng cho phép giao tiếp giữa các thiết bị trong mạng SCCP đến các mạng khác

3.1.1.2 Bản tin SCCP

SCCP là một giao thức gọn nhẹ (được gọi là "Skinny") nên cấu trúc của bản tin SCCP khá đơn giản, thường sẽ có 1 hoặc nhiều bản tin trên một gói tin Định dạng cơ bản của bản tin SCCP: tất cả các trường đều có 4 byte Trường đầu tiên là

độ dài của bản tin, trường thứ 2 là trường dành riêng, trường thứ 3 là trường hiển thị loại bản tin, trường còn lại của bản tin là các biến

Hình 3.2 Cấu trúc bản tin SCCP Các bản tin của SCCP [6] sẽ xuất hiện theo thứ tự tuần tự sau :

- Bước 1: Các bản tin khi điện thoại đăng ký với CUCM và kiểm tra trạng thái, cảnh báo Hướng mũi tên "" sẽ chỉ hướng từ điện thoại đến CUCM và ngược lại

Bảng 3.1 Các bản tin SCCP đăng ký phone

 0001 RegisterMessage

Device Name, Station UserID &

Instance, IP Address, Device Type, Max Streams

 0002 IPPortMessage IP and Port Terminal is listening on

 0081 RegisterAckMessage

Keep Alive Interval, Date Template (M/D/YA), Secondary Keep Alive Interval

 009B CapabilitiesRequest Call Mgr asks for Station capabilties

 0010 CapabilitiesResponse CapCount capabilities

20

(PayLoad/MaxFramesPerPacket)

 000F VersionRequest Station requests Call Mgr version

 0098 VersionResponse Call Mgr Version

32-Các điện thoại sẽ định kỳ gửi bản tin "KeepAlive" đến CUCM để kiểm tra trạng thái của điện thoại Các cảnh báo sẽ được gửi trong trường hợp bị lỗi

Bảng 3.2 Các bản tin SCCP kiểm tra trạng thái và cảnh báo

 0000 KeepAliveMessage (sent periodically by phone)

 0100 KeepAliveAckMessage (sent periodically by callMgr)

Bảng 3.3 Các bản tin SCCP khi nhấc điện thoại

21

SoftKeyMap (16-bit bitmap)

 0116 ActivateCallPlaneMessage Line Instance

 0082 StartToneMessage Dial Tone (as 32 bit identifier)

- Bước 3: Các bản tin khi thực hiện cuộc gọi Khi cuộc gọi bắt đầu thực hiện,

nó sẽ gửi bản tin dừng chuông và bắt đầu tạo kênh cho cuộc thoại

Bảng 3.4 Các bản tin SCCP khi thực hiện cuộc gọi

 0105 OpenReceiveChannel Receive Channel Details

 008A StartMediaTransmission Transmission Channel Details

 0022 OpenReceiveChannelAck Status, IP, Port, Pass Through Party ID

 0007 OnHookMessage (serves as a call hangup)

 0113 ClearPromptStatusMess Line Instance, Call Ident

 0106 CloseReceiveChannel Conf Id, Pass Through Party Id

 008B StopMediaTransmission Conf Id, Pass Through Party Id

3.1.2 Giao thức báo hiệu H.323

Giao thức H.323 [15] là chuẩn do ITU-T phát triển, cho phép truyền thông

đa phương tiện qua các hệ thống dựa trên mạng chuyển mạch gói Nó được ban hành lần đầu vào năm 1996 và năm 1998 phiên bản thứ 2 ra đời, phiên bản hiện tại

là 7 được công bố vào tháng 11/2009 H.323 cung cấp nền tảng kỹ thuật cho truyền thoại, hình ảnh, số liệu một cách đồng thời qua mạng IP H.323 bao gồm cả chức năng điều khiển cuộc gọi, quản lý thông tin đa phương tiện, quản lý băng thông

3.1.2.1 Các thành phần trong mạng H.323

Một số thành phần trong mạng H.323 [5][15] bao gồm: thiết bị đầu cuối H.323 (H.323 terminal), đơn vị điều khiển liên kết đa điểm MCU (H.323 MCU), Gateway, Gatekeeper

22

Hình 3.3 Các thành phần trong mạng H.323

- Thiết bị đầu cuối H.323 (H.323 terminal): là các thiết bị đầu cuối trong mạng VoIP, có khả năng truyền thông hai chiều, nó có thể là một thiết bị PC hoặc một thiết bị độc lập

Hình 3.4 Sơ đồ khối thiết bị đầu cuối H.323

- Điều khiển liên kết đa điểm MCU (Multipoint Control Unit): là một thiết bị trong mạng, nó cung cấp khả năng cho nhiều thiết bị đầu cuối, gateway cùng tham gia vào một liên kết đa điểm Một MCU bao gồm một MC (Multipoint Controller), một hoặc nhiều MP (Multipoint Process) Các nhiệm vụ của MC là điều tiết khả

23

năng audio, video, data nào cần được gửi đến các đầu cuối theo giao thức H.245 và điều khiển các tài nguyên của hội thoại bằng việc xác định dòng audio, video, data cần được gửi đến thiết bị đầu cuối Tuy nhiên, MC không thao tác trực tiếp trên các dòng dữ liệu mà nhiệm vụ này giao cho MP, MP sẽ thực hiện việc kết hợp, chuyển đổi, xử lý các bits dữ liệu

- Gateways: là các thiết bị, chúng cho phép giao tiếp giữa các thiết bị trong mạng H.323 đến các mạng khác Ví dụ như một gateway có thể kết nối và cung cấp khả năng truyền tin giữa một thiết bị đầu cuối H.323 và chuyển mạch kênh PSTN Gateway cũng được sử dụng để cho phép các thiết bị hội nghị truyền hình dựa trên H.320 và H.324 giao tiếp với hệ thống H.323 Hầu hết mạng di động 3G hiện nay

sử dụng giao thức H.324 và có thể giao tiếp với thiết bị đầu cuối H.323 thông qua các thiết bị gateways

- Gatekeepers: là thành phần mở rộng trong mạng H.323, nó cung cấp các dịch vụ đến các thiết bị đầu cuối, gateways và các MCU Các dịch vụ chính của gatekeeper bao gồm: đăng ký người dùng, chức năng dịch địa chỉ, điều khiển truy cập, xác thực người dùng , cụ thể như sau:

 Chức năng dịch địa chỉ: Gatekeeper sẽ thực hiện chuyển đổi địa chỉ URI (dạng tên gọi hay địa chỉ hộp thư) của một đầu cuối hay Gateway sang địa chỉ truyền dẫn (địa chỉ IP) Việc chuyển đổi được thực hiện bằng cách sử dụng bản đối chiếu địa chỉ được cập nhật thường xuyên bởi các bản tin đăng ký

 Điều khiển truy cập: Gatekeeper cho phép một truy cập bằng cách sử dụng các bản tin H.225 là Admission Request/Admission Confirm/Admission Reject (ARQ/ACF/ARJ) Việc điều khiển này dựa trên sự cho phép cuộc gọi, băng thông, hoặc một vài thông số khác do nhà sản xuất quy định Nó có thể

là chức năng rỗng, nghĩa là chấp nhận mọi yêu cầu truy nhập của đầu cuối

 Điều khiển độ rộng băng thông: Gatekeeper hỗ trợ các bản tin Bandwidth Request/Bandwidth Confirm/Bandwidth Reject (BRQ/BCF/BRJ) cho việc quản lý băng thông Nó có thể là chức năng rỗng, nghĩa là chấp nhận mọi yêu cầu thay đổi băng thông Gatekeeper có thể hạn chế một số các đầu cuối H.323 cùng một lúc sử dụng mạng Thông qua việc sử dụng kênh báo hiệu H.225, Gatekeeper có thể loại bỏ các các cuộc gọi từ một đầu cuối do sự hạn chế băng thông Điều đó có thể xảy ra nếu Gatekeeper thấy rằng không đủ băng thông sẵn có trên mạng để trợ giúp cho cuộc gọi Việc từ chối cũng có thể xảy ra khi một đầu đang tham gia một cuộc gọi yêu cầu thêm băng thông

Nó có thể là một chức năng rỗng nghĩa là mọi yêu cầu truy nhập đều được đồng ý

 Quản lý miền dịch vụ: ở đây miền dịch vụ (domain) nghĩa là tập hợp tất

cả các phần tử H.323 gồm thiết bị đầu cuối Gateway, MCU có đăng ký hoạt động với Gatekeeper để thực hiện liên lạc giữa các phần tử trong miền dịch vụ hay từ dịch vụ này sang dịch vụ khác

24

 Điều khiển báo hiệu cuộc gọi: Gatekeeper có thể lựa chọn hai phương thức điều khiển báo hiệu cuộc gọi là: hoàn thành báo hiệu cuộc gọi với các đầu cuối và xử lý báo hiệu cuộc gọi chính bản thân nó, hoặc Gatekeeper có thể

ra lệnh cho các đầu cuối kết nối một kênh báo hiệu cuộc gọi hướng tới nhau Theo phương thức này thì Gatekeeper không phải giám sát báo hiệu trên kênh H.225

 Quản lý cuộc gọi: Một ví dụ cụ thể về chức năng này là Gatekeeper có thể lập một danh sách tất cả các cuộc gọi H.323 hướng đi đang thực hiện để chỉ thị rằng một đầu cuối bị gọi đang bận và cung cấp thông tin cho chức năng quản lý băng thông

3.1.2.2 Giao thức báo hiệu H.323

Giao thức H.323 [5] được chia làm 3 phần chính gồm: Báo hiệu H.225 RAS (Registration, Admissions and Status), báo hiệu H.225 (Q.931), báo hiệu H.245

Hình 3.5 Giao thức báo hiệu H.323

- Báo hiệu H.225 RAS (Registration, Admissions and Status): cung cấp điều khiển tiền cuộc gọi trong mạng H.323 có tồn tại Gatekeeper và một vùng dịch vụ (do Gatekeeper quản lý) Kênh RAS được thiết lập giữa các thiết bị đầu cuối và Gatekeeper qua mạng IP với các chức năng như: tìm gatekeeper, đăng ký, quản lý băng thông Kênh RAS được mở trước khi các kênh khác được thiết lập và độc lập với các kênh điều khiển cuộc gọi và media khác

- Báo hiệu H.225: Giao thức H.225 được dùng để thiết lập liên kết giữa các điểm cuối H.323 (thiết bị đầu cuối, gateway), qua liên kết đó dữ liệu thời gian thực

sẽ được truyền đi Quá trình báo hiệu cuộc gọi được bắt đầu bởi bản tin setup được gửi đi trên kênh báo hiệu H.225, tiếp theo là một chuỗi các bản tin phục vụ cho quá trình thiết lập cuộc gọi Chức năng điều khiển cuộc gọi dựa trên cơ sở giao thức H.323 sử dụng bản tin báo hiệu Q.931 Một kênh điều khiển cuộc gọi được tạo ra dựa trên giao thức TCP/IP với cổng 1720 H.225 cũng sử dụng bản tin Q.932 cho các dịch vụ bổ sung

- Báo hiệu H.245: giao thức H.245 được sử dụng để thiết lập các kênh logic

để truyền audio, video, data và các thông tin kênh điều khiển Giữa 2 thiết bị đầu

25

cuối được thiết lập một kênh H.245 cho một cuộc gọi Kênh điều khiển truyền thông H.245 thiết lập trên một kết nối TCP, nó truyền tải các thông điệp điều khiển với các chức năng sau:

 Trao đổi: Mã hóa, giải mã các dòng tín hiệu media của các thiết bị đầu cuối tham gia truyền thông

 Quyết định chủ tớ: Xác định mối quan hệ chủ tớ giữa các điểm cuối, dùng để giải quyết tranh chấp giữa chúng khi xảy ra

 Đóng, mở các kênh logic cho tín hiệu media

3.1.2.3 Thiết lập cuộc gọi VoIP sử dụng giao thức H.323

Trong phần này tôi xin trình bày 03 mô hình báo hiệu được sử dụng với giao thức H.323 gồm:

Mô hình 1: Báo hiệu trực tiếp giữa các thiết bị đầu cuối

- Trong mô hình này, có chú ý là các thiết bị đầu cuối (Endpoint) chỉ xin phép Gatekeeper thực hiện cuộc gọi thông qua báo hiệu RAS còn các bước báo hiệu giữa các thiết bị này được thực hiện trực tiếp không thông qua Gatekeeper

- Dưới đây là một ví dụ thiết lập cuộc gọi giữa 2 hai thiết bị đầu cuối có cùng một Gatekeeper

Hình 3.6 Thiết lập báo hiệu H.323 trực tiếp giữa hai thiết bị đầu cuối

 Bước 1: Endpoint O đăng kí với Gatekeeper yêu cầu cho phép thực hiện một cuộc gọi tới Endpoint T Các bước thực hiện xác thực thuê bao gọi sẽ được thực hiện ở bước này Gatekeeper trả lời cho phép Endpoint O thực hiện

 Bước 4: Người bị gọi nhấc ống nghe Endpoint T gửi bản tin Conect tới Endpoint O thông báo kênh cuộc gọi đã được thiết lập Lúc này, giữa hai Endpoint mở một kết nối TCP nữa cho kênh báo hiệu H.245 để thương lượng, thiết lập và duy trì kênh media

 Bước 5: Khi đã thương lượng xong (các thông số được mô tả trong phần báo hiệu H.245), mỗi Endpoint yêu cầu mở một kết nối audio để truyền thoại Như vậy sẽ tồn tại hai kênh cho phép thực hiện cuộc gọi hai chiều giữa hai thuê bao Quá trình thoại được thực hiện hiện dựa trên giao thức RTP với sự kiểm soát của RTCP

Mô hình 2: Báo hiệu được định tuyến thông qua Gatekeeper

- Trong mô hình này thì mọi bản tin báo hiệu đều được gửi qua Gatekeeper Gatekeeper sẽ xử lý và chuyển tiếp bảo tin tới phía bị gọi Khi đó, phía gọi không nhất thiết phải biết chính xác địa chỉ của phía bị gọi nhưng quá trình này sẽ bị trễ nhiều hơn

Hình 3.7 Thiết lập báo hiệu H.323 định tuyến qua Gatekeeper

 Sau khi nhận được bản tin Connect từ Endpoint T, Endpoint O và Endpoint T sẽ thực hiện báo hiệu trực tiếp với nhau để mở kênh truyền media

Mô hình 3: thiết lập cuộc gọi giữa hai thiết bị đầu cuối ở hai vùng dịch vụ

- Trong mô hình này là việc thực hiện cuộc gọi giữa hai thiết bị đầu cuối ở hai vùng dịch vụ khác nhau cho nhau Mô hình này được chia làm 2 dạng theo các kiểu báo hiệu mô hình 1 và 2 gồm: báo hiệu được định tuyến thông qua 2 Gatekeeper và báo hiệu trực tiếp giữa hai thiết bị đầu cuối trên hai vùng dịch vụ

Hình 3.8 Báo hiệu được định tuyến thông qua 02 Gatekeeper

28

- Sau khi nhận được yêu cầu của Endpoint O muốn thiết lập cuộc gọi với Endpoint T, Gatekeeper 1 gửi tới Endpoint T yêu cầu thiết lập cuộc gọi Vì Endpoint T nằm trong vùng dịch vụ do Gatekeeper 2 quản lý nên nó phải xin sự cho phép để có thể thực hiện cuộc gọi (giống như các trường hợp trước) Ở trong trường hợp này, Gatekeeper 2 cũng gửi trả lời bản tin ARQ của Endpoint T bằng bản tin ACF cho phép thiết lập cuộc gọi nhưng phải thông qua nó (không cho thực hiện cuộc gọi trực tiếp tới Endpoint T) Do vậy, Endpoint T gửi bản tin Facility tới Gatekeeper 1 thông báo là cuộc gọi được chấp nhận nhưng phải được định tuyến lại thông qua Gatekeeper 2

Hình 3.9 Báo hiệu trực tiếp giữa hai thiết bị đầu cuối trên hai vùng dịch vụ

- Tương tự như trường hợp trên, hình 3.9 cho ta thấy trước khi gửi bản tin setup nó sẽ thực hiện thiết lập trực tiếp một kết nối TCP cho báo hiệu H.225 để truyền các bản tin Q.931

3.1.3 Giao thức báo hiệu SIP

Session Initiation Protocol (SIP) [16] đã được chuẩn hóa bởi Internet Engineering Task Force (IETF) và được mô tả trong Request for Comment (RFC) RFC 2543 là phiên bản đầu tiên và RFC 3261 là phiên bản gần đây nhất, được gọi

là SIP phiên bản 2 SIP là một giao thức tầng ứng dụng được sử dụng để thiết lập, duy trì và kết thúc phiên hoặc các cuộc gọi đa phương tiện Các phiên này có thể là

29

âm thanh và video, e-learning, hội nghị, hoặc các phiên screen-sharing Nó dựa trên một giao thức văn bản tương tự như Hypertext Transfer Protocol (HTTP) và được thiết kế để bắt đầu, giữ, và đóng các phiên truyền thông tương tác giữa những người sử dụng Ngày nay, SIP là một trong những giao thức được sử dụng phổ biến cho mạng VoIP và có mặt trên hầu hết các cuộc gọi IP trên thị trường

3.1.3.1 Các thành phần trong mạng SIP

Hình 3.10 Các thành phần trong mạng SIP Nhìn vào hình 3.10 ta thấy các thành phần chính trong mạng SIP gồm: User Agent, Proxy server, Location server, Redirect server và Registrar server

- User Agent: là các thiết bị đầu cuối trong mạng SIP (các điện thoại IP, softphone ) User agent được chia làm 2 loại là client và server: User agent client (UAC): là các client hoặc thiết bị đầu cuối mà bắt đầu báo hiệu SIP và khởi tạo cuộc gọi User agent server (UAS): là các server để đáp ứng các tín hiệu SIP đến từ một UAC và trả lời cuộc gọi

- Proxy server: là thực thể trong mạng SIP, làm nhiệm vụ chuyển tiếp các SIP request tới thực thể khác trong mạng Như vậy, chức năng chính của nó trong mạng

là định tuyến cho các bản tin đến đích Proxy server cũng cung cấp các chức năng xác thực trước khi cho khai thác dịch vụ Một proxy có thể lưu (stateful) hoặc không lưu trạng thái (stateless) của bản tin trước đó Thông thường, proxy có lưu trạng thái, chúng duy trì trạng thái trong suốt transaction

- Redirect server: Chức năng của máy chủ redirect là nhận yêu cầu và trả lời cho người gọi với một thông điệp có chứa dữ liệu về các điểm đến (nhận yêu cầu SIP và chuyển đổi địa chỉ SIP sang một số địa chỉ khác và gửi cho UA)

- Location server: lưu thông tin trạng thái hiện tại của người dùng trong mạng SIP