94 Trang 9 7 THUẬT NGỮ VIẾT TẮT1Viế ắt t t Tiếng AnhTiếng Việt AAA Authentication, Authorization and Accounting Nhận thực, trao quyền và thanh toán AES Advanced Encryption Standard Chuẩ
KIẾN TRÚC IMS
Giới thiệu chung
Kiến trúc IMS không được tổ chức theo các nút mà dựa vào các chức năng, tạo thành một tập hợp các chức năng liên kết thông qua các giao diện Các chức năng này có thể được kết hợp trong một nút hoặc tách ra để thực hiện ở hai nút hoặc nhiều hơn Thông thường, các nhà cung cấp thường triển khai một chức năng cho mỗi nút riêng biệt.
SIP-AS OSA-SCS IM-SSF
Hình 1 : Tổng quan kiến trúc IMS
Hình vẽ thể ệ hi n t ng quan ki n trúc IMS Trong hình vổ ế ẽ này các giao diện báo hiệu trong IMS được th hi n bằng hai hoặc ba chữ ể ệ cái.
Bên phải hình vẽ là các thiết bị IMS, trong khi phía dưới là thiết bị di động, thường được gọi là thiết bị người dùng UE Các thiết bị đầu cuối IMS kết nối tới mạng chuyển mạch gói thông qua liên kết vô tuyến.
The system supports various access methods and devices, including Personal Digital Assistants (PDAs) and computers These devices can connect via ADSL or WLAN.
Phần còn l i cạ ủa hình vẽ ch ra các nút chứỉ c năng khác trong kiến trúc lõi của IMS bao g m: ồ
+ Cơ sở ữ ệ d li u người dùng: HSS (Home Subcriber Servers) và SLF (Subcriber Location Function)
+ Chức năng điều khiển phiên/ cuộc gọi: CSCF (Call /Sesion Control Function)
The Media Resource Function (MRF) encompasses the Media Resource Function Controller (MRFC) and the Media Resource Function Processor (MRFP), which are essential components for managing media resource functionality.
+ BGCF (Breakout Gateway Control Function)
+ PSTN gateway bao g m SGW (Signalling Gateway), MGCF (Media ồ Gateway Controller Function) và MGW (Media Gateway)
2 Chức năng điều khiển phiên/cuộc gọi CSCF(Call/Session Control Function)
CSCF là một SIP server Nó là thành phần cơ bản nhất trong kiến trúc IMS
CSCF xử lý báo hi u SIP Có ba kiểu khác nhau của CSCF: ệ
Chức năng điều khi n phiên/cu ể ộc gọi CSCF(Call/Session Control Function)
Mỗi CSCF có chức năng đặc biệt, góp phần quan trọng vào việc định tuyến bản tin SIP Bên cạnh đó, chúng cũng có khả năng xử lý thông tin tính cước, hỗ trợ chức năng tính cước ngoài tuyến hiệu quả.
P-CSCF là điểm liên lạc đầu tiên giữa thiế ị đầt b u cuối và mạng IMS Trong mô hình c a SIP thì Pủ -CSCF đang làm việc như một oubound/inbound SIP proxy server Tất cả các bản tin SIP được khởi tạo b i mộở t thi t b u ế ị đầ cuối IMS ho c gửặ i đến thi t bế ị đầ u cuối IMS đều phải đi qua P-CSCF P- CSCF chuyển tiếp các bản tin SIP: yêu c u và hầ ồi đáp theo các hướng phù hợp hoặc là đi tới thiết bịIMS hoặc là tới mạng IMS
P-CSCF được chỉ định cho các thi t bế ị đầ u cu i IMS trong quá trình ố đăng ký và không thay đổi trong quá trình này
P-CSCF bao gồm nhiều chức năng khác nhau và một trong số chúng liên quan tới b o mả ật Nó thiết l p mậ ộ ốt s liên kế ảt đ m b o IPsec với các thiết ả b ị đầu cuối IMS Những liên kết bảo mật IPsec này đảm b o s toàn v n thực ả ự ẹ thể, ví dụ như kh năng đả ể dò tìm n i dung củộ a b n tin có bả ị thay đổi từ khi nó đượ ạc t o ra hay không
Khi P-CSCF xác thực người dùng, các nút khác trong mạng không cần thực hiện thêm các chứng thực khác, vì đã tin tưởng vào P-CSCF Ngoài việc xác nhận người dùng, P-CSCF còn có vai trò cung cấp dịch vụ cho cá nhân và quản lý các bản ghi tính cước.
Một chức năng quan trọng của P-CSCF là kiểm tra tính chính xác của các bản tin yêu cầu SIP được gửi từ thiết bị đầu cuối trong hệ thống IMS Chức năng này đóng vai trò ngăn chặn việc gửi đi các bản tin SIP không chính xác, từ đó đảm bảo tính ổn định và hiệu quả của mạng.
2 Tham kh ả o t ừ “ The IMS: IP Multimedia Concepts and Services in the Mobile Domain”.
P-CSCF bao gồm một bộ ph n nén và giải nén các bản tin SIP (thi t bậ ế ị đầu cuối IMS cũng bao gồm chức năng này) B n tin SIP đôi khi có thả ể ấ r t lớn Trong khi gửi một bản tin qua một k t nế ối băng thông rộng ch m t một ỉ ấ thời gian ng n thì viắ ệc gửi một b n tin SIP qua mả ột kênh băng thông h p, như ẹ một kết nối vô tuyến chẳng hạn, sẽ ấ m t một vài giây Cơ chế dùng để rút ng n ắ thời gian truyền mộ ảt b n tin là nén b n tin l i, truyền qua liên kết vô tuyến và ả ạ giải nén bên phía nhận
P-CSCF có thể bao gồm một PDF PDF cấp quyền sử ụng media và d quản lý QoS trên mặt phẳng media
P-CSCF đồng thời tạo ra các thông tin tính cướ ớc t i các nút thu th p ậ thông tin tính cước
Mục tiêu của việc mở rộng mạng IMS với nhiều P-CSCF là tạo ra sự dư thừa nhằm phục vụ cho các tình huống dự phòng Mỗi P-CSCF sẽ phục vụ một số lượng thiết bị đầu cuối IMS, tùy thuộc vào dung lượng của nó.
P-CSCF có thể được đặt tại mạng khách hoặc mạng chủ Trong trường hợp mạng chuyển mạch gói d a trên GPRS thì P-ự CSCF luôn đặt trong cùng một mạng với GGSN Vì vậy GGSN và P-CSCF có thể cùng đặ ại mạng t t khách hoặc tại mạng chủ
I-CSCF là SIP proxy được đặt tại biên của miền quản trị Địa chỉ ủ c a I- CSCF luôn được li t kê trong các bảệ n ghi DNS c a mi n Khi m t SIP server ủ ề ộ tuân theo các thủ ụ t c SIP để tìm ch ng SIP tiếp theo cho mặ ột bản tin SIP sẽ nhận được địa ch c a I-CSCF trong miền đích ỉ ủ
Ngoài chức năng là một SIP server, I CSCF còn có m- ột giao di n tới ệ SLF và HSS Giao di n này d a trên giao th c Diameter Qua giao di n này Iệ ự ứ ệ -
3 Tham kh ả o t ừ “ The IMS: IP Multimedia Concepts and Services in the Mobile Domain”.
CSCF truy vấn các thông tin về ị v trí của ngư i dùng và đờ ịnh tuyến các bản tin SIP tớ ịi đ a chỉ phù h p ợ
I-CSCF còn có chức năng mã hóa một ph n bản tin SIP đang chứa ầ đựng nh ng thông tin nh y c m v miữ ạ ả ề ền, như số ợ lư ng các server trong mi n, ề tên DNS và dung lượng c a chúng ủ
Một mạng IMS thường bao gồm nhiều I CSCF cho mụ- c đích mở rộng và tạo dư thừa
I-CSCF thường nằm tại mạng chủ, mặc dù trong m t sộ ố trường hợp đặc bi t nó có thệ ể được đặ ạt t i m ng khách ạ
S-CSCF là nút trung tâm trong mặt phẳng báo hi u Ngoài chệ ức năng là một SIP server, S-CSCF còn đóng vai trò là một SIP registrar Nó duy trì một gắn kết giữa vị trí của ngư i dùng (như đờ ịa ch IP c a thi t b u cu i mà ỉ ủ ế ị đầ ố ngư dùng đăng nhời ập) và địa ch SIP cỉ ủa người dùng trong bản ghi
Giống như I-CSCF, S-CSCF cũng đồng thời thực hiện giao di n tệ ới HSS để ự th c hi n các mệ ục đích sau:
+ Tải về các vector ch ng thực củứ a ngư i dùng đang truy nhờ ập vào mạng S CSCF sử ụng các vector này để chứng thự- d c người dùng
+ Tải về ồ h sơ người dùng từ HSS H ồ sơ người dùng bao gồm h ồ sơ dịch vụ
+ Thông báo cho HSS rằng S-CSCF này sẽ phục vụ người dùng trong khoảng thời gian đăng ký
Tất cả các tín hiệu SIP được gửi và nhận bởi thiết bị đầu cuối IMS đều đi qua S-CSCF S-CSCF có nhiệm vụ giám sát từng bản tin SIP và quyết định liệu tín hiệu đó sẽ đi qua một hoặc nhiều máy chủ ứng dụng, hoặc sẽ được định tuyến đến đích cuối cùng.
4 Tham kh ả o t ừ “ The IMS: IP Multimedia Concepts and Services in the Mobile Domain”.
S-CSCF đóng vai trò quan trọng trong việc cung cấp chức năng định tuyến cho tín hiệu SIP Khi người dùng gọi đến một số điện thoại thay vì một SIP URI, S-CSCF sẽ thực hiện dịch vụ chuyển đổi địa chỉ, thường dựa trên công nghệ DNS E.164 Number Translation (IETF).
S-CSCF đồng thời thi hành các chính sách của nhà điều hành m ng Ví ạ d mụ ột người dùng không có quyề đển thiết l p mậ ột lo i phiên c th ạ ụ ể như phiên video chẳng hạn Nói cách khác, S-CSCF ngăn chặn người dùng thực hiện những dịch vụ không được cho phép
S-CSCF luôn luôn nằm tại mạng chủ
2.2 Cơ sở dữ liệu HSS và SLF 5
HSS và SLF là hai cơ sở ữ ệ d li u chính trong ki n trúc IMS.ế
HSS lưu trữ dữ liệu cho tất cả các thuê bao và các thông tin liên quan đến dịch vụ của IMS Dữ liệu được lưu trữ trong HSS bao gồm nhận dạng, thông tin đăng ký thuê bao, tham số truy nhập và thông tin kích hoạt dịch vụ Nhận dạng gồm hai loại: nhận dạng người dùng công cộng và nhận dạng người dùng cá nhân Nhận dạng cá nhân được sử dụng cho mục đích đăng ký và cấp quyền, trong khi nhận dạng công cộng phục vụ liên lạc giữa người dùng Các tham số truy nhập IMS được khởi tạo để thiết lập một phiên, bao gồm các thông số như chứng thực người dùng, cấp quyền chuyển vùng và tên của S-CSCF phụ trách người dùng Thông tin kích hoạt dịch vụ cho phép thực hiện các dịch vụ SIP.
HSS cũng bao gồm m t sốộ các chức năng của b ộ đăng ký vị trí ch ủ (HLR) và trung tâm nhận thực (AuC)
5 Tham kh ả o “ The IMS: IP Multimedia Concepts and Services in the Mobile Domain”.
Chức năng HLR/AuC cho miền chuyển mạch kênh
Chức năng HLR/AuC cho miền chuyển mạch gói
Hình 2 : Cấu trúc của HSS
Nguyên lý làm việ c c a ki n trúc IMS 30 ủ ế 1 Quá trình đăng ký
Quá trình nhận dạng
Mục này sẽ khám phá các loại nhận dạng người dùng, bao gồm nhận dạng công cộng, thuê bao cá nhân, và sự kết hợp giữa nhận dạng công cộng với thiết bị người dùng để định tuyến toàn cầu Chúng ta cũng sẽ đề cập đến dịch vụ công cộng và các thực thể trong IMS, đồng thời giải thích mối quan hệ giữa các loại nhận dạng người dùng khác nhau.
4.1 Nhận dạng người dùng công cộng
Trong mạng IMS, các nhận dạng người dùng được gọi là các nhận dạng công cộng, đóng vai trò quan trọng trong việc yêu cầu giao tiếp với những người dùng khác Những nhận dạng này có thể được công khai rộng rãi, chẳng hạn như trên các trang web hay trong danh thiếp cá nhân.
Người dùng IMS có khả năng khởi tạo và nhận kết nối từ nhiều mạng khác nhau, bao gồm mạng GSM và Internet Để truy cập vào phần CS (Circuit Switched), định dạng nhận dạng người dùng công cộng cần phải phù hợp với tiêu chuẩn viễn thông, chẳng hạn như +358501234567 Tương tự, khi có yêu cầu kết nối từ người dùng Internet, định dạng nhận dạng công cộng cũng phải tuân thủ quy tắc nhất định, ví dụ như joe.doe@example.com.
H ệ thống IMS đưa ra những yêu cầu dư i đây cho nhớ ận dạng người dùng công cộng [ 3GPP TS23.228, TS 23.003]:
- Nhận dạng người dùng công c ng s ph i s d ng các d ng, ho c là ộ ẽ ả ử ụ ạ ặ kiểu nh n dậ ạng của SIP (URI) hoặc là dạng thoại URL
- Có ít nhất 1 nhận dạng người dùng công cộng đư c lưu trợ ữ trong ứng dụng ISIM.
- UE không có khả năng sửa chữa nhận dạng ngư i dùng đư c lưu trờ ợ ữ trong ISIM
Để sử dụng một nhận dạng người dùng cho các phiên IMS và các thủ tục ngoài phiên như nhắn tin, đăng ký hoặc cảnh báo, người dùng cần phải thực hiện đăng ký trước.
- Có thể đăng kí đa nhận dạng người dùng công cộng thông qua duy nhất 1 UE đăng kí
- Mạng sẽ không xác nhận các nhận dạng người dùng công c ng trong ộ khi đăng kí
Ví dụ ề v nhận dạng người dùng:
Dạng SIP URI: sip:joe.doe@ims.example.com
4.2 Nhận dạng người dùng cá nhân
Nhận dạng người dùng cá nhân là một định danh duy nhất toàn cầu, được xác định bởi hệ thống vận hành mạng thường trú Định danh này có thể được sử dụng trong mạng thường trú để nhận diện người dùng một cách độc nhất từ góc độ của mạng.
Mỗi thuê bao IMS không giống như nhận dạng người dùng công cộng, mà có một định danh cá nhân riêng, được xác định theo chuẩn của NAI (Network Access Identifier) [RFC 2468].
Mục đích của nhận dạng cá nhân là xác định và xác thực thuê bao Thông tin này được lưu trữ trong một thẻ thông minh, giúp người dùng không cần phải nhập lại thông tin mỗi khi cần xác minh danh tính.
H ệ thố g IMS đưa ra những yêu cầu cụn thể cho nhận dạng người dùng cá nhân như sau:
- Nhận dạng cá nhân theo chuẩn NAI định nghĩa trong [RFC 2468]
- Nhận dạng cá nhân ch a tứ ất cả các yêu cầu đăng kí từ UE đến mạng thường trú
- Nhận dạng cá nhân được xác thực chỉ trong quá trình đăng kí của người dùng
- S-CSCF cần lấy và lưu trữ nhận dạng người dùng cá nhân trong quá trình đăng kí và d ng đăng kí.ừ
- Nhận dạng cá nhân không sử ụ d ng trong định tuyến các gói tin SIP.
- Nhận dạng cá nhân được phân phát cố định đến 1 User và lưu trữ an toàn trong ISIM
- UE không thể ửa chữa nhận dạng cá nhân s
- HSS cần phải lưu thông tin nhận dạng cá nhân.
Ví dụ đị nh d ng cạ ủa nhận dạng cá nhân theo NAI:
Private_user1@home1.operator.net
4.3 Quan hệ giữa nhận dạng công cộng và nhận dạng cá nhân Ở đây sẽ đưa ra 2 ví dụ cho chúng ta biết các nhận dạng khác nhau có quan hệ ớ v i nhau như thế nào Trong ví dụ, Joe đang làm cho một công ty ôtô và sử ụ d ng một thiết bị đầ u cuối cho cả công việc và đời sống cá nhân Khi làm việc anh ta sử d ng hai nh n dụ ậ ạng người dùng công cộng là sip:joe.smith@brandnewcar.com và tel:+35850124567 Trong đời sống cá nhân anh ta sử dụng hai nhận dạng người dùng công cộng là: sip:joe.smith@ims.example.com và tel:358503334444
Người dùng Joe có thông tin dịch vụ được lưu trong hai gói khác nhau Gói đầu tiên chứa thông tin về các nhận dạng công việc của anh, được truy xuất từ HSS đến S-CSCF khi cần thiết, như khi Joe đăng ký nhận dạng người dùng công cộng cho công việc hoặc khi S-CSCF cần thực hiện ngừng đăng ký dịch vụ Gói thứ hai chứa thông tin về các nhận dạng đời sống tư, cũng được truy xuất đến S-CSCF từ HSS khi cần Hình 3-4 minh họa mối liên hệ giữa nhận dạng người dùng cá nhân, nhận dạng công việc và các gói dịch vụ của Joe.
Hình 9 : Mối quan hệ giữa các nhận dạng người dùng
5 Module nhận dạng thuê bao ISIM
Trong mạng IMS, ISIM là m t ộ ứng dụng chạy trên thẻ thông minh UICC (Universal Integrated Circuit Card) - một loại thẻ có thể tháo ra hoặc
UICC là một thành phần quan trọng trong thiết bị ủ của người dùng, với dung lượng lớn khoảng vài trăm Kb, giúp bảo mật thông tin cá nhân UICC có khả năng chạy nhiều ứng dụng như SIM cho mạng GSM, USIM cho mạng UMTS và ISIM cho mạng IMS ISIM lưu trữ dữ liệu thuê bao từ nhà mạng, chủ yếu được sử dụng khi thiết bị kết nối vào mạng IMS.
- Thông tin nh n dậ ạng cá nhân của người dùng, dùng để xác th c các ự thông tin về người dùng khi hòa mạng IMS
- Thông tin nhận dạng công c ng cộ ủa người dùng, dùng trong quá trình đăng ký hoặc liên lạc với người dùng khác
- Tên miền của mạng thư ng trú, dùng trong quá trình đăng ký để địờ nh tuyến tới mạng thường trú của người dùng.
Các dữ ệ li u qu n trả ị bao g m nhi u d liồ ề ữ ệu đượ ử ục s d ng b i nhà m ng ở ạ hoặc nhà sản xuấ ểt đ thực hiện quá trình tự độ ng kiểm tra
- Luật tham chiếu truy nhập g m các thông tin v s nh n d ng cá nhân ồ ề ố ậ ạ để ể ki m tra trong quá trình truy nh p vào các ng dậ ứ ụng
- Địa chỉ ủa P c -CSCF dùng khi phương pháp truy nhập không hỗ trợ P- CSCF động
- Các thông số ảo mật đượ ử b c s dụng trong quá trình xác thực
Trong giai đoạn đầu triển khai, thiết bị IMS yêu cầu phải có ISIM để truy cập vào mạng IMS Tuy nhiên, hiện nay, các nhà mạng đã cho phép thiết bị sử dụng SIM và USIM cũng có khả năng kết nối với mạng IMS.
IMS cho phép triển khai mô hình tính cước mới, giúp nhà khai thác dịch vụ có thể áp dụng các mô hình kinh doanh đa dạng Một trong những lợi thế chính của IMS là khả năng tính cước dựa vào phiên hoặc dịch vụ, mang lại lợi ích cho người dùng cuối Chẳng hạn, trong các game trực tuyến, người chơi cần có tiền trong tài khoản game để sử dụng dịch vụ, hoặc trong các phiên đa phương tiện, người dùng phải trả phí định kỳ cho dịch vụ Ngoài ra, cũng có thể tính cước dựa vào độ dài phiên hoặc số byte được truyền đi, tạo ra nhiều lựa chọn cho người dùng.
Trong dịch vụ trả sau, IMS cần hỗ trợ cơ chế tính cước offline, cho phép tính cước mà không làm ảnh hưởng đến các dịch vụ đang sử dụng Người dùng thường nhận hóa đơn hàng tháng với các mục phí cụ thể Ngược lại, dịch vụ trả trước yêu cầu tính cước online, nghĩa là IMS phải sử dụng hệ thống tính cước online (OCS) trước khi người dùng có thể sử dụng dịch vụ OCS hoạt động trong thời gian thực, tương tác với tài khoản người dùng để kiểm soát và theo dõi chi phí liên quan đến dịch vụ.
Mạng IMS được cấu hình để phát hiện các điều kiện kích hoạt tính cước Khi phát hiện, IMS sẽ tổng hợp thông tin cần thiết từ yêu cầu SIP và các yêu cầu cho phép từ hệ thống tính cước.
8 Tham kh ả o t ừ “ The IMS: IP Multimedia Concepts and Services in the Mobile Domain ”.
Để xử lý yêu cầu SIP, hệ thống sẽ gửi thông tin liên quan đến tính cước để tạo ra CDR (Charging Detail Record) cho việc tính cước offline Kích hoạt tính cước có thể bao gồm yêu cầu khởi tạo phiên, thay đổi phiên, hoặc kết thúc phiên, cũng như bất kỳ bản tin SIP nào như MESSAGE, PUBLISH, SUBSCRIBE Hệ thống có khả năng kích hoạt dựa trên các tiêu đề SIP hoặc thông tin SDP Dựa trên thông tin nhận được, hệ thống sẽ tính cước online cho người dùng hoặc chuyển các CDR tới hệ thống thanh toán.
Tính cước
IMS cho phép triển khai mô hình tính cước mới, giúp nhà khai thác dịch vụ có thể áp dụng nhiều mô hình kinh doanh khác nhau Một trong những lợi thế chính của IMS là khả năng tính cước dựa vào phiên, sự kiện hoặc dịch vụ, mang lại lợi ích cho người dùng cuối Cụ thể, trong các game trực tuyến, người điều hành có thể cung cấp dịch vụ trả trước, yêu cầu người chơi nạp tiền vào tài khoản game để sử dụng dịch vụ Ngoài ra, dịch vụ trả sau trong các phiên đa phương tiện cũng yêu cầu người dùng thanh toán định kỳ cho dịch vụ sử dụng, chẳng hạn như hàng tháng Bên cạnh đó, tính cước có thể dựa vào độ dài phiên hoặc số byte được truyền đi trong tin nhắn cơ sở phiên.
Trong dịch vụ trả sau, IMS cần hỗ trợ cơ chế tính cước offline, nơi thông tin tính cước được tổng hợp sau phiên mà không ảnh hưởng đến các dịch vụ đang sử dụng Người dùng thường nhận hóa đơn hàng tháng với các mục phí cụ thể Ngược lại, dịch vụ trả trước yêu cầu tính cước online, đòi hỏi mạng IMS phải xem xét hệ thống tính cước online (OCS) trước khi cho phép người dùng sử dụng dịch vụ OCS hoạt động trong thời gian thực để quản lý tài khoản người dùng và theo dõi chi phí liên quan đến dịch vụ.
Mạng IMS được cấu hình để phát hiện các điều kiện kích hoạt tính cước Khi phát hiện, IMS sẽ tổng hợp thông tin từ yêu cầu SIP và các yêu cầu cho phép từ hệ thống tính cước.
8 Tham kh ả o t ừ “ The IMS: IP Multimedia Concepts and Services in the Mobile Domain ”.
Để xử lý yêu cầu SIP trực tuyến, hệ thống cần gửi thông tin liên quan đến việc tính cước để tạo ra CDR (Charging Detail Record) cho việc tính cước offline sau này Kích hoạt tính cước có thể xảy ra trong các tình huống như khởi tạo phiên, thay đổi phiên, hoặc kết thúc phiên, cũng như trong bất kỳ bản tin SIP nào như MESSAGE, PUBLISH, SUBSCRIBE Hơn nữa, việc kích hoạt cũng có thể liên quan đến các tiêu đề SIP hoặc thông tin SDP Dựa trên thông tin nhận được, hệ thống sẽ xử lý tín dụng từ tài khoản người dùng (tính cước online) hoặc chuyển các CDR đến hệ thống thanh toán.
Hình vẽ dưới đây minh họa cấu trúc của hệ thống tính cước trong IMS Phần bên trái thể hiện mô hình tính phí offline, trong khi phần bên phải mô tả quy trình tính phí online.
Hình 10 : Kiến trúc hệ thống tính cước của IMS
Hệ ố th ng IMS xử lý báo hiệu SIP để kết nối với hệ thống tính phí offline, như trong trường hợp của CDF – Charging Data.
Chức năng Diameter đơn dựa trên điểm tham chiếu Rf, cho phép CDF nhận yêu cầu Diameter từ các thực thể mạng truy cập CDF sử dụng thông tin từ nhiều nguồn để tạo ra các CDR, sau đó chuyển chúng tới Charging Gateway Function (CGF) qua điểm tham chiếu Ga Cuối cùng, CGF xử lý các CDR nhận được và truyền các CDR cuối cùng tới hệ thống thanh toán qua điểm tham chiếu Bx.
Trong hệ thống IMS, chỉ có ba thực thể chính (AS, MRFC, S-CSCF) tham gia vào việc tính cước online Tuy nhiên, S-CSCF không thể liên hệ trực tiếp với OCS do thiết kế không tối ưu trong phiên bản Release 5 IMS-GWF (IMS Gateway Function) thường sử dụng giao thức chuyển đổi cần thiết OCS hỗ trợ hai điểm tham chiếu từ các thực thể mạng khác SGSN sử dụng CAP (CAMEL Application Part) và các thực thể còn lại sử dụng Diameter qua điểm tham chiếu Ro Tương tự như CGF trong hệ thống tính cước, OCS cũng có khả năng phát sinh các CDR bên cạnh việc kiểm soát điều khiển tín dụng.
Hệ thống IMS hoạt động thông qua nhiều thực thể khác nhau, với việc khởi động sớm giúp các thực thể này có khả năng tự động tạo ra thông tin tính cước Mỗi thực thể có chức năng tính cước được gọi là CTF (Charging Trigger Function), đóng vai trò quan trọng trong việc nhận diện các sự kiện kích hoạt tính cước như bắt đầu, thay đổi hoặc kết thúc phiên IMS, gửi tin nhắn, đăng ký sự kiện và quảng bá thông tin presence Khi có điều kiện kích hoạt, CDF (Charging Data Function) sẽ tổng hợp thông tin tính cước từ các tín hiệu báo hiệu và gửi thông tin tính cước offline tới CDF thông qua ACRs (Diameter Accounting Requests) qua giao tiếp Rf, bao gồm nhiều thông tin liên quan đến các sự kiện kích hoạt như yêu cầu INVITE, MESSAGE, SUBSCRIBE và địa chỉ nhóm gọi.
CDF sử dụng ACA-Diameter Accounting Answer để công nhận yêu cầu nhận được Trong trường hợp của phiên IMS, có ít nhất hai cặp ACR/ACA được gửi (bao gồm bắt đầu và kết thúc phiên) ACR cũng có thể được sử dụng nếu các thuộc tính phiên bị thay đổi, chẳng hạn như khi các thành phần media được thêm vào hoặc gỡ bỏ, codec của thành phần media và băng thông thay đổi Trong trường hợp chỉ có một người duy nhất trao đổi trên mạng (ví dụ, gửi tin nhắn tức thời), thì chỉ cần một ACR/ACA là đủ.
Trước khi tiến hành thanh toán và gửi hóa đơn tới người dùng, cần xem xét các bước tiếp theo, bao gồm việc chuyển CDRs từ CDF sang CGF CGF đóng vai trò quan trọng vì nhiều CDF có thể tham gia vào sự kiện phiên, cho phép IMS truy cập thông tin tính cước từ các CDF khác, như trong trường hợp chuyển vùng hoặc do cấu hình CGF sẽ xác nhận, củng cố và tiền xử lý CDR, bao gồm việc lọc các trường không cần thiết và thêm thông tin điều hành, đồng thời có khả năng tương quan các CDR khác trước khi gửi chúng tới hệ thống thanh toán.
Trong hình 3.13, người dùng gửi yêu cầu đăng ký tới AS, với giả thiết S-CSCF và AS sử dụng cùng CDF (CDF#2) trong khi P-CSCF sử dụng CDF (CDF#1) Yêu cầu đăng ký nhằm tìm người là thành viên của nhóm POC Trong bước 1-3, yêu cầu SUBSCRIBE được chuyển từ UE tới AS Trong bước 4-6, CTFs trong các thực thể dò tìm tính cước, tạo ACR và gửi tới CDF Bước 7-8, CDFs gửi CDRs thích hợp tới CGF, sau đó chuyển CDR tới hệ thống thanh toán CDRs từ CDF tới CGF được vận chuyển qua các yêu cầu Data Record Transfer trong GPRS Tunnelling Protocol, chứa các chức năng tính cước (GTP) Điều này cho phép CDF#2 tự động tạo CDR đơn lẻ từ thông tin tính cước nhận được và cho phép CGF thu thập CDRs nhận được, gửi CDR đơn lẻ tới hệ thống thanh toán.
Hình 11 : Ví dụ về tính cước offline
Mục đích của tính cước online là kiểm soát tín dụng trước khi sử dụng dịch vụ hoặc tài nguyên IMS Có sự khác biệt giữa hai mô hình: ghi nợ trực tiếp và
Trong ghi nợ trực tiếp, thực thể IMS liên lạc với OCS để yêu cầu cấp phép sử dụng dịch vụ và tài nguyên OCS sử dụng chức năng đánh giá nội bộ nhằm tìm ra bản kê giá phù hợp dựa trên thông tin nhận được, nếu chi phí không được nêu trong yêu cầu Sau khi phân tích bản kê giá và giá cả, OCS kiểm tra tài khoản người dùng để xác định mức tín dụng Nếu đủ, OCS sẽ trừ một số tiền hợp lý từ tài khoản của người dùng để đáp ứng yêu cầu từ thực thể IMS Trong mô hình dự trữ đơn vị, OCS nhận yêu cầu điều khiển tín dụng từ IMS và sử dụng chức năng đánh giá nội bộ để xác định giá dịch vụ mong muốn, dựa trên thông tin cụ thể từ IMS, nếu chi phí không được nêu trong yêu cầu OCS sẽ dự trữ một số tiền phù hợp từ tài khoản người dùng để đáp ứng các yêu cầu tài nguyên.
Khi thực thể IMS yêu cầu tài nguyên, thời gian hoặc dữ liệu sẽ được cấp cho người dùng Sau khi tài nguyên được tiêu thụ hoặc dịch vụ hoàn thành, IMS sẽ thông báo cho OCS về số tài nguyên đã sử dụng OCS sẽ trừ số tiền tương ứng từ tài khoản người dùng Nếu tất cả tài nguyên đã cấp được tiêu thụ, OCS có thể nhận yêu cầu tiếp theo từ IMS, và trong trường hợp này, OCS cần xác thực tín dụng mới.
GIỚ I THI U PH N M M OPENIMSCORE CỦA FOKUS 48 Ệ Ầ Ề 1 Giới thiệu chung
Các thành phần trong OpenIMSCore
2.1 Các CSCFs (Call Session Control Function)
OpenIMS CSCFs được phát triển dựa trên SIP Express Router (SER), cho phép hoạt động như máy chủ đăng ký SIP, máy chủ proxy SIP hoặc máy chủ chuyển hướng SIP, với khả năng xử lý hàng nghìn cuộc gọi mỗi giây Mỗi thực thể CSCF được triển khai như một module có thể tự động mở rộng SER, giúp thêm các chức năng cần thiết cho SER để đáp ứng các yêu cầu theo tiêu chuẩn 3GPP.
Thành phần P-CSCF có vai trò quan trọng trong việc quản lý và bảo mật các kết nối của người dùng cuối trong mạng lõi Khi người dùng đăng ký, P-CSCF sẽ xác thực danh tính và thiết lập một kênh bảo mật cá nhân cho từng thiết bị Để theo dõi người dùng đã đăng ký, P-CSCF lưu trữ thông tin trong một bản đăng ký cục bộ và cập nhật thông tin qua quá trình đăng ký hoặc thông qua User Agent Client (UAC) Dữ liệu được lưu trữ dưới dạng bảng băm (hash-table) để đảm bảo truy xuất dữ liệu nhanh chóng và hiệu quả.
Hình 13 : Cấu trúc P -CSCF trong OpenIMSCore
Sau khi người dùng đăng ký thành công vào mạng IMS, các bản tin tiếp theo sẽ được chuyển đi dựa trên thông tin DNS từ mạng chủ Về vấn đề NAT trong báo hiệu SIP, tùy thuộc vào phương hướng lựa chọn, người dùng đầu cuối có thể hoạt động như một router bằng cách kích hoạt trong cả hai mạng Hơn nữa, module NAT cũng được điều chỉnh phù hợp với cơ chế lưu trữ vị trí người dùng xác định.
Một số đặc điểm của P CSCF:-
+ Giữ vai trò như tường lửa và xác nhận đ nh danh người dùng ị
+ Đồng bộ ản đăng ký cụ b c b thông qua s kiện ộ ự
+ Hỗ trợ các trường như Path, Security-Client, Security-Server, Security-Verify, Visited Network- - ID
+ Xác thực/tăng cư ng đờ ịnh tuyến dịch vụ (Service-Route)
+ Xác thực/tăng cư ng đờ ịnh tuyến bản nghi (Record-Route) và hội thoại có ng thái (Statefulness)trạ
+ Thiết lập cơ chếIPSec sử ụ d ng CK và IK từ AKA
+ Hỗ trợ NAT cho báo hiệu và media thông qua RTP Proxy
Một I-CSCF đóng vai trò như m t proxy không lưu giộ ữ trạng thái b ng ằ cách sử ụ d ng định danh công c ng cộ ủa người gọi cũng như ngư i đườ ợc gọ ểi đ truy vấn HSS và d a trên ph n hự ả ồi để đị nh tuy n b n tin tế ả ới đúng S-CSCF
Nó có thể giao tiếp với Cx giữa I-CSCF và HSS, hỗ trợ các câu lệnh liên quan đến Diameter để xác định S-CSCF được gán cho người dùng hoặc để lựa chọn một S-CSCF mới dựa trên khả năng và kiểm tra nhằm định danh, chuyển vùng và quyền lợi như đã được quy định trong 3GPP.
Hình 14 : Cấu trúc I -CSCF trong OpenIMSCore
Sau khi nhận được trả lời từ Diameter, I-CSCF chuyển bản tin SIP theo chế độ giao dịch, nhằm tối ưu hóa tốc độ và giảm thiểu thông số trạng thái Để đảm bảo an toàn, nó cho phép các bản tin báo hiệu đến từ các mạng tin cậy thông qua Network Domain Security (NDS).
+ Hỗtrợgiao diện Cx hoàn toàn
+ Lựa chọn S CSCF dựa trên khả năng người dùng
+ Hỗtrợ trường Visited-Network-ID và xác nhận quy n chuyển vùng ề + Che giấu Topo (THIG).
Hình 15 : Cấu trúc S -CSCF trong OpenIMSCore
S-CSCF cũng giao tiếp với HSS s d ng Diameter (thông qua giao diện ử ụ Cx) để truy lục vector xác thực, cập nhật thông tin đăng ký và download hiện trạng người dùng như đặ ảc t trong 3GPP S-CSCF có thể áp dụng hiện trạng người dùng dựa trên các tiêu chuẩn lọc ban đầu (iFC) để thúc đẩy các luật định tuyến SIP Nó cũng thực thi sự ỗ h tr viợ ệc tiến hành IMS Digest AKA phiên b n 1 S CSCF không tả - ự ạ t o ra vector xác th c mà nó dự ựa vào HSS và so sánh những giá trị này v i nh ng giá trịớ ữ được tính toán trên thi t bế ị người dùng Để đạt được thời gian đáp ứng nhanh chóng với thời gian khóa tối thiểu, sự đăng ký của S-CSCF có m t c u trúc phức tạp dựa trên bảng băm ộ ấ
Thông tin liên quan đến định danh người dùng được lưu trữ tại đây và được sử dụng trong quá trình đăng ký Nó cho phép việc theo dõi các sự kiện trạng thái trong quá trình đăng ký và thông báo cho người thuê bao về sự thay đổi trong quá trình này.
+ Hỗtrợgiao diện Cx hoàn toàn
+ Xác thực thông qua AKAv1-MD5, AKAv2 MD5 và MD5-
+ Hỗ trợ các trường như Service-Route, Path, P Asserted-Identity, - Visited Network- -ID:
+ Tải hiện trạng dịch vụ ừ t HSS
+ Tạo ra các tiêu chuẩn lọc ban đầu
+ Định tuyến giao diện ISC đi tới máy chủ ứ ng dụng (AS) s + Máy chủ ự kiện đăng ký với sự giới hạn truy cập
Trong phần mềm OpenIMS do FOKUS phát tri n, khể ối HSS được còn được g i là FhoSS (Fokus Home Subcriber Server) ọ
Hình 16 : Cấu trúc FHoSS trong OpenIMSCore
FHoSS được xây dựng như mộ ựt d án Java, d a trên m t s ph n m m ự ộ ố ầ ề mã nguồn mở khác như MySQL, Tomcat Dữ ệ li u ngườ ử ụi s d ng được lưu giữ
FHoSS is built with three interfaces based on the Diameter protocol (RFC 3588), facilitating efficient communication in MySQL databases The web management interface operates on Tomcat, while the Sh interface allows Application Servers to access the Home Subscriber Server (HSS).
+ Giao diện Cx dung trong các quá trình đăng ký (cụ th là giao di n kết ể ệ nối với I CSCF và S-CSCF) -
+ Giao diện Zh đểthiết lập các kênh HTTPS tới các ứng dụng
Here is a rewritten paragraph that maintains the original meaning and complies with SEO rules:"Lõi cốt của FHoSS được xây dựng dựa trên HssDiameterStack, cho phép sử dụng DiameterPeer để giao tiếp với các thực thể khác và nhận các yêu cầu cũng như trả lời theo kiểu CommandListener."
Dữ liệu của HSS được lưu trữ trong một cơ sở dữ liệu Cấu trúc Hibernate persistence được sử dụng để xây dựng tầng truy cập dữ liệu Hibernate là công nghệ phổ biến trong việc xây dựng tầng truy cập cơ sở dữ liệu cho các dự án Java.
FHoSS được qu n lý b ng giao diệả ằ n web Nó được triển khai dựa trên công nghệ servlet trong đó kết hợp với Apache Struts Web framework
Hình 17 : Giao diện web quản lý FHoSS
Giao diện web này gồm có các mục chính sau:
• User Identities: cho phép cấu hình thông tin người dùng như IMPU
(IP Multimedia Public Identity), IMPI (IP Multimedia Private Identity), IMSU (IMS SubscrIPtion) và liên k t các thông tin này lế ại, một IMPI có thểliên kết với nhiều IMPU
Hình 18 : Trang cấu hình nhận dạng người dùng cá nhân
• Services: cấu hình thông tin d ch v ị ụ
Hình 19 : Trang cấu hình thông tin dịch vụ
• Network Configuration: Cấu hình các thông tin về ạ m ng
Cấu trúc phần mềm của FHoSS:
Hình 20 : Cấu trúc thư mục của FHoSS
+ Đây là gói chính để ch y ứng dụng HSS ạ
+ Chứa file HSSContainer.java trong đó có hàm main() để ắ b t đầu ứng dụng.
+ Xây dựng nhờ vào JavaDiameterPeer phía trên ở
+ Thực thi giao diẹn command listeners
+ Chứa file Milenage.java triển khai chức năng xác thực
+ Chứa tất cả các gói nhỏ liên quan đến cơ sở ữ d liệu
+ Gói model chứa tất cả các loại b ng dả ữ li u.ệ
+ Gói op chứa các gói liên quan đế ớn l p DAO (Data Access Object) + Gói hibernate tri n khai theo công nghể ệ hibernate trong java để ế k t nối với cơ sở d ữ liệu
Các gói cx, sh, zh triển khai các giao diện tương ứng, mỗi gói đều chứa gói op, bao gồm tất cả các phương thức cần thiết cho giao diện đó.
- Gói web xây d ng giao diự ện cho web qu n lý FHoSS (hình 5.3).ả
GIỚI THIỆ U D CH V CH N VÀ CHUYỂ Ị Ụ Ặ N TI P CU C Ế Ộ
Tổng quan về công ngh ệ SIP Servlet
SIP Servlet là một thành phần ứng dụng Java quan trọng, được quản lý bởi một SIP Servlet container và thực thi thông qua các bản tin SIP Các servlet này là các lớp Java độc lập, được biên dịch thành mã máy có thể tự động nạp và chạy như một máy chủ SIP Các container này, còn gọi là phương tiện servlet, là phần mở rộng của máy chủ, cung cấp các chức năng cho servlet Servlet tương tác với các client bằng cách trao đổi các bản tin yêu cầu (request) và hồi đáp (response) thông qua các servlet container.
Servlet container là thành phần quan trọng trong máy chủ ứng dụng, cung cấp dịch vụ thông qua việc xử lý các yêu cầu và phản hồi Nó xác định các ứng dụng nào được triển khai và cách thức chúng hoạt động trong môi trường máy chủ.
Một servlet container quản lý và điều phối vòng đời của các servlet, có thể được tích hợp vào máy chủ SIP như một phần bổ sung thông qua các giao diện lập trình ứng dụng Container này có khả năng cài đặt và kích hoạt các máy chủ ứng dụng, đồng thời quản lý các điểm lắng nghe mạng để theo dõi luồng lưu lượng SIP Mỗi điểm lắng nghe được xác định bởi giao thức vận chuyển, địa chỉ IP và cổng, hỗ trợ các giao thức như UDP, TCP, TLS, và SCTP.
Một servlet container có khả năng thiết lập các giới hạn bảo mật cho môi trường thực thi của servlet Trong các phiên bản J2SE 1.2 và J2EE 1.3, những giới hạn này cần được thiết lập thông qua việc sử dụng các kiến trúc cho phép định nghĩa nền tảng Java2.
SIP Servlet tương tự như HTTP Servlet nhưng tập trung vào việc xử lý các yêu cầu SIP Chúng định nghĩa các phương thức đặc thù cho yêu cầu SIP, ví dụ như phương thức doInvite() được sử dụng để xử lý yêu cầu Invite, trong khi HTTP Servlet sử dụng phương thức doPost() để xử lý yêu cầu Post SIP Servlet và HTTP Servlet có thể được đóng gói cùng với các tài nguyên khác như thư viện, lớp khác nhau, nội dung tĩnh (âm thanh, hình ảnh, video) và một số tệp cấu hình, nhằm tạo ra một ứng dụng hội tụ.
1.2 Một số thuộc ính quan trọng của t SIP Servlet API
SIP Signaling cho phép các ứng dụng thực hiện một chuỗi các hành động liên quan đến tín hiệu SIP, bao gồm hỗ trợ các nhiệm vụ của User Agent Client (UAC), User Agent Server (UAS) và proxy.
Container giúp đơn giản hóa quy trình bằng cách xử lý các tác vụ phức tạp không cần thiết như quản lý các điểm nghe mạng, truyền lại thông tin như Cseq và Call-ID thông qua các trường điều khiển và định tuyến.
Các ứng dụng hội tụ được hỗ trợ bởi các Container có khả năng tích hợp nhiều giao thức và loại phương tiện khác nhau, bao gồm web, điện thoại và sự hiện
Phát triể ứn ng d ng t i nhà cung c p th ba: mô hình servlet hỗ trợ ụ ạ ấ ứ việc phát triển ứng dụng cho bên thứ ba Vi c mô tảệ tri n khai XML ể
61 thư ng đườ ợc s dử ụng để giao ti p thông tin ng dế ứ ụng t các bên thi t k ừ ế ế ứng d ng cho t i bên tri n khai ụ ớ ể
Thành phần ứng dụng có thể được sử dụng cho nhiều loại ứng dụng thực thi theo các yêu cầu hoặc hồi đáp theo chiều đến hoặc đi Mỗi ứng dụng đều có một bộ quy tắc riêng và thực thi một cách độc lập với các ứng dụng khác, đảm bảo tính rõ ràng và tổ chức theo thứ tự.
Cấp độ carrier (carrier grade) đề cập đến các servlet lưu trữ dữ liệu trong các container quản lý phiên giao dịch Việc triển khai này cho phép tái tạo dữ liệu một cách hiệu quả, đảm bảo hiệu suất tối ưu cho hệ thống.
1.3 Vòng đời của SIP Servlet
Vòng đời của một servlet bắt đầu khi nó được nạp vào bộ nhớ của máy chủ ứng dụng (AS) và kết thúc khi servlet bị ngắt hoặc nạp lại.
Vòng đờ ủi c a servlet bao gồm các bước sau:
Lớp servlet được n p b i container trong suạ ở ốt quá trình khở ội đ ng
Phương thức init() là phương thức khởi tạo của servlet, cần được gọi trước khi servlet có thể xử lý bất kỳ yêu cầu nào Trong suốt vòng đời của servlet, init() chỉ được thực hiện một lần.
Sau khi khởi tạo, servlet có khả năng phục vụ các yêu cầu từ phía client Mỗi yêu cầu sẽ được xử lý trong một chuỗi riêng biệt mà nó sở hữu.
Bộ chứa gọi phương thức nào được thực hiện và gửi đi với một phương thức phù hợp để xử lý yêu cầu đó Người phát triển servlet cần cung cấp triển khai cho các phương thức này Nếu một yêu cầu được gửi đến phương thức mà không được triển khai bởi servlet, phương thức mặc định sẽ được gọi, thường dẫn đến việc trả lại một lỗi từ người yêu cầu.
Cuối cùng, phương thức destroy() được gọi để ngừng hoạt động của servlet trong container Phương thức này tương tự như phương thức init(), nhưng chỉ được gọi một lần trong vòng đời của servlet.
Hình 21 : Vòng đời của Sip Servlet
Dịch vụ ch n và chuy n ti ặ ể ếp cuộc gọi
1.6 Phiên SIP Đặ ảc t SIP Servlet đ nh nghĩa các đ i tưị ố ợng SipSession để thể ệ hi n một phiên thông qua SIP trong cùng một cách với HttpSession để ể th hiện phiên thông làm việc thông qua HTTP Bởi vì một ứng dụng đơn như ứng dụng h i tộ ụ có th thể ực hiện một phiên thông qua cả HTTP và SIP, đặc tả này có thể đị nh nghĩa SipApplicationSession là một đ i tưố ợng session ở m c ng dứ ứ ụng Đối tượng SipApplicationSession có th hoạ ộể t đ ng như một lớp cha v i các phiên ớ HTTP và SIP trong một ứng d ng SipApplicationSession phụ ục vụ hai mục đích: cung cấp kho chứa d li u cho ữ ệ ứng dụng và phối hợp v i mộớ t s ố protocol session
2 Dịch vụ chặn và chuyển tiếp cuộc gọi
Dịch vụ chặn và chuyển tiếp cuộc gọi cho phép người dùng đăng ký danh sách các số điện thoại mà cuộc gọi đến sẽ bị chặn hoặc chuyển tiếp đến người khác Với dịch vụ này, người dùng có toàn quyền kiểm soát việc nhận và thực hiện cuộc gọi của mình.
2.2 Một số CallFlow của dịch vụ
2.2.1 CallFlow cuộc gọi thông thường
2.2.2 CallFlow cuộc gọi bị chặn
2.2.3 CallFlow cuộc gọi chuyển tiếp
2.3.1 Dịch vụ đăng ký dịch vụ chặn và chuyển tiếp cuộc gọi
Dịch vụ cho phép người dùng đăng nh p và đăng kí chặậ n cu c g i và chuyển ộ ọ tiếp cuộc gọi Dịch vụ ồ g m các thành phần chính:
- CCManagementApp.java: Khởi tạo UI và đọc mộ ố ất s c u hình
- CCManagementView.java: Xử lý các tác vụ liên quan t i giao diện và ớ kết nối cơ sở ữ ệ d li u ph c v cho vi c x lý ch n và chuy n ti p cuộc ụ ụ ệ ử ặ ể ế g i ọ
- DatabaseHelper.java: Kết nối cơ sơ dữ u liệ
- Utils.java: Lưu trữ các API truy vấn cơ sở ữ ệ d li u, thêm, sửa xóa các bản ghi liên quan
Tên cơ sở ữ ệ d li u: call_control
Quan hệ các b ng dả ữ liệu account
PK id username password call_forward
PK,FK1 subcriber forwarded_sub subcriber caller callee service_type
Hình 22 : Mối quan hệ giữa các bảng dữ liệu
Mô tả các b ng dả ữ ệ li u
Bảng thông tin đăng nhập chứa username và password của người dùng, cho phép họ đăng nhập vào chương trình đăng ký dịch vụ Sau khi đăng nhập, người dùng có thể đăng ký danh sách các cuộc gọi bị chặn và các cuộc gọi chuyển tiếp.
Các trường của bảng: id, username, password
Mục đích của bảng này là lưu trữ danh sách chuyển tiếp cuộc gọi Khi một cuộc gọi đến thuê bao được lưu trong trường subscriber, nó sẽ được chuyển tiếp tới thuê bao trong trường forwarded_subs.
Các trường của bảng: id, subcriber, forwarded_subs
Mục đích: bảng chứa thông tin đăng kí dịch v ch n và chuy n ti p ụ ặ ể ế cuộc gọi
Nếu giá trị trong trường service_type bằng 2, cuộc gọi sẽ được chuyển tiếp khi thuê bao trong trường caller gọi đến thuê bao trong trường callee Thông tin về việc chuyển tiếp cuộc gọi sẽ được lấy từ bảng call_forward.
Nếu giá trị lưu trong trường service_type = 1, thuê bao lưu trữ trong trường caller khi g i tọ ới thuê bao lưu trữ trong trường callee s b ẽ ịchặn
Thuật toán xử lý dịch vụ
Register CallBlocking Service Register CallBlocking Service
Hình 23 : Thuật toán xử lý đăng kí dịch vụ chặn/chuyển tiếp cuộc gọi
Quá trình thêm đăng kí dịch v ch n/chuy n ti p cu c g i ụ ặ ể ế ộ ọ
@Action public void add() { if (!getAuthenFlag()) { showError("You must to login"); return;
String caller = caller_text.getText();
String callee = callee_text.getText();
String service_type = (String) service_type_comboBox.getSelectedItem(); if (caller == null || caller.isEmpty()) { showError(caller_label.getText() + " must be not NULL"); return;
The method checks for paired users and verifies if the service type is call blocking If paired users exist, it attempts to update the user status; however, if the update fails, it displays an error message and logs the failure to insert data into the database.
} else if (type == Constant.NOT_EXIST) { if (!Utils.insertUser(caller, getSubs(), Constant.CALL_BLOCKING_TYPE)) { showError("Failure"); logger.error("Unable to insert to database"); return;
} else { showError("Failure"); logger.error("Database Error"); return;
} else if (Constant.CALL_FORWARDING_TEXT.equalsIgnoreCase(service_type)) { if (callee == null || callee.isEmpty()) { showError(callee_label.getText() + " must be not NULL"); return;
} if (type == Constant.EXIST) { if (!Utils.updateUser(caller, getSubs(), Constant.CALL_FORWARDING_TYPE)) { logger.error("Unable to update to database"); showError("Failure"); return;
} else if (type == Constant.NOT_EXIST) { if (!Utils.insertUser(caller, callee, Constant.CALL_FORWARDING_TYPE)) { logger.error("Unable to insert to database"); showError("Failure"); return;
} else { logger.error("Database Error"); showError("Failure"); return;
Quá trình xóa đăng kí
@Action public void remove() { if (!getAuthenFlag()) { showError("You must to login"); return;
String caller = caller_text.getText();
String callee = callee_text.getText();
String service_type = (String) service_type_comboBox.getSelectedItem(); if (caller == null || caller.isEmpty()) { showError(caller_label.getText() + " must be not NULL"); return;
} int type = Utils.hasPairUsers(caller, getSubs()); if (type == Constant.EXIST) { if (!Utils.deleteUser(caller, getSubs())) { showError("Failure"); logger.error("Unable to insert to database"); return;
} else { if (Constant.CALL_FORWARDING_TEXT.equalsIgnoreCase(service_type)) { if (callee == null || callee.isEmpty()) { if (!Utils.deleteAllForwardedSubs(getSubs())) { logger.error("Unable to update to database"); showError("Failure"); return;
} else { if (!Utils.deleteForwardedSubs(getSubs(), callee)) { logger.error("Unable to update to database"); showError("Failure"); return;
} else if (type == Constant.UNKNOWN) { showError("Failure");
72 logger.error("Database Error"); return;
Một sốgiao diện chương trình
Hình 24 : Màn hình loginVD: Đăng kí với username: bob@ims.hut.vn và pass: bob để đăng kí dịch vụ cho ob.B
Hình 25 : Màn hình đăng kí cuộc chuyển tiếp
Giao diện cho phép Bob đăng ký dịch vụ chuyển tiếp cuộc gọi Khi Bob chọn "Thêm", cuộc gọi từ Alice sẽ được chuyển tiếp đến Peter Ngược lại, nếu Bob chọn "Xóa", dịch vụ chuyển tiếp cuộc gọi sẽ bị hủy.
Hình 26 : Màn hình đăng kí chặn cuộc gọi
VD: Giao diện mô tả đăng kí chặn cuộc gọi cho Bob Nếu Bob chọn
“Add”, khi Alice g i t i Bob sọ ớ ẽ không th gể ọi được Nếu Bob chọn
“Remove” sẽ ủ h y dịch vụ chặn cuộc gọ ối đ i với Alice
2.3.2 Các servlet kết nối với OpenIMSCore
Xây dựng các servlet tương ứng v i vi c xửớ ệ lý các s kiự ện đố ới v i các thuê bao khi thực hiện cuộc gọi Các thành phần chính gồm có
- Main.java: Main servlet được kh i tở ạo khi d ch v ị ụ được load trên máy chủ ứ ng dụng
CallControl.java là servlet xử lý khi nhận được bản tin INVITE Servlet này kiểm tra cơ sở dữ liệu để xác định xem người được gọi có đăng ký dịch vụ hay không Nếu người được gọi đã đăng ký dịch vụ chặn cuộc gọi, servlet sẽ gửi bản tin kết thúc cho người gọi.
Nếu người gọi đăng kí dịch v chuy n ti p cu c g i, servlet sụ ể ế ộ ọ ẽ tiế ục p t
Kiểm tra xem người chuyển tiếp có tồn tại hay không Nếu không có, servlet sẽ gửi thông báo kết thúc cho người gọi Nếu có, servlet sẽ chuyển tiếp cuộc gọi đến đối tượng đã đăng ký.
Bản tin SIP được xửlý: INVITE
- CallForwarding.java: CallForward servlet được s dử ụng để thực hi n ệ kết nối giữa ngườ ọi g i ban đ u và ngưầ ời được chuy n ti p cu c g i ể ế ộ ọ
Bản tin SIP được xửlý: BYE, ACK, CANCEL
CallProxy.java là một servlet được sử dụng để thiết lập kết nối giữa người gọi và người nghe trong trường hợp người nghe không đăng ký dịch vụ chuyển tiếp cuộc gọi.
Bản tin SIP được xửlý: toàn bộ các b n tin ả
- Sip.xml: kịch bản triển khai cho SIP servlet
Main
-class>org.hut.fet.ims.callcontr -
0
CallControl
-class>org.hut.fet.ims.callcontrol.servlets.CallControlorg.hut.fet.ims.callcontrol.servlets.CallForwardingorg.hut.fet.ims.callcontrol.servlets.CallProxy