Phần mềm SIPp

Một phần của tài liệu 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ế (Trang 50)

- SIPp [4] là một công cụ mã nguồn mở miễn phí dùng để kiểm tra hiệu suất của giao thức SIP. Nó bao gồm một vài kịch bản cơ bản (UAC và UAS) dùng để thiết lập và tạo ra các phiên đa cuộc gọi với các phương thức INVITE và BYE. Nó cũng có thể đọc các tập kịch bản XML để mô tả cấu hình kiểm tra hiệu năng riêng cho từng trường hợp. SIPp có thể được sử dụng để kiểm tra các hệ thống thực chạy SIP như SIP Proxies, B2BUAs, SIP media servers, SIP PBX..., nó cũng được sử dụng để giả lập hàng nghìn cuộc gọi trong hệ thống SIP của bạn.

- Một số tính năng nâng cao khác bao gồm hỗ trợ cho IPv6, TLS, SCTP, xác thực SIP, kịch bản có điều kiện, truyền tải UDP, các biến đặc biệt cho cuộc gọi. Nó có thể sử dụng các file mở rộng CSV để giả lập người dùng thực tế. SIPp cũng có thể gửi các lưu lượng media qua RTP, media ở đây có thể là audio hoặc video.

- Trong luận văn này tôi sử dụng SIPp phiên bản 3.3 để thực hiện đánh giá hiệu năng các tổng đài, thông số máy chủ chạy SIPp:

Bảng 4.5. Bảng thông số máy chủ chạy SIPp Máy chủ giám sát solarwinds

Server Laptop OS Ubuntu Server 12.04 CPU 4 Cores, 2,6 GHz Ram 8Gb HDD 500Gb IP 10.64.29.117 Netmask 255.255.255.0 Gateway 10.64.29.1

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

4.4.1. Đánh giá năng lực hệ thống 4.4.1.1. Mô hình đánh giá 4.4.1.1. Mô hình đánh giá

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

4.4.1.2. Thực hiện đánh giá

Với mô hình trên ta đánh giá lần lượt các tổng đài FusionPBX và FreePBX, kịch bản đánh giá được thực hiện như sau:

- Luồng dữ liệu: SIPp thực hiện cuộc gọi (có xác thực); Thực hiện cuộc gọi đến số cố định (số cố định này được cấu hình trả lời tự động khi thực hiện kiểm thử năng lực hệ thống) qua FreePBX (hoặc FusionPBX); Chạy media qua RTP với file g711a.pcap (mặc định có trên SIPp); Khoảng thời gian thực hiện một cuộc gọi trong 60s (giả định với một cuộc gọi trung bình trong khoảng 1 phút).

- Xác thực cuộc gọi: sử dụng file .CSV chứa các thông tin tài khoản đính kèm (tài khoản đã được tạo trên hệ thống tổng đài) trong câu lệnh SIPp để xác thực khi có yêu cầu. Các thông tin chính gồm: Số gọi đi, IP tổng đài, username, password và số được gọi đến.

- Số lượng cuộc gọi: Dự kiến có 600 số điện thoại trên tổng đài mới bao gồm: 570 số cho Cục Thuế (trung bình mỗi Cục Thuế sẽ có 9 số, riêng Hà Nội, Hồ Chí Minh và Đà Nẵng sẽ có 10 số), 30 số cho đội hỗ trợ tại Tổng cục Thuế. Thời gian thực hiện một cuộc gọi trung bình 60s. Do đó, lần lượt thực hiện đánh giá tải với 10%, 20%, 30% và 50% số cuộc gọi đồng thời theo cách tính sau:

 Với 10% trong 600 số thì có 60 số thực hiện cuộc gọi đồng thời (60 số luôn gọi trong vòng 60s).

 Với 20% trong 600 số thì có 120 số thực hiện cuộc gọi đồng thời.

 Với 30% trong 600 số thì có 180 số thực hiện cuộc gọi đồng thời.

 Với 50% trong 600 số thì có 300 số thực hiện cuộc gọi đồng thời.

52

 Với 100% trong 600 số thì có 600 số thực hiện cuộc gọi đồng thời.

- Mỗi lần kiểm tra tải thực hiện 1000 cuộc gọi để đánh giá xem có bao nhiêu cuộc gọi thành công hay lỗi.

Các tham số cơ bản của kịch bản kiểm thử theo bảng 4.6 dưới đây. Bảng 4.6. Các tham số thực hiện kiểm thử hiệu năng % Số điện thoại

đang thực hiện gọi

Số cuộc gọi đồng thời/60s

Số cuộc gọi được thực hiện

Tham số thực hiện (theo dòng lệnh SIPp) 10% 60 1000 r = 1, m =1000 20% 120 1000 r = 2, m =1000 30% 180 1000 r = 3, m =1000 50% 300 1000 r = 5, m =1000 80% 480 1000 r = 8, m =1000 100% 600 1000 r = 10, m =1000

