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ế

ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

NGUYỄN THANH LONG

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Ế

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

Hà Nội - 2015
1


ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

NGUYỄN THANH LONG

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Ế

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
2


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

3


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
4


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

5


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

CT

Cục Thuế

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

6


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
7


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

8


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

9

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


- Về khả năng hỗ trợ số lượng người dùng trên các tổng đài mã nguồn mở là
gần tương đương nhau, phụ thuộc vào cấu hình phần cứng của tổng đài triển khai.
- Về chất lượng: sau khi thực hiện đánh giá chất lượng giữa hệ thống tổng đài
mới (tổng đài mã nguồn mở FreePBX) và tổng đài hiện có của Tổng cục Thuế thì
kết quả tương đối tương đồng, chất lượng cuộc gọi tốt, đảm bảo điểm đạt cao nhất
theo thang điểm Mean Opinion Score (MOS) [7].

11


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

IP
IP

IP

IP

IP

Hình 1.1. Mô hình kết nối logic mạng VoIP ngành Thuế
Mạng VoIP ngành Thuế được xây dựng theo công nghệ của hãng Cisco, bao
gồm các thiết bị: 02 thiết bị quản trị CUCM version 6.0, chạy cluster chia tải; 02
thiết bị trả lời tự động IVR, chạy cluster mode active/standby; 01 Voice gateway,
kết nối trực tiếp đến PSTN; Sử dụng trung kế E1 với 22 kênh thoại được đăng ký
với nhà cung cấp dịch vụ; Các thiết bị điện thoại: bao gồm các thiết bị phần cứng
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.

12


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.

13

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:
2.1. Giải pháp nâng cấp hệ thống
Với giải pháp này ta chỉ cần tiến hành nâng cấp và mở rộng hệ thống hiện tại
theo công nghệ của hãng Cisco. Các yêu cầu đối với giải pháp trên:
- Nâng cấp phiên bản CUCM từ 6.0 lên phiên bản hiện tại là 10.5 để cập nhật
các tính năng mới cho phần mềm quản trị.
- 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:

IP

IP

IP

IP

IP

IP

Hình 2.1. Mô hình giải pháp nâng cấp hệ thống
2.2. Giải pháp mở rộng hệ thống bằng Opensource
Đố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:
14


- Kết nối được với hệ thống ngành Thuế đang chạy (các số có thể gọi được
cho nhau trên 02 hệ thống) nhằm mở rộng người dùng.
- Hỗ trợ các giao thức báo hiệu như H323 hoặc SIP (CUCM chỉ hỗ trợ
H.323, SIP hoặc SCCP - giao thức riêng của hãng). Chất lượng cuộc gọi phải đáp
ứng được yêu cầu sử dụng, tương đương với hệ thống đang chạy (hỗ trợ các codec
G.729, G.711).
- 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:

IP

IP

IP

IP

Hình 2.2. Mô hình giải pháp mở rộng
Với mô hình trên ta sử dụng các softphone tại Cục và các Cục Thuế để mở
rộng cho người dùng hoặc thay thế các thiết bị hỏng đã hết khấu hao.
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ệ
15


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

MIG-CUCMUSR-A

Migration to UC Manager
Enhanced - Less than 1K Users

500

Selling
Price (USD)
22500

CON-ECMUMIGCUC87

SWSS UPGRADES Migration
to UC Manager Enhanced

500

13800

LIC-CUCM10X-ENH-A

UC Manager-10.x Enhanced
Single User-Under 1K

300

63000

300

8280

1

2000

100

22500

100

5175

100

2500

Item Name

Description

SWSS UPGRADES UC
Manager-10.x Enhanced Single
User-Und
MCP-SVR-10X- One Server License (One
Primary or One Secondary
SW
Node) - For MediaSense
MediaSense Base Port License
MCP-BASE10X-LIC
SWSS UPGRADES MediaSense
CON-ECMUBase Port License
MASE10XL
CON-ECMULICCUCME

Quantity

MCP-C-10XAUD-LIC

MediaSense Audio Session

CON-ECMUMCP0XAUD

SWSS UPGRADES MediaSense 100
Base Port License

575

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


 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ế.

17


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. Giao thức SCCP

SCCP [2][14] là giao thức báo hiệu được phát triển bởi công ty Selsius, được
Cisco mua lại vào năm 1998 và trở thành giao thức riêng của Cisco.
SCCP được sử dụng để giao tiếp giữa các thiết bị IP và hệ thống CUCM. Một
SCCP client sử dụng TCP/IP để giao tiếp với CUCM (hoặc nhiều CUCM trong 1
Cluster), nó sử dụng giao thức RTP để truyền tải âm thanh đến một client khác.
Trong tài liệu này tôi chỉ đưa ra một số thông tin cơ bản của giao thức báo hiệu
SCCP, do thực tế đây là giao thức riêng của hãng nên các thiết bị và phần mềm mã
nguồn mở sẽ không hỗ trợ giao thức này.
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.

IP

Hình 3.1. Các thành phần trong mạng SCCP
- Thiết bị IP Phone: là các thiết bị đầu cuối trong mạng SCCP, nó được hỗ trợ
chạy riêng cho giao thức SCCP của Cisco.
- Cisco Unified Communications Manager (CUCM): là thành phần chính
trong mạng SCCP, nó thực hiện chức năng chính của một proxy (đăng ký người
18


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
Msg

Usage

Data

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


(PayLoad/MaxFramesPerPacket)
 000F

VersionRequest

Station requests Call Mgr version

 0098

VersionResponse

Call Mgr Version

 000E

ButtonTemplateRequest

--

ButtonTemplateMessage

Button offset/count and 40-something
button defs

TimeDateRequest

--

DefineTimeDate

Y/M/WD/D, Hour/Min/Sec/mSec, 32bit TimeStamp


0097
 000D


0094

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
Msg

Usage

Data

 0000

KeepAliveMessage

-- (sent periodically by phone)

 0100

KeepAliveAckMessage

-- (sent periodically by callMgr)

Alarm Message

Alarm Severity, Display Message &
Params

 0020

- Bước 2: Các bản tin khi người dùng nhấc điện thoại, điện thoại sẽ gửi một
bản tin "OffHook" đến CUCM và ngược lại CUCM sẽ gửi lại một loạt các bản tin
đến điện thoại.
Bảng 3.3. Các bản tin SCCP khi nhấc điện thoại
Msg

Usage

Data

 0006

OffHookMessage

--

 0099

DisplayTextMessage

ASCII text, NULL terminated

SetLampMessage

Stimulus, StimulusInstance,
LampMode

CallStateMessage

Call State (code), Line Instance, Call

Ident

DisplayPromptStatus

Timeout, DisplayMessage*, Line Inst,
Call Ident

SelectSoftKeysMessage

Line Instance, Call Ident, SoftKeySet,


0086

0111

0112
 0110

20


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
Msg
 0003

Usage

Data

KeyPadButtonMessage

Dialed Digit

StopToneMessage

0110 may follow to reconfigure
softkeys..

CallInfoMessage

Calling/Called Party & Party Names,
Line Inst., Call Ident, Call Type, Orig.
called party

 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


0083

008F

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


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


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


 Đ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
24


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
25