phần mềm OPENIMS như: tạo người dùng mới, thực hiện cuộc gọi nhắn tin giữa các người dùng, kiêm tra các bản tin gửi và nhận từ khối HSS trong các quá trình hoạt động của người dùng và mạng….
4.1 Tạo và đăng ký người dùng mới
Để tạo thêm một người dùng mới trong cơ sở dữ liệu của HSS ta sử dụng giao diện web quản lý của phần mềm FHoSS.. Thông tin người dùng trong FHoSS gồm có các loại nhận dạng và các trường tương ứng bắt buộc sau:
* IMSU (IP Multimedia Subscription) + Tên người dùng
Hình 1.1 Cấu hình thông số IMSU
* IMPI (IP Multimedia Private User Identity) + Nhận dạng cá nhân: ví dụ ha@open-ims.test
+ Chìa khóa an ninh (Secret Key): là một chuỗi ký tự nào đó
Hình 1.2 Cấu hình thông số IMPI
* IMPU (IP Multimedia Public User Identity)
+ Nhận dạng công cộng: ví dụ sip:ha@open-ims.test
+ Thông tin dịch vụ (Service Profile). Thông tin dịch vụ được tạo, chỉnh sửa trong mục SERVCES như đã giới thiệu ở hình 3.7.
+ Loại IMPU (IMPU Type): thường là public_user_identity
Sau khi thiết lập đầy đủ, chính xác các trường bắt buộc trong ba loại nhận dạng trên thì cần phải liên kết chúng lại với nhau
Hình 1.3 Cấu hình thông số IMPU
4.2 Cơ sở dữ liệu người dùng trên mysql
Cơ sở dữ liệu trong phần mềm FHoSS là cơ sở dữ liệu quan hệ được xây dựng bao gồm 24 bảng như hình dưới đây:
Hình 1.1 Cơ sở dữ liệu trong FhoSS
Có thể đưa ra sơ đồ thực thể liên kết rút gọn bao gồm một số bảng cơ bản và các trường chính trong đó:
Hình 1.2 Sơ đồ thực thể liên kết rút gọn của cơ sở dữ liệu trong FHoSS
Ta có thể đối chiếu hình trên với hình 1.10: Mối liên hệ giữa nhận dạng cá nhân và nhận dạng công cộng trong Release 6, hình 2.13: Cấu trúc thông tin người dùng và hình 2.14: Cấu trúc tiêu chuẩn lọc ban đầu:
- Mỗi người dùng là một thuê bao IMS (bảng imsu)
- Quan hệ giữa bảng imsu và bảng impi là 1 - ∞ vì mỗi người dùng có thể có nhiều nhận cá nhân (bảng impi).
- Mỗi người dùng cũng có thể có nhiều nhận dạng cá nhân (bảng impu): Do đó quan hệ giữa bảng impi và bảng impu là quan hệ ∞ - ∞. Đúng như theo lý thuyết cơ sở dữ liệu quan hệ, để kết nối giữa hai bảng ∞ - ∞ cần phải có một bảng trung gian (bảng impi_impu).
- Quan hệ giữa bảng sp và bảng impu là quan hệ 1 - ∞ vì như trong hình 2.13 mỗi một Service Point (bảng sp) có thể nằm trong nhiều nhận dạng người dùng công cộng (bảng impu).
- Cũng theo hình 2.13 nhiều Service Point có thể nằm trong một Initial Filter Criteria (bảng ifc) và ngược lại. Như vậy quan hệ giữa bảng sp và bảng ifc là quan hệ ∞ - ∞, liên kết giữa chúng thông quan bảng sp_ifc. - Theo hình 2.14 một IFC chỉ có thể có nhiều nhất một Trigger Point (bảng
tp), quan hệ giữa bảng ifc và bảng tp là quan hệ 1 - 1.
- Quan hệ giữa bảng application_server và bản ifc là 1 - ∞ vì địa chỉ của một máy chủ ứng dụng có thể nằm trong nhiều IFC khác nhau.
- Trong một Trigger Point có thể có nhiều Service Point Trigger nên quan hệ giữa bảng tp và bảng spt là quan hệ 1 - ∞.
4.3 Cấu hình các dịch vụ
Trang cấu hình dịch vụ cho phép cấu hình các mục sau: * Service Profiles : Tên các dịch vụ
* Application Servers: Máy chủ ứng dụng tương ứng với bảng application_server Ví dụ các máy chủ ứng dụng đã được cấu hình và chạy thử:
Hình 1.1 Một số máy chủ ứng dụng đã khởi tạo và chạy thử
Trong đó:
+ default_as là máy chủ ứng dụng mặc định
+ media_as là máy chủ ứng dụng hỗ trợ dịch vụ hội thảo
+ iptv là máy chủ ứng dụng cho dịch vụ iptv (xem tv qua mạng IP) * Trigger Points: Điểm kích hoạt, tương ứng với bảng tp:
Hình 1.2 Một số điểm kích hoạt đã tạo
+ c2d_tp: điểm kích hoạt cho dịch vụ click to dial * Initial Filter Criteria: tương ứng với bảng ifc
Hình 1.3 Một số tiêu chuẩn lọc ban đầu đã được tạo
+ cf_ifc: tiêu chuẩn lọc ban đầu cho dịch vụ conference + c2d_ifc: tiêu chuẩn lọc ban đầu cho dịch vụ click to dial
4.4 Thống kê các bản tin Diameter trong quá trình đăng ký
Hệ thống dựng lên bao gồm:
+ Máy 1 (192.168.7.97): cài P-CSCF, I-CSCF và S-CSCF
+ Máy 2 (192.168.7.98): cài FHoSS, OpenIMS Client đăng ký người dùng bob@open-ims.test
Về lý thuyết quá trình đăng ký diễn ra như trong hình 2.8 và hình 2.9. Ta thấy đầu tiên client gửi bản tin đăng ký sip (7) tới I-CSCF.
Sau khi nhận được đăng ký, P-CSCF sẽ chuyển tiếp bản tin này tới I-CSCF (quá trình bắt gói tin được thực hiện tại Máy 2 nên không nhìn thấy bản tin chuyển tiếp này)
Khi nhận được bản tin đăng ký, I-CSCF sẽ gửi bản tin Diameter UAR tới FHoSS (8) để xác nhận xem người dùng bob@open-ims.test sẽ được S-CSCF nào phục vụ.
FHoSS trả lời bằng bản tin UAA (10) thông báo cho I-CSCF biết địa chỉ của S- CSCF phục vụ người dùng đang đăng ký.
Hình 1.1 Một số bản tin trong quá trình đăng ký
Nhận được bản tin UAA, I-CSCF biết được địa chỉ của S-CSCF nên chuyển bản tin đăng ký người dùng tới S-CSCF.
Sau khi nhận được bản tin đăng ký, S-CSCF tiến hành chứng thực người dùng, tuy nhiên vì đây là lần đăng ký đầu tiên nên S-CSCF chưa có các véc tơ chứng thực, do đó nó gửi bản tin MAR (11) tới HSS để tải véc tơ chứng thực về.
HSS gửi các véc tơ chứng thực về cho S-CSCF qua bản tin MAA (12).
S-CSCF gửi bản tin 401 unauthorized về cho người dùng, yêu cầu thông tin chứng thực từ người dùng (14)
Client bắt đầu đăng ký lại, các bản tin tương tự như trên: (17), (18) và (19)
Trong bản tin đăng ký lần này có chứa các thông tin chứng thực, khi S-CSCF so sánh thông tin đó với các véc tơ chứng thực tải về từ HSS. Nếu quá trình chứng thực thành công, S-CSCF sẽ gửi bản tin SAR (20) tới HSS thông báo đã chứng thực người dùng. HSS gửi bản tin SAA trả lời (23).
KẾT LUẬN