Với r: là số cuộc gọi được thực hiện trong vòng 1s, m là tổng số cuộc gọi. Một số tham số lấy log trong quá trình chạy SIPP gồm:

- trace_screen: dump trạng thái màn hình kết quả của quá trình chạy SIPp, sử dụng để thống kê số cuộc gọi thành công, thất bại và các tham số response time.

- trace_rtt: thống kê các response theo kịch bản, được sử dụng để vẽ biểu đồ response time theo số lượng cuộc gọi.

- trace_err: đưa ra các thông tin lỗi gặp phải trong quá trình chạy SIPp.

4.4.1.3. Kết quả

Kết quả thực hiện kiểm thử hiệu năng theo kịch bản trên đối với hai tổng đài mã nguồn mở được cài đặt như sau:

- Tổng đài FreePBX: kết quả kiểm thử hiệu năng được tổng hợp theo bảng 4.7 và biểu đồ thời gian đáp ứng cho các cuộc gọi theo hình 4.3.

Bảng 4.7. Kết quả kiểm thử hiệu năng trên tổng đài FreePBX Số cuộc gọi đồng thời trong 60s Tổng số cuộc gọi được thực hiện Số cuộc gọi thành công Số cuộc gọi không thành công Trung bình 01 CPU được sử dụng 60 1000 1000 0 4,2% 120 1000 1000 0 7% 180 1000 1000 0 12,8%

53

300 1000 1000 0 22,2%

480 1000 1000 0 33,6%

600 1000 984 16 38,4%

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

- Tổng đài FusionPBX: kết quả kiểm thử hiệu năng được tổng hợp theo bảng 4.8 và biểu đồ thời gian đáp ứng cho các cuộc gọi theo hình 4.4.

Bảng 4.8. Kết quả kiểm thử hiệu năng trên tổng đài FusionPBX Số cuộc gọi đồng thời trong 60s Tổng số cuộc gọi được thực hiện Số cuộc gọi thành công Số cuộc gọi không thành công Trung bình 01 CPU được sử dụng (max) 60 1000 1000 0 5,1% 120 1000 1000 0 12,1% 180 1000 1000 0 19,3% 300 1000 1000 0 35,1%

54

480 1000 1000 0 56,5%

600 1000 895 105 59,6%

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

Đối với các trường hợp chạy 600 cuộc gọi đồng thời trong vòng 60s, do có số lượng cuộc gọi không thành công nên kết quả trên là kết quả trong trường hợp có lượng cuộc gọi không thành công ở mức giữa (trong 03 cuộc kiểm thử).

Nhìn vào biểu đồ thời gian đáp ứng, ta thấy: đối với FreePBX thời gian đáp ứng trung bình ở mức 30 - 40ms tốt hơn so với FusionPBX trung bình ở mức 60 - 70ms. Tuy nhiên, ở mức cao thì có một số cuộc gọi của FreePBX thời gian đáp ứng lên đến gần 700ms so với khoảng 350 của FusionPBX.

Kết luận: Với các kết quả đạt được theo thống kê ở trên, có thể kết quả kiểm thử chưa chính xác hoàn toàn do phụ thuộc vào nhiều yếu tố (môi trường kiểm thử, cấu hình kiểm thử...). Tuy nhiên, tôi có thể kết luận rằng hai tổng đài này đều phù hợp cho giải pháp ban đầu của tôi đưa ra. Để lựa chọn một trong hai tổng đài tiếp tục thực hiện các bước tiếp theo, tôi chọn tổng đài FreePBX do có thời gian đáp ứng trung bình và cuộc gọi không thành công ít hơn so với tổng đài FusionPBX.

55

4.4.2. Đánh giá chất lượng cuộc gọi 4.4.2.1. Mô hình đánh giá 4.4.2.1. Mô hình đánh giá

IP

IP

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

4.4.2.2. Thực hiện đánh giá

Các thành phần trong mô hình đánh giá theo hình 4.5 gồm: Tổng đài FreePBX; máy chủ chạy Solarwinds; các softphone hỗ trợ giao thức báo hiệu SIP; hệ thống tổng đài đang chạy của Tổng cục Thuế với các IP Phone.

Sau khi các hệ thống đã được cài đặt hoàn chỉnh, tôi tiến hành: khai báo và kết nối từ Solarwinds vào CUCM để lấy các thông tin phục vụ đánh giá (từ SNMP và các thông tin từ CDR, CMR); tạo các tài khoản trên FreePBX và thực hiện trunking giữa hai hệ thống tổng đài (CUCM và FreePBX).

