4 CHƯƠNG I V: QUẢN LÝ TƯƠNG TÁC DỊCH VỤ TRONG IMS
4.1.1 SCSCF và tiêu chuẩn lọc
4.1.1.1 Tiêu chuẩn lọc
Tiêu chuẩn lọc là một trong những thành phần quan trọng nhất của thông tin người dùng được lưu trữ trên mạng vì chúng xác định loại dịch vụ nào sẽ cung cấp cho người sử dụng. Tiêu chuẩn lọc bao gồm một tập hợp thông tin liên
quan đến người dùng giúp cho S-CSCF quyết định khi nào gọi máy chủ ứng dụng cung cấp dịch vụ.
Theo tiêu chuẩn 3GPP TS 23.218 [20] có hai tiêu chuẩn lọc là: tiêu chuẩn lọc khởi tạo (IFC – Initial Filter Criteria) và tiêu chuẩn lọc kế tiếp (SFC – Subsequent Filter Criteria). Tuy nhiên chỉ có tiêu chuẩn lọc khởi tạo IFC là được sử dụng. Tiêu chuẩn lọc kế tiếp SFC vẫn còn nằm trên lý thuyết, do nếu áp dụng tiêu chuẩn lọc kế tiếp SFC tại S-CSCF có thể sẽ gây ra xung đột với quy tắc định tuyến bản tin SIP cho các proxy.
Tiêu chuẩn lọc khởi tạo IFC có nhiệm vụ đánh giá các yêu cầu khởi tạo SIP và tạo ra các yêu cầu đơn. Ví dụ, S-CSCF đánh giá tiêu chuẩn lọc khởi tạo khi nhận được yêu cầu SUBSCRIBE đầu tiên, INVITE, OPTIONS, hoặc bất cứ yêu cầu nào tạo ra cuộc hội thoại hoặc được gửi ngoài các hộp thoại. S-CSCF không đánh giá tiêu chuẩn lọc khởi tạo khi nhận được yêu cầu PRACK, NOTIFY, UPDATE, hoặc BYE do chúng luôn luôn được gửi như một phần của một hội thoại SIP đang tồn tại.
Khái niệm tiêu chuẩn lọc kế tiếp là S-CSCF sẽ đánh giá tiêu chuẩn lọc kế tiếp khi nó nhận được yêu cầu kế tiếp trong hộp thoại SIP. Tuy nhiên, kết quả của việc đánh giá tiêu chuẩn lọc kế tiếp có thể dẫn đến việc S-CSCF chuyển tiếp yêu cầu SIP kế tiếp đến một máy chủ ứng dụng, điều này trái ngược với thủ tục định tuyến cho yêu cầu kế tiếp ở trong một SIP proxy. Hơn nữa, trong sự kiện một máy chủ ứng dụng nhận được yêu cầu kế tiếp này, khi đó máy chủ ứng dụng vẫn chưa nhận được yêu cầu khởi tạo SIP để tạo hộp thoại SIP. Do đó, máy chủ ứng dụng sẽ hủy yêu cầu và bỏ qua yêu cầu kế tiếp đó. Từ đó dẫn đến việc không sử dụng tiêu chuẩn lọc kế tiếp.
Tiêu chuẩn lọc duy nhất được triển khai là tiêu chuẩn lọc khởi tạo. Do tiêu chuẩn lọc kế tiếp không tồn tại nên thuật ngữ tiêu chuẩn lọc khởi tạo và tiêu
chuẩn lọc là như nhau.
HSS lưu giữ tất cả dữ liệu liên quan tới người dùng trong một cấu trúc dữ liệu tên là User Profile. Hình 4-1 mô tả cấu trúc đơn giản cấp cao của user profile.
hay nhiều service profile. Mỗi một service profile chứa một hay nhiều định danh công cộng thuê bao mà service profile đó thuộc về và không có hoặc nhiều tiêu chuẩn lọc.
Hình 4-16: Cấu trúc của User Profile
Khi người dùng đăng ký với S-CSCF, S-CSCF liên lạc với HSS và tải user profile có chứa tiêu chuẩn lọc. Vậy tiêu chuẩn lọc vẫn tồn tại trong S-SCSF tại thời điểm người dùng đăng ký.
Tiêu chuẩn lọc xác định các dịch vụ mà nó có thể áp dụng được để thu thập định danh công cộng thuê bao liệt kê trong “Service profile”. Cấu trúc dữ liệu của tiêu chuẩn lọc được thể hiện ở hình 4-2.
Hình 4-17: Cấu trúc tiêu chuẩn lọc khởi tạo
Trường đầu tiên trong cấu trúc tiêu chuẩn lọc là Priority. Trường Priority xác định thứ tự của tiêu chuẩn lọc sẽ được đánh giá so với các tiêu chuẩn lọc còn lại trong cùng một “service profile”. S-SCSF trước tiên sẽ chọn tiêu chuẩn lọc
S-SCSF tiếp tục với tiêu chuẩn lọc tiếp theo có độ ưu tiên nhỏ hơn. Trường Priority của tiêu chuẩn lọc là số duy nhất đối với các tiêu chuẩn lọc trong cùng một “service profile”. Trong một số trường hợp, số ưu tiên không cần thiết phải liền nhau.
Sau trường Priority, có thể không có hoặc có một Trigger Point (điểm kích hoạt). Một Trigger Point là một biểu thức cần được đánh giá để xác định xem yêu cầu SIP có được chuyển tiếp đến máy chủ ứng dụng hay không. Một điểm kích hoạt là tập hợp các bộ lọc riêng biệt được gọi là “Service Point Triggers”.
Ví dụ, một Trigger Point có thể như sau:
(Method = INVITE) AND (Request-URI = sip:user@example.com)
Trong ví dụ này có hai Service Point Trigger là Method = INVITE và Request- URI = sip:user@example.com.
Sevice Point Trigger cho phép ta truy nhập thông tin được lưu trữ chứa trong các trường khác nhau của yêu cầu SIP.
• Giá trị của Request-URI.
• Phương thức của yêu cầu SIP (ví dụ: INVITE, OPTIONS, SUBSCRIBE,…).
• Sự có mặt hay vắng mặt của bất cứ trường điều khiển SIP (SIP header) nào.
• Trùng một phần hay toàn bộ nội dung của bất kỳ trường điều khiển SIP nào.
• Trường hợp phiên (ví dụ, yêu cầu SIP có nguồn là một thuê bao được phục vụ gửi đến thuê bao đã đăng ký, hoặc gửi đến thuê bao chưa đăng ký).
• Mô tả phiên (ví dụ, trùng một phần hay toàn bộ bất kể một dòng SDP nào).
Nếu không có Trigger Point thì các yêu cầu SIP được chuyển tiếp đến máy chủ ứng dụng vô điều kiện.
Sau Trigger Points chứa một hay nhiều Service Point Triggers, tiêu chuẩn lọc khởi tạo chứa AS SIP URI. Đây là địa chỉ của máy chủ ứng dụng sẽ nhận yêu cầu SIP nếu các điều kiện được mô tả trong các Trigger Point được thỏa mãn. Trường Default Handling chỉ hành động sẽ xảy ra nếu S-CSCF với lý do nào đó không thể liên lạc được với máy chủ ứng dụng. Các hành động có thể tiếp tục xử lý yêu cầu SIP hoặc ngừng xử lý.
Trường Service Information chứa dữ liệu trong suốt (ví dụ, trong suốt với HSS và S-CSCF) mà máy chủ ứng dụng có thể cần để xử lý yêu cầu. Cách sử dụng trường này được giới hạn với các yêu cầu SIP REGISTER hoặc bất kỳ yêu cầu nào khác khi mà S-CSCF hoạt động như là một SIP User Agent Client. Nguyên nhân là do các dữ liệu được thêm vào phần thân của yêu cầu SIP. Hành động này không được chấp nhận trong các SIP Proxy. Vì vậy, trường hợp duy nhất sử dụng thông tin này là khi S-CSCF, tùy theo tiêu chuẩn lọc khởi tạo, hoạt động như một “SIP User Agent Client” tạo ra yêu cầu SIP REGISTER ở bên thứ ba tới máy chủ ứng dụng. Yêu cầu REGISTER đó có thể chứa Service Information (trong trường hợp máy chủ ứng dụng cần nó), với mục đích là truyền IMSI tới IM-SSF của thuê bao, vì IMSI có thể được sử dụng bởi IM-SSF.
Cuối cùng, user profile được mã hóa sử dụng ngôn ngữ đánh dấu mở rộng XML (Extensible Markup Language). Mẫu XML định nghĩa tiêu chuẩn lọc khởi tạo được mô tả trong 3GPP TS 29.228 [21]. Tiêu chuẩn lọc khởi tạo được truyền từ HSS đến S-SCSF thông qua bản tin Diameter.
Các SPT (Service Point Triggers – điểm kích hoạt dịch vụ) là các điểm trong chuỗi báo hiệu SIP có thể làm SCSCF gửi hoặc chuyển tiếp các bản tin SIP tới các Server nhu SIP AS/OSA SCS/IM-SSF. Các tập hợp của tất cả các SPT liên quan tới một ứng dụng cụ thể được xác định trong tiêu chuẩn lọc Filter Criteria. Các SPT có thể bao gồm:
SIP Header Header: string Content: string
Service Point Trigger ConditionNegated: boolean Group: list of integer RegistrationType: list of enumerated SIP Method Method: string Session Description Line: string Content: string Session Case SessionCase: enumerated Request-URI RequestURI: string
Hình 4-18: Thành phần của Service Point Trigger
Như trên hình 4-3, các thành phần SPT có chức năng cụ thể như sau:
• Request-URI: xác định tài nguyên mà yêu cầu được hướng đến (ví dụ: new@ims.hut.edu.vn). Request-URI chứa thuộc tính RequestURI của bản tin SIP cần xác nhận.
• SIP Method: dùng để kiểm tra phương thức yêu cầu nào của bản tin SIP (có thể là REGISTER, INVITE, PUBLISH, SUBSCRIBE, MESSAGE,…).
• SIP Header: chứa thông tin liên quan đến yêu cầu. SPT có thể dựa trên sự có mặt hay vắng mặt của một SIP Header nào đó với giá trị Header là tên của Header cần xét và giá trị Content là nội dung của header đó. Giá trị của Content được sử dụng như một mẫu để kiểm tra.
• Session Case: dùng để xác định chiều của bản tin là khởi tạo (originating) hay kết thúc (terminating) trong trường hợp người dùng có đăng ký (registered) hoặc chưa đăng ký (unregistered). Nói cách khác, trường này được sử dụng bởi S-CSCF để xử lý dịch vụ cho phía nguồn, dịch vụ cho phía đích hay dịch vụ cho phía đích chưa đăng ký. Trường hợp nguồn là khi S-CSCF phục vụ cho phía khởi tạo phiên
(người gọi), trường hợp đích là khi S-CSCF phục vụ cho phía cuối của phiên (người bị gọi).
• Session Description: xác định SPT cho nội dung của trường SDP trong phần thân (body) của phương thức SIP. Mẫu kiểm tra có thể sử dụng ở đây.
Về mặt dữ liệu thì cấu trúc của tiêu chuẩn lọc khởi tạo được mã hóa dựa trên xml. Dưới đây là một ví dụ tiêu chuẩn lọc khởi tạo cho dịch vụ hộp thư thoại tại máy chủ ứng dụng (sip:vmail@ims.example.com) dành cho thuê bao chưa đăng ký. Để làm được điều này thì nhà cung cấp phải làm cho SIP Method có giá trị là INVITE và Session Case có giá trị là terminating – unregistered. Nếu như không kết nối đến được máy chủ ứng dụng thì xử lý mặc định là dừng phiên lại.
Hình 4-19: Ví dụ về User Profile
Nhiều SPT có thể liên kết với nhau thông qua các quan hệ logic (như AND, OR, NOT).
Tiêu chuẩn lọc khởi tạo (iFC) là tiêu chuẩn lọc được lưu trữ trong HSS như một phần thông tin người sử dụng và được SCSCF tải về trong quá trình người sử dụng đăng kí. Nó mô tả đăng kí của người sử dụng tới một ứng dụng nào đó. Về mặt dữ liệu thì cấu trúc của tiêu chuẩn lọc khởi tạo được mã hóa dựa trên xml. Dưới đây là một ví dụ tiêu chuẩn lọc khởi tạo cho dịch vụ hộp thư thoại tại máy chủ ứng dụng (sip:vmail@ims.example.com) dành cho thuê bao chưa đăng ký. Để làm được điều này thì nhà cung cấp phải làm cho
SIP Method có giá trị là INVITE và Session Case có giá trị là terminating – unregistered. Nếu như không kết nối đến được máy chủ ứng dụng thì xử lý mặc định là dừng phiên lại.
4.1.1.2 SCSCF sử dụng tiêu chuẩn lọc khởi tạo iFC để lựa chọn ứng dụng khởi tạo:
Hình 4-20: SCSCF đóng vai trò Service Broker giữa các AS khác nhau
SCSCF có thể nhận được nhiều tiêu chuẩn lọc trong tiêu chuẩn lọc khởi tạo. Để cho phép SCSCF xử lí các tiêu chuẩn khác lọc khác nhau theo trình tự đúng, thứ tự ưu tiên sẽ được gán cho mỗi tiêu chuẩn. Khối SCSCF sau đó sẽ lần lượt xử lý các tiêu chuẩn lọc này dựa trên thứ tự đó.
Tiêu chuẩn lọc khởi tạo được tải về S-CSCF trong quá trình đăng ký của thuê bao hoặc khi nhận được yêu cầu khởi tạo đích cho thuê bao chưa đăng ký. Sau khi tải hồ sơ thuê bao từ HSS, S-CSCF sẽ quyết định tiêu chuẩn lọc cho từng yêu cầu khởi tạo theo các bước sau:
• Kiểm tra xem dịnh danh người dùng công cộng có bị chặn hay không? Nếu không thì tiếp tục.
• Kiểm tra xem yêu cầu là yêu cầu đích (terminating) hay yêu cầu nguồn (originating).
• Chọn tiêu chuẩn lọc khởi tạo cho các trường hợp phiên cụ thể (nguồn, đích, đích cho người dùng chưa đăng ký).
• Kiểm tra xem yêu cầu có khớp với tiêu chuẩn lọc khởi tạo có độ ưu tiên cao nhất bằng cách so sánh hồ sơ dịch vụ với định danh người dùng công cộng trong yêu cầu:
o Nếu yêu cầu khớp với tiêu chuẩn lọc khởi tạo, S-CSCF sẽ chuyển tiếp yêu cầu này đến máy chủ ứng dụng, sau đó kiểm tra xem nó có khớp với tiêu chuẩn lọc khởi tạo có độ ưu tiên thấp hơn hay không? Nếu có áp dụng vào SIP Method nhận được từ liên lạc trước đó đến máy chủ ứng dụng.
o Nếu yêu cầu không khớp với tiêu chuẩn lọc khởi tạo có độ ưu tiên cao nhất thì tiếp tục kiểm tra cho đến khi nó khớp.
o Nếu không còn (hoặc không có) tiêu chuẩn lọc khởi tạo nào khớp, thì S-CSCF sẽ chuyển yêu cầu theo các quyết định định tuyến.
Ở đây tồn tại sự khác biệt rõ ràng giữa cách xử lý của S-CSCF với tiêu chuẩn lọc khởi tạo cho yêu cầu nguồn và đích. Khi S-CSCF nhận ra rằng máy chủ ứng dụng đã thay đổi Request-URI trong trường hợp tiêu chuẩn lọc khởi tạo đích, nó sẽ dừng kiểm tra và định tuyến yêu cầu theo giá trị của Request-URI. Trong trường hợp nguồn, S-CSCF sẽ tiếp tục đánh giá các tiêu chuẩn lọc khởi tạo cho đến khi hết.
Nếu máy chủ ứng dụng được liên lạc không phản hồi, S-CSCF sẽ gọi hành động mặc định được nêu ra trong tiêu chuẩn lọc khởi tạo: hoặc là dừng phiên hoặc là cho tiếp tục dựa trên các thông tin được cung cấp ở tiêu chuẩn lọc khởi tạo. Nếu trong tiêu chuẩn lọc khởi tạo không đề cập đến hành động mặc định, nếu không liên lạc được với máy chủ ứng dụng thì S-CSCF sẽ cho cuộc gọi tiếp tục.
Để làm rõ hơn về hành vi của SCSCF khi sử dụng tiêu chuẩn lọc khởi tạo để lựa chọn ứng dụng, em xin trình bày ví dụ sau:
Trong ví dụ này, ta giả sử có 3 máy chủ ứng dụng (AS) đã thiết lập tiêu chuẩn lọc cho các bản tin yêu cầu mà thuê bao có tên Dung (xem bảng dưới) gửi.
tiêu chuẩn lọc SPT: session case
Originating Originating Terminating
SPT: public user identify Tel:+44-123-456- 789 Sip:dung@hut.vn Tel:+44-123-456- 789 Sip:dung@hut.vn
SPT: SIP method * INVITE SUBSCRIBE
Further SPT __ __ SIP header: event:
pres Application
server
Sip:as1.hut.vn;lr Sip:as2.hut.vn;lr Sip:as3.hut.vn;lr
SCSCF trong miền của Dung sẽ kiểm tra từng tiêu chuẩn lọc này và so sánh với thông tin nhận được trong bản tin INVITE:
INVITE sip:hanh@hut2.vn SIP/2.0
Via:SIP/2.0/UDPscscf1.hut.vn;branch=asctb Via:SIP/2.0/UDPpcscf1.visited1.vn;branch=9pctb Via:SIP/2.0/UDP[5555::1:2:3:4]:1357;branch=8uetb Route:<sip:orig@scscf1.hut.vn;lr> From:"YourBrother"<sip:dung@brother.com>;tag=veli To:"MySister"<sip:hanh@sister.com> P-Asserted-Identity:<sip:dung@hut.vn> Privacy:None
Ta thấy, tiêu chuẩn 1 không thích hợp, vì trường P-Asserted-Identify trong bản tin này không mang URL có chứa số điện thoại của Dung.
Tiêu chuẩn 2 tương ứng vì :
- Bản tin INVITE nhận được từ thuê bao trong miền khởi tạo. SCSCF biết điều này dựa vào trường Service-Route nó thiết lập cho thuê bao và thông tin nó lấy được từ trường Route trong bản tin.
- Trường P-Asserted-Identify phù hợp với tiêu chuẩn lọc - Phương thức SIP là INVITE
Hình 4-21: Định tuyến bản tin đến máy chủ ứng dụng