Giao thức truy nhập cấu hỡnh XML (XCAP) là giao thức được thiết kế theo
chuẩn HTTP, nú sử dụng phương phỏp HTTP như PUT, GET, DELETE cho việc
giao tiếp trờn điểm thao chiếu Ut. XCAP ỏnh xạ tài liệu XML và cỏc nhõn tố thuộc tớnh tới HTTP URIs, vỡ vậy cỏc thành phần này cú thể được truy nhập trực tiếp bởi cỏc phương phỏp HTTP. XCAP cung cấp một client (ứng dụng) với cỏch thức để
thờm, sửa, xúa cấu hỡnh XML của một loại dữ liệu bất kỳở XCAP server. Trong hoạt
động phục vu dịch vụ presence XCAP server được sử dụng để cho phộp XCAP client thao tỏc dữ liệu: user ở danh sỏch user, chớnh sỏch cấp quyền, hoặc danh sỏch người
.
Hỡnh 4.6 Sử dụng XCAP
Presence server sử dụng tài liệu chứa đựng trong XCAP server theo cấu trỳc: xcap-root
• pres-rules
o users
bob
• presence-rules.xml //file chứa đựng luật cấp phộp presence cho bob
alice • presence-rules.xml ... (thư mục cho người sử dụng khỏc) • resource-lists o users bob
• resource-list.xml //file chứa đựng danh danh sỏch nguồn cho bob
alice
• resource-list.xml
... (thư mục cho người sử dụng khỏc)
• rls-services
o global
Vớ dụ:
• resource-list.xml
• Presence-rules.xml
4.7. Một số luồng bản tin bỏo hiệu cơ bản phục vụ dịch vụ
Luồng tớn hiệu bỏo hiệu phục vụ dịch vụ presence chỉ ra làm như thế nào cỏc watcher cú thể yờu cầu thụng tin trạng thỏi của một thực thể cung cấp thụng tin. Ở đõy ta tập trung nghiờn cứu về cỏc bản tin khởi tạo SUBSCRIBE request đểđăng kớ nhận thụng tin trạng thỏi, và cỏc NOTIFY request khởi tạo chứ khụng nghiờn cứu
cỏc bản tin SUBSCRIBE request và NOTIFY request chuyển tiếp giữa cỏc CSCF.
Một số kớ hiệu để hiểu luồn tớn hiệu:
• Rls.home1.net: một RLS ở home network của watcher.
• Rls.home2.net: một RLS ở home network của nhà cung cấp dịch vụ, khụng ở
• Ps.home1.net: một PS ở home network của bờn xuất bản thụng tin
• Ps.home2.net: một PS ở home network của nhà cung cấp dịch vụ, khụng ở home network của watcher.
• User1_list1@home1.net: một danh sỏch nguồn đang được đăng kớ tới RLS ở
home network.
• User2_list1@home2.net: một danh sỏch nguồn đang được đăng kớ tới RLS ở
home network của nhà cung cấp dịch vụ, khụng ở home network của thuờ bao
đăng kớ.
4.7.1. Watcher đăng kớ để nhận thụng tin trạng thỏi của một thực thể cung cấp thụng tin
4.7.1.1. Watcher ở mạng khỏch đối với thực thể cung cấp thụng tin
Home Network#2 Home Network#1 UE (Watcher) P-CSCF#1 S-CSCF#1 I-CSCF HSS S-CSCF#2 AS(PS) 2.SUBSCRIBE 3.Đỏnh giỏ lọc Khởi tạo 4.SUBSCRIBE 5.Truy vấn vị trớ user 6.SUBSCRIBE 7.Đỏnh giỏ lọc khởi tạo 8.SUBSCRIBE 9.Cấp phộp watcher 10.200(OK) 11.200(OK) 12.200(OK) 13.200(OK) 14.200(OK) 15.NOTIFY 16.NOTIFY 17.NOTIFY 18.200(OK) 19.200(OK) 20.200(OK) 1.SUBSCRIBE
Hỡnh 4.7 chỉ ra watcher đăng kớ để nhận thụng bỏo về sự kiện presence của một thực thểở mạng con IM CN khỏc. Chi tiếp về một số luồng:
• 1. SUBSCRIBE request (UE (watcher) tới P-CSCF) Một watcher muốn nhỡn
thụng tin presence của một thực thể presentity. Để khởi tạo đăng kớ, watcher tạo ra một SUBSCRIBE request chứa đựng trường event (sự kiện) “presence” cựng với trường Expires chỉ ra thời gian hết hạn của một đăng kớ.
• 3 và 7 đỏnh giỏ lọc khởi tạo: S-CSCF#1 và S-CSCF#2 xỏc nhận tớnh hợp lệ
của của service profile của thuờ bao.
• 5 Cx truy vấn vị trớ user đú là I-CSCF gửi một truy vấn tới HSS để tỡm S- CSCF của user được gọi. HSS đỏp ứng lại với vị trớ hiện tại của S-CSCF cho mỗi thuờ bao, chi tiết được miờu tảở 3GPP TS 29.228.
• 9 Cấp phộp watcher đú là: PS thực hiện kiểm tra cấp phộp cần thiết trờn người khởi tạo để chắc chắn rằng nú được cho phộp để nhỡn presentity. Trong vớ dụ
này, tất cả tỡnh trạng bảo mật là được thỏa món, vỡ vậy PS gửi đỏp ứng 200(OK) tới S-CSCF. Trong trường hợp cấp phộp lỗi, khi đú đỏp ứng 2xx
hoặn 4xx sẽđược gửi tới S-CSCF. Sự lựa chọn mó đỏp ứng sửa phụ thuộc vào chớnh sỏch cấp phộp của yờu cầu đăng kớ của presentity.
• 15 NOTIFY request (PS tới S-CSCF) Ngay sau khi PS gửi đỏp ứng 200 (OK)
để chấp nhận sựđăng kớ, nú gửi NOTIFY request với thụng tin presence trạng thỏi hiện tại của presentity mà watcher đăng kớ để nhận. NOTIFY request
được gửi tới S-CSCF#1. Dựa trờn trường Accept của SUBSCRIBE request,
PS quyết định sử dụng một phần thụng bỏo để cung cấp sự thay đổi của thụng tin trạng thỏi.
4.7.1.2. Watcher đăng kớ với RLS để nhận thụng bỏo về thụng tin trạng thỏi người dựng của một danh sỏch nguồn
4.7.1.2.1. RLS nằm trong cựng Home Network với UE
UE (Watcher) P-CSCF S-CSCF AS(RLS) 1.SUBSCRIBE 2.SUBSCRIBE 3.Đỏnh giỏ lọc khởi tạo 4.SUBSCRIBE 5.Cấp phộp Watcher 6.200(OK) 6.200(OK) 7.200(OK) 9.NOTIFY 10.NOTIFY 11.NOTIFY 12.200(OK) 13.200(OK) 14.200(OK) 15.Đăng kớ và thụng bỏo gúi sự kiện presence 16.NOTIFY 18.NOTIFY 19.200(OK) 20.200(OK) 21.200(OK) 17.NOTIFY
Visited Network Home Network of UE
Hỡnh 4.8 Watcher đănng kớ tới danh sỏch nguồn để nhận thụng tin trạng thỏi của danh sỏch người dựng
Hỡnh trờn chỉ ra luồng bản tin bỏo hiệu khi Watcher đăng kớ tới danh sỏch nguồn
để nhõn thụng tin presence trong trường hợp RLS nằm cựng Home Network của UE.
• 1. SUBSCRIBE request (watcher tới P-CSCF) một watcher muốn biết thụng
tin presence của nhiều thực thể presentity. Danh sỏch của cỏc thực thể
presenctity được nhận dạng bởi một SIP URI. Để khởi tạo một đăng kớ tới
RLS phỏp ra một SUBSCRIBE request chỉ ra cung cấp (supported) cho
• 9. NOTIFY request (RLS tới S-CSCF) RLS phỏt ra một NOTYFY request bao gồm tài liệu RLMI như là kết quả của SUBSCRIBE request.
• 15. Đăng kớ và thụng bỏo gúi sự kiện presence: đú là sau khi RLS phỏt ra một NOTIFY request núi cho UE (watcher) biết về trạng thỏi đăng kớ, RLS sẽ phỏt ra một SUBSCRIBE request cần thiết tới cỏc thực thể presentity tồn tại trong danh sỏch nguồn. Ngay sau khi RLS nhận NOTIFY request về sự thay đổi ở
một hoặc nhiều thực thể presentity nú sẽ phỏt ra NOTIFY request.
• 16. NOTIFY request (RLS tới S-CSCF) RLS sao lưu tất cả thõn NOTIFY
request đến vào thõn một NOTIFY request ra sử dụng dạng MIME
một phần thụng tin presence được bật ( chỉ thụng tin presence, cỏi mà đó được thay đổi từ thụng bỏo cuối cựng như miờu tảở RFC 4662 [22]. Ở vớ dụ này giả
sử rằng RLS đó nhận hai NOTIFY request từ cỏc thực thể presentity là
“sip:user2_public1@home2.net” và “sip:user3_public1@home3.net” trước
4.7.1.2.2. RLS ở trong cựng Home Network với AS UE (Watcher) AS(RLS) HSS I-CSCF S-CSCF P-CSCF 1.SUBSCRIBE 2.SUBSCRIBE 3.Đỏnh giỏ lọc khởi tạo 7.Cấp phộp Watcher 10.200(OK) 11.200(OK) 12.NOTIFY 14.NOTIFY 15.200(OK) 16.200(OK) 17.200(OK) 18. Đăng kớ và thụng bỏo gúi sự kiờn
presence 19.NOTIFY 20.NOTIFY 21.NOTIFY 22.200(OK) 23.200(OK) 24.200(OK)
Home Network Home Network of AS
13.NOTIFY
4.SUBSCRIBE 5.Cx truy vấn vị trớ PSI
6.SUBSCRIBE
9.200(OK) 8.200(OK)
Hỡnh 4.9 Watcher đăng kớ tới danh sỏch nguồn để nhận thụng tin trạng thỏi của danh sỏch người dựng
Hỡnh 4.9 chỉ ra luồng bản tin watcher đăng kớ tới danh sỏch nguồn để nhõn thụng tin presence trong trường hợp RLS nằm ở Home Network của AS.
• Cỏc SUBSCRIBE request và NOTIFY request hoạt động tương tự như trương hợp 4.7.1.2.1
• 5 truy vấn vị trớ PSI đú là: I-CSCF gửi truy vấn đến HSS để tỡm vị trớ của RLS. HSS sẽđỏp ứng với địa chỉ của RLS. Chi tiết về luồng bản tin được chỉ
ra ở 3GPP TS 29.228
4.7.2. RLS đăng kớ để nhận thụng tin trạng thỏi của người dựng của một thực thể cung cấp thụng tin ở mạng khỏch S-CSCF I-CSCF HSS S-CSCF AS(PS) AS(RLS) 1.SUBSCRIBE 2.Đỏnh giỏ lọc khởi tạo 2.SUBSCRIBE 4.Cx truy vấn vị trớ user 5.SUBSCRIBE 6.Đỏnh giỏ Lọc khởi tạo 7.SUBSCRIBE 8.Cấp phộp Watcher 9.200(OK) 10.200(OK) 11.200(OK) 12.200(OK) 13.NOTIFY 14.NOTIFY 15.200(OK) 16.200(OK)
List Server Presentity Home Network
Hỡnh 4.10 RLS đăng kớ để nhận thụng tin trạng thỏi của người dựng của một thực thể cung cấp thụng tin ở mạng khỏch
Hỡnh trờn chỉ ra RLS đăng kớ để nhận thụng bỏo về presence của presentity,
presentity là ở mạng IM CN khỏc.Chi tiết về một số luồng:
sự kiện “presence” với tất cả thực thể presentity, cỏi mà được miờu tả bởi danh sỏch nguồn SIP URI. Home Network của cỏc thực thể presentity cú thể khỏc hoặc trong cựng một mạng. Trong luồng tớn hiệu trờn là ở khỏc mạng. Để khởi tạo một đăng kớ, RLS phỏt ra một SUBSCRIBE request chứa đựng sự kiện “presence” cỏi mà nú mong muốn được thụng bỏo, RLS gửi yờu cầu tới S- CSCF.
• 14. NOTIFY request (PS tới S-CSCF) hoạt động tương tự như luồng tớn hiệu ở
chương IV mục 4.7.1.1
4.7.3. Thực thể cung cấp thụng tin cập nhật thụng tin trạng thỏi
UE P-CSCF S-CSCF PS 1.PUBLISH 2.PUBLISH 3.Đỏnh giỏ lọc khởi tạo 4.PUBLISH 5.Cấp phộp xuất bản 6.200(OK) 7.200(OK) 8.200(OK) Home Network Hỡnh 4.11 UE xuất thụng tin trạng thỏi tới PS
UE cú thể xuất một phần hoặc toàn bộ thụng tin presence về một thực thể presentity tới PS. Trong vớ dụ này, giả sử UE xuất toàn bộ thụng tin presence. Hỡnh 4.11 chỉ ra UE xuất thụng tin hoặc thay đổi thụng tin trạng thỏi người dựng đó tồn tại. Một số chi tiết về luồng:
• 1. PUBLISH ( UE tới P-CSCF) Một PUA trong một UE mong muốn xuất
thụng tin presence. Để khởi tạo sự xuất bản, UE phỏt ra một yờu cầu
PUBLISH theo chuẩn RFC 3903 chứa đựng thụng tin presence mà mong
4.7.4. Luồng tớn hiệu hoạt động HTTP phục vụ dịch vụ kiểm tra trạng thỏi người dựng thỏi người dựng
Luồng tớn hiệu này chỉ ra sự thao tỏc dữ liệu phục vụ hoạt động dịch vụ presence tại
điểm thao chiếu Ut sử dụng XCAP. Luồng chỉ chỉ ra luồng tớn hiệu giữa XCAP server và XCAP client, bởi vậy cỏc proxy giữa cỏc thực thể này là khụng được chỉ ra trong vớ dụ trờn. Mỗi một luồng tớn hiệu chỉ ra vài chuỗi thao tỏc dữ liệu cho phục vụ
presence. Chỳ ý rằng lỗi là khụng được xem xột trong vớ dụ. Nếu sự kiểm tra xỏc thực là lỗi ở XCAP server hoặc URI khụng tồn tại khớ đú đỏp ứng 4xx sẽđược gửi tới client. XCAP sử dụng HTTP được miờu tảở RFC 4825. Proxy chứng thực giữa UE( XCAP client) và AS (XCAP server), và vớ dụ của luồng tớn hiệu cho chứng thực proxy là được cung cấp ở 3GPP TS 24.109
4.7.4.1. XCAP client thao tỏc danh sỏch nguồn
Hỡnh 4.12 trờn chỉ ra như thế nào XCAP client cú thể thao tỏc danh sỏch nguồn XCAP server. Chi tiết của luồng tớn hiệu đú là:
• 1. XCAP PUT (XCAP client tới XCAP server) XCAP client phỏt ra một yờu
cầu XCAP PUT để tạo một danh sỏch nguồn mới ở XCAP server. Dỏnh sỏch nguồn này cú một mục nhập.
• 2. XCAP 201 (Created) (XCAP server tới XCAP client) Sau khi XCAP server đó thực hiện kiểm tra chứng thực cần thiết trờn nguồn để chắc chắn XCAP client là được phộp để tạo tệp thụng tin. XCAP server gửi đỏp ứng
XCAP 201 (Created) tới XCAP client.
• 3. XCAP PUT ( XCAP client tới XCAP server) XCAP client thờm vào một
UE(XCAP CLIENT) AS(XCAP Server) 1.XCAP PUT 2.XCAP 201 (Created) 3.XCAP PUT 4.XCAP 200 (OK) 5.XCAP DELETE 6.XCAP 200 (OK) 7.XCAP GET 8.XCAP 200 (OK)
Hỡnh 4.12 XCAP client thao tỏc danh sỏch nguồn ở XCAP server
• 4. XCAP 200 (OK) (XCAP server tới XCAP client) Sau khi XCAP server đó
thực hiện kiểm tra chứng thực cần thiết, tài liệu XML cú giỏ trị và giản đồ
XML phự hợp thỡ XCAP server gửi đỏp ứng XCAP 200 (OK) tới XCAP client
• 5. XCAP DELETE (XCAP client tới XCAP server) XCAP client quyết định
xúa mục “user2” từ danh sỏch nguồn. XCAP client phỏt ra một yờu cầu XCAP DELETE.
• 6. XCAP 200 (OK) (XCAP server tới XCAP client): luồng tớn hiệu này hoạt
động tương tự như luồng tớn hiệu 4.
• 7. XCAP GET (XCAP client tới XCAP server) XCAP client muốn kiểm tra
của lần vận chuyển trước bằng việc phỏt ra một yờu cầu XCAP GET.
• 8. XCAP 200 (OK) (XCAP server tới XCAP client) Sau khi XCAP server đó
thực hiện kiểm tra chứng thực cần thiết, tài liệu XML cú giỏ trị và giản đồ
XML phự hợp thỡ XCAP server gửi đỏp ứng XCAP 200 (OK) tới XCAP client
bao gồm danh sỏch nguồn ở thõn của đỏp ứng
4.7.4.2. XCAP client thao tỏc chớnh sỏch cấp phộp phục vụ dịch vụ kiểm tra trạng
thỏi người dựng
Hỡnh 4.12 cũng chỉ ra như thế nào XCAP client cú thể thao tỏc chớnh sỏch cấp phộp ở
• 1. XCAP PUT (XCAP client tới XCAP server) XCAP client phỏt ra một yờu cầu XCAP PUT để tạo một chớnh sỏch cấp phộp presence ở XCAP server. Chớnh sỏch cấp phộp cú một luật cho phộp “sip:user2_publisc1@home2.net” nhỡn thấy tất cả thụng tin phục vụ cựng với nhõn tố liờn quan định nghĩa ở
“draft-ietf-simle-prescaps-ext”.
• 2. XCAP 201 (Created) (XCAP server tới XCAP client) luồng tớn hiệu này
• 3. XCAP PUT (XCAP client tới XCAP server) XCAP client đưa luật tới chớnh sỏch cấp phộp presence bằng việc phỏt ra một yờu cầu XCAP PUT mới. Luật mới thờm vào sẽ khúa người dựng cú tờn là “sip:user3_public@home3.net” nhỡn thấy thụng tin trạng thỏi của người dựng.
• 4. XCAP 200 (OK) (XCAP server tới XCAP client): luồng tớn hiệu này tương
tự luồng tớn hiờu 4 ở mục 4.7.4.1
• 5. XCAP DELETE (XCAP client tới XCAP server) XCAP client quyết định
xúa luật cho “sip:user2_public1@home2.net” từ chớnh sỏch cấp phộp. XCAP
client phỏt ra yờu cầu XCAP DELETE.
• 6. XCAP 200 (OK) (XCAP server tới XCAP client) : Luồng tớn hiệu này
tương tự luồng tớnh hiệu 4 ở mục 4.7.4.1
• 7. XCAP GET (XCAP client tới XCAP server) XCAP client muốn kiểm tra
• 8. XCAP 200 (OK) (XCAP server tới XCAP client) Sau khi XCAP server đó thực hiện kiểm tra chứng thực cần thiết, tài liệu XML cú giỏ trị và giản đồ XML phự hợp thỡ XCAP server gửi đỏp ứng XCAP 200 (OK) tới XCAP client bao gồm luật cấp phộp ở thõn của đỏp ứng.
CHƯƠNG V: THỰC HIỆN DỊCH VỤ
5.1. Mụ hỡnh triển khai dịch vụ
Hỡnh 5.1 Mụ hỡnh thực hiện dịch vụ presence trong IMS
5.2. Presence server
Openser là phần mềm mó nguồn mở được viết bằng C trờn linux, module presence cú chức năng như một presence server thực hiện dịch vụ kiểm tra trạng thỏi người dựng. Nú quản lớ thụng điệp PUBLISH và SUBSCRIBE, đồng thời cũng phỏt ra cỏc thụng điệp NOTIFY. Nú cho phộp đăng kớ cỏc sự kiện tới nú từ những openser module khỏc. Nú cũng phỏt triển memory cache để tăng hiệu suất hoạt động. Thụng
tin được chứa trong bộ nhớ và được cập nhật vào cơ sở dữ liệu theo chu kỳ. Cỏc biến là cỏc hàm trong việc thực hiện AS presence server
• Exported Parameters (cỏc biến xuất)
o db_url(str): Nếu biến này được thiết lập, module presence sẽ hoạt động với
đầy chức năng của presence server. Trong trường hợp khỏc nú sẽđược sử
dụng như là 1 thư viện cho những chức năng suất của nú. Giỏ trị mặc định là “NULL”.Vớ dụ thiết lập biến db_url:
modparam("presence","db_url",
"mysql://openser:openserrw@192.168.7.97/openser")
o presentity_table(str): Tờn của cụ sở dữ liệu nơi mà thụng tin trạng thỏi của một thực thể cung cấp thụng tin xuất bản ra sẽđược chứa đựng vào trong nú. Giỏ trị mặc định là “presentity”. Vớ dụ thiết lập biến presentity_table:
Modparam(“presence”, “presentity_table”, “presentity”)
o active_watcher_table(str): Tờn của bảng cơ sở dữ liệu nơi mà thụng tin đăng kớ hoạt động được chứa đựng. Giỏ trị mặc định là “active_watchers”.
Vớ dụ thiết lập biến active_watchers_table:
Modparam(“presence”, “active_watchers”, “active_watchers”)
o watcher_table(str):Tờn của bảng cơ sở dữ liệu nơi mà trạng thỏi đăng ký
được chứa đựng. Giỏ trị mặc định là “watchers”.Vớ dụ thiết lập biến watcher_table.
modparam("presence", "watchers_table", "watchers")
o clean_period(int): Chu kỡ để kiểm tra thụng điệp đó hết hạn trong cơ sở dữ
liệu. Giỏ trị mặc định là “100”.Vớ dụ thiết lập biến clean_period. modparam("presence", "clean_period", 100)
o to_tag_pref(str): Tiền tố được sử dụng khi phỏt sinh to_tag khi gửi đỏp ứng cho yờu cầu SUSBSCRIBE. Vớ dụ thiết lập biến to_tag_pref :
modparam("presence", "to_tag_pref", 'pres')
o expires_offset(int): Giỏ trị sẽ bị được trừ từ giỏ trị hết hạn khi gửi đỏp ứng 200OK cho một Publish. Nú được sử dụng để yờu cầu client gửi cập trước khi
một thụng tin publish cũ hết hạn. Giỏ trị mặc định là “0”.Vớ dụ thiết lập biến expires_offset:
modparam("presence", "expires_offset", 10)