Trong phần đánh giá này tôi thực hiện đánh giá theo kịch bản: thực hiện 10 cuộc gọi giữa hai IP Phone trên hệ thống CUCM và thực hiện 10 cuộc gọi từ Softphone trên hệ thống FreePBX đến IP Phone trên hệ thống CUCM; các thông tin thu được sẽ được Solarwinds xử lý để đưa ra điểm chất lượng theo từng cuộc gọi (sử dụng điểm MOS theo bảng 4.3).

4.4.2.3. Kết quả

Chất lượng cuộc gọi được thực hiện giữa hai thiết bị IP Phone trên hệ thống CUCM.

Bảng 4.9. Bảng kết quả cuộc gọi giữa 2 IP Phone Call Origin Call Destination Call Status Jitter (ms) Latency (ms) Packet Loss (%) MOS (1-5) 46468 46336 Success 1 0 0 4,5

56 46468 46509 Success 0 0 0 4,5 46468 46401 Success 0 0 0 4,5 46468 46509 Success 1 0 0 0,0 46468 46803 Success 1 0 0 4,5 46468 46555 Success 0 0 0 4,5 46468 46509 Success 0 0 0 4,5 46468 46509 Success 0 0 0 4,5 46468 46504 Success 0 0 0 4,5 46468 46422 Success 1 0 0 4,5

Chất lượng cuộc gọi được thực hiện giữa softphone trên hệ thống FreePBX và IP Phone trên hệ thống CUCM.

Bảng 4.10. Bảng kết quả cuộc gọi giữa hệ thống CUCM và FreePBX Call Origin Call Destination Call Status Jitter (ms) Latency (ms) Packet Loss (%) MOS (1-5) 1000 46456 Success 3 0 0 4,5 1000 48888 Success 16 0 0 4,5 1000 46468 Success 4 0 0 4,5 1000 46468 Success 4 0 0 0,0 1000 46468 Success 3 0 0 4,5 1000 48888 Success 5 0 0 4,5 1000 48888 Success 5 0 0 4,5 1000 48888 Success 5 0 0 4,5 1000 48888 Success 4 0 0 4,5 1000 48888 Success 3 0 0 4,5

Thông tin các trường theo bảng trên: - Call Origin: số gọi đi.

- Call Destination: số được gọi đến. - Call status: trạng thái cuộc gọi.

- Các tham số đánh giá chất lượng cuộc gọi đính kèm gồm: Jitter, Latency, Packet Loss và điểm đánh giá MOS.

57

Đối với các trường hợp điểm MOS là 0,0 trong bảng 4.9 và bảng 4.10 là các trường hợp mà cuộc gọi chưa đến 8s (khi người nhận bắt đầu nhấc máy) nên chưa được đánh giá.

Căn cứ theo bảng chất lượng cuộc gọi (bảng 4.3) thì các kết quả trên đều đáp ứng tốt về chất lượng cuộc gọi (mức rất hài lòng). Tuy nhiên, việc đánh giá vẫn còn khá hạn chế do chỉ thực hiện kiểm thử trong hệ thống mạng người dùng tại Tổng cục mà chưa qua môi trường mạng hạ tầng truyền thông ngành Tài chính.

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

Trong chương 1, tôi đã đưa ra một số vấn đề còn tồn tại và cần có giải pháp để khắc phục. Trong đó, việc hỗ trợ người dùng (hỗ trợ về ứng dụng, hệ thống phần cứng và phần mềm) tại các Cục Thuế cũng hết sức quan trọng nhưng chưa được đánh giá chính xác chất lượng hỗ trợ. Để giải quyết vấn đề trên, trong phần này tôi dự kiến giải pháp thực hiện như sau:

- Lập danh sách đội hỗ trợ người dùng, có kế hoạch đánh số và quay số cho từng cán bộ hỗ trợ cụ thể. Kế hoạch quay số sẽ đề ra các quy tắc bấm số khi thực hiện các cuộc gọi. Kế hoạch đánh số và quay số sẽ ảnh hưởng tới toàn bộ các thông số, cấu hình định tuyến của hệ thống.

- Tạo các tài khoản (các số điện thoại) cho đội hỗ trợ trên hệ thống FreePBX, kích hoạt tính năng record cho các tài khoản này. Các thông tin chính của bản ghi record trên hệ thống FreePBX được liệt kê theo bảng 4.11.

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

Tên trường Chức năng

Call Date

Đưa ra ngày, tháng, năm của cuộc gọi và thời gian bắt đầu gọi

Recording

Là nơi chưa file được ghi âm, người quản trị có thể click vào file này để nghe lại toàn bộ cuộc hội thoại Source Là số điện thoại gọi đi

Destination Là số điện thoại được gọi đến Duration Khoản thời gian được gọi

- Tiến hành cài đặt các softphone cho đội hỗ trợ theo các số đã được cấu hình. Lên quy trình và hướng dẫn sử dụng softphone cho cán bộ hỗ trợ.

- Thông báo rộng rãi đến toàn bộ Cục Thuế về các đầu số hỗ trợ mới và trình tự giải đáp vướng mắc cũng như cách hỗ trợ của các cán bộ Tổng cục Thuế.

58

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

Nội dung của luận văn này tập trung tìm hiểu các công nghệ, phần mềm mã nguồn mở và các giải pháp về VoIP nhằm mục đích giải quyết trước mắt các vấn đề còn tồn đọng trong hệ thống hạ tầng mạng VoIP của ngành Thuế. Ngoài ra, trong luận văn tôi cũng đã tiến hành cài đặt và thực hiện đánh giá để đưa ra lựa chọn tối ưu cho việc triển khai. Với kết quả đạt được, tôi nghĩ giải pháp này hoàn toàn khả thi và có thể áp dụng tốt tại thời điểm hiện tại nếu được Lãnh đạo Tổng cục và Cục CNTT cho phép triển khai.

Qua việc nghiên cứu, xây dựng và trực tiếp triển khai giải pháp này tôi cũng rút ra được rất nhiều kinh nghiệm và nâng cao kỹ năng công việc cho bản thân. Kết quả đạt được trong luận văn này có thể đáp ứng tốt cho nhu cầu công việc. Tuy nhiên, do quỹ thời gian nghiên cứu không nhiều và kỹ năng nghiên cứu không tốt nên nội dung luận văn này không tránh khỏi những thiếu sót và hạn chế.

Hướng phát triển của luận văn: Hiện tại, theo kế hoạch của Bộ tài chính, trong năm 2016 sẽ hoàn thiện việc xây dựng trung tâm dự phòng thảm họa cho Tổng cục Thuế tại Hà Nội và Hồ Chí Minh. Với kế hoạch này, tôi có thể đưa ra giải pháp phát triển cho luận văn như sau:

- Xây dựng các tổng đài thoại IP tại các trung tâm dự phòng Hà Nội và Hồ Chí Minh.

- Thực hiện kết nối giữa các tổng đài tại trung tâm dữ liệu chính và dự phòng. Việc kết nối sẽ thông qua mạng WAN ngành Tài chính.

- Khi thảm họa xảy ra tại trung tâm dữ liệu chính thì toàn bộ kết nối từ các IP Phone và softphone tại Cục CNTT và các Cục Thuế sẽ được định tuyến vào các tổng đài dự phòng này. Mô hình dự kiến như sau:

59

TÀI LIỆU THAM KHẢO Tiếng Việt

[1]. Nguyễn Thị Quỳnh Trang (2009), Tổng đài Asterisk và công nghệ VoIP, Đồ án

tốt nghiệp, Trường Đại học Bách Khoa Đà Nẵng. Tiếng Anh

[2]. Cisco System. (2008), Cisco Voice over IP (CVOICE), Volume 1, Version 6.0. Cisco System Learning, pp. 12-19

[3]. Cisco System. (2014), Cisco MediaSense Version 10.5 Data Sheet, Cisco

and/or its affiliates, pp. 1

[4]. Charles P.Wright, Olivier Jacques, Richard Gayraud, Robert Day, Many

contributors (21/04/2014). SIPp reference documentation

[5]. Jonathan Davidson, James Peters, Manoj Bhatia, Satish Kalidindi, Sudipto

Mukherjee. Voice over IP Fundamentals, 2nd Edition. Cisco Press.

[6]. Jonathan Levin. (2005), VoIP - Voice over Internet Protocol , Technologeeks,

pp. 49-55

[7]. Solarwinds Incorporated. (1995-2014), VoIP and Network Quality Manager Administrator Guide, Version 4.2, pp.35-41

[8]. Schmooze Com Inc., The FreePBX Project, http://www.freepbx.org and

http://wiki.freepbx.org/display/FD/FreePBX+Distro+Home

[9]. Packetizer. Copyright © 2015, H.323 versus SIP: A Compare,

http://www.packetizer.com/ipmc/h323_vs_sip, Packetizer, Inc.

[10]. The FusionPBX Project. © Copyright 2008-2015, http://www.fusionpbx.com

and http://wiki.fusionpbx.com

[11]. The FreeSWITCH Project, https://freeswitch.org/

[12]. RFC 3261. SIP - Session Initiation Protocol [13]. RFC 2327. SDP - Session Description Protocol

[14]. http://en.wikipedia.org/wiki/Skinny_Call_Control_Protocol [15]. http://en.wikipedia.org/wiki/H.323

Một phần của tài liệu 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ế (Trang 50)

Tải bản đầy đủ (PDF)

(59 trang)