Một B2BUA chỉ đơn giản là hai SIP UA kết nối với nhau .Hỡnh 3.3 chỉ ra cấu trỳc logic của một B2BUA.
Hỡnh 3.4 AS ứng dụng đúng vai trũ SIP B2BUA
Một request A được nhận tại một bờn của UA, sẽ đi qua phần logic dịch vụ đặc trưng.Logic dịch vụ đặc trưng chịu trỏch nhiệm tạo ra response A và tạo ra một request B mới.Logic dịch vụ đặc trưng cú thể thay đổi cỏc trường mà SIP Proxy AS khụng thể thay đổi như To, From, Call-ID,...thậm chớ thay đổi cả method.
Một vớ dụ của cấu hỡnh này là AS đúng vai trũ là prepaid AS. Trong một phiờn đang diễn ra nếu tài khoản của người gọi khụng cũn thỡ nú sẽ gửi BYE request
đến cỏc thành viờn tham gia phiờn để giải phúng phiờn.
3.2.3. AS đúng vai trũ là SIP Proxy mỏy chủứng dụng:
Trong cấu hỡnh này A S đúng vai trũ là SIP Proxy AS để cung cấp dịch
vụ.Cấu hỡnh được chỉ ra như trong hỡnh 3.5 cung cấp dịch vụ cho người gọi.Thiết bị đầu cuối gửi một bản tin INVITE request tới P-CSCF và S-CSCF. S-CSCF nhận thấy dịch vụ cú liờn quan đến AS và chuyển tiếp bản tin tới AS đú. AS cú thể thay đổi một số trường header trong bản tin.Vớ dụ như AS đang cung cấp dịch vụ quay số nhanh.
Hỡnh 3.5 AS ứng dụng đúng vai trũ SIP Proxy AS 3.2.4. AS đúng vai trũ là một SIP redirect mỏy chủ ứng dụng:
Hỡnh 3.6 AS ứng dụng đúng vai trũ SIP Redirect AS
Theo hỡnh một I-CSCF trong mạng chủ nhận bản tin INVITE(1). I-CSCF
chuyển tiếp nú tới S-CSCF (2). S-CSCF liờn quan đến một AS và sẽ chuyển tiếp bản tin INVITE yờu cầu này tới nú (3). AS hoạt động như một SIP redirect AS tạo ra một bản tin 302 (Tạm thời chuyển Moved temporarily) đỏp ứng lại (4). Đỏp ứng này chức trường Contact bao gồm URI mới để liờn lạc. Đỏp ứng này được chuyển tiếp lại cho nguồn, (5) & (6). Khi nguồn của phiờn nhận được bản tin đỏp ứng 302, nú sẽ tạo ra một yờu cầu INVITE mới mà request URI của nú là giỏ trị trường Contact nhận được
trong bản tin 302. Bản tin INVITE mới này cú thể khụng đến trong cựng một miền IMS.Một vớ dụ tiờp biểu về khả năng ứng dụng như SIP redirect Mỏy chủ ứng dụng là provision của dịch vụ chuyển tiếp cuộc gọi.
3.3. Giao diện AS với cỏc thành phần khỏc trong mạng : 3.3.1. Giao diện với IMS core – ISC :
Giao diện giữa AS ứng dụng SIP với S-CSCF được gọi là ISC (IMS Service Control – Điều khiển dịch vụ IMS). Tựy thuộc vào chức năng của mỏy chủứng dụng, mà thủ tục của ISC cú thể chia thành hai nhúm:
Cho cỏc phiờn mới khởi tạo bản tin SIP, S-CSCF phõn tớch chỳng dựa trờn tiờu chớ lọc khởi tạo (initial filter criteria) từ hồ sơ người dựng (user profile) - là một phần của cơ sở dữ liệu thuờ bao HSS và định tuyến chỳng tới đỳng AS ứng dụng cho cỏc quỏ trỡnh xử lý tiếp theo.
Khi đú mỏy chủ ứng dụng cú thể đúng vai trũ User Agent AS, SIP
proxy hay Redirect AS.
AS ứng dụng Sip cũng cú thể khởi tạo bản tin SIP của chớnh nú và hoạt
động giống một User Agent Client hay B2BUA. (Trong trường hợp
dịch vụ Click to dial thỡ mỏy chủ ứng dụng đúng vai trũ B2BUA làm trung gian giao tiếp giữa bờn gọi và bờn bị gọi).
3.3.2. Giao diện với HSS – Sh:
Giao diện Sh định nghĩa giữa SIP AS Hay OSA-SCS với HSS. Nú cung cấp một dữ liệu dự trữ và cỏc loại chức năng phục hồi như là ASứng dụng tải dữ liệu về
từ HSS hày mỏy chủứng dụng tải dữ liệu lờn HSS. Những dữ liệu này cú thể phục vụ
thi hành scripts hay cỏc tham số cấu hỡnh mà người dựng và một dịch vụ cụ thể cú thể
sử dụng được . Giao diện Sh cũng cung cấp dịch vụđăng kớ và thụng baú, để AS cú thểđăng kớ nhận thụng bỏo khi cú sự thay đổi về dữ liệu chứa trong HSS. Khi những
Việc thực hiện giao diện Sh là tựy chọn của mỏy chủ ứng dụng và phụ thuộc vào bản chất của dịch vụ mà AS cung cấp: Một vài dịch vụ yờu cầu tương tỏc với HSS trong khi một số dịch vụ khỏc thỡ khụng.
Mỗi AS cú thể tựy chọn giao tiếp với HSS sử dụng giao thức Diameter thụng qua giao diện Sh. Giao thức Diameter cơ sở thực hiện chức năng nhận thực, chứng thực và tớnh cước trong IMS và trong mạng thế hệ sau. Nú cung cấp khả năng thương lượng giữa cỏc thực thể trong mạng liờn quan tới truyền thụng, cảnh bỏo lỗi, truyền nhận AVP và một khả năng mở rộng cho phộp bạn cú thể thờm những lệnh cụ thể và
AVP mới.
Mỏy chủ ứng dụng, trong trường hợp này là Web Logic. Mỏy chủ ứng dụng SIP cú thể sử dụng lệnh UDR (User Data Request) để yờu cầu dữ liệu. HSS sẽ trả lời về bằng bản tin UDA (User Data Answer) cú chứa dữ liệu được yờu cầu và mó kết quả. Mó này chỉ ra là bản tin cú thành cụng hay khụng. Vớ dụ một thao tỏc thành
cụng sẽđược trả về với mó 2001 DIAMETER_SUCCESS.
Dưới đầy là danh sỏch cỏc đầu cuối cú thể liờn quan trong trao đổi thụng tin DIAMETER (WLSS thường thực hiện tất cả cỏc chức năng trừ chức năng AS Diameter).
DIAMETER AGENT: một nỳt diameter cung cấp hoặc là cỏc dịch vụ chuyển
tiếp, tỏi định hướng hay chuyển đổi
DIAMETER client : là một thiết bị ở sườn của mạng thực hiện cỏc chức năng truy nhập
Nỳt DIAMETER : là một mỏy chủ tiến trỡnh thực thi giao thức DIAMETER,
và hoạt động giống như hoặc client hoặc AS hoặc agent.
DIAMETER Peer : Một nỳt DIAMETER mà đến nú một nỳt DIAMETER cú
một kết nối vận chuyển trực tiếp.
RELAY Agent : một thực thể thực hiện chức năng chuyển tiếp yờu cầu và đỏp
Giao diện này cho phộp một mỏy chủứng dụng giao tiếp với HSS để lấy được cỏc dữ liệu cần thiết để cấp phỏt cỏc logic dịch vụ. Cỏc loại dữ liệu này là duy nhất đối với một người dựng. Thường là, một hồ sơ người dựng chứa một tới một vài hồ sơ
dịch vụ, mỗi hồ sơ dịch vụ này định nghĩa dịch vụ sẽđược thực hiện như thế nào Dữ liệu người dựng trờn giao diện Sh : User data là một khỏi niệm dựng để đề
cập đến cỏc loại dữ liệu liệu khỏc nhau, cú thể là bất cứ thụng tin nào trong số :
Repository data : mỏy chủ ứng dụng sử dụng HSS để chứa cỏc dữ liệu trong suốt. Cỏc dữ liệu này chỉ được hiểu bởi cỏc mỏy chủ ứng dụng cú triển khai dịch vụđú. Dữ liệu này khỏc nhau tựy từng người dựng và tựy từng dịch vụ.
Public Identifiers : tập cỏc định danh chung của người dựng
IMS user state : chứa cỏc thụng tin về trạng thỏi người dựng IMS của một định
danh chung của người dựng: REGISTERED, NOT_REGISTERED,
AUTHEN_PENDING, REGISTER_UNREGISTED_SERVICE.
S-CSCF name : chứa địa chỉ của cỏc S-CSCF cấp phỏt cho người dựng
Initail filter criteria : chứa cỏc thụng tin kớch hoạt cho một dịch vụ. Một AS
ứng dụng cú thể chỉ cần lấy cỏ tiờu chớ lọc khởi tạo để định tuyến bản tin sip tới AS ứng dụng yờu cầu.
Location Information : chứa vị trớ của người dựng trong mạng chuyển mạch gúi hay mạng chuyển mạch kờnh.
User State : chứa trạng thỏi của người dựng trong mạng chuyển mạch gúi hay mạng chuyển mạch kờnh.
Hỡnh 3.7 SH DATA UML DIAGRAM
Việc thực thi giao diện Sh trong một mỏy chủứng dụng cú thể hoạt động ở hai modes: Data Handling và Subscriptions/ Notification
Data Handling (Pull/Update) : Data handling thường được chứa trong Sh Pull
(để lấy dữ liệu từ HSS) và Sh Update để chứa dữ liệu vào trong HSS. Khi bạn truy nhập dữ liệu từ HSS bạn đạng tạo ra một yờu cầu Sh Pull request, và khi bạn chứa dữ liệu vào trong HSS bạn đang thực hiện một yờu cầu Sh Update
Subscription/Notifications : mode này cho phộp WLSS lấy cỏc thụng tin thụng
bỏo khi một dữ liệu cụ thể của một người dựng cụ thểđược HSS cập nhật bởi một vài thực thể mạng khỏc.
Trong trường hợp cụ thể của dịch vụ này, giao diện Sh hầu như chỉ hoạt động
ở mode điều khiển dữ liệu (Data handling). Dưới đõy là cỏc thành phần thụng tin cú liờn quan trong thủ tục Sh Pull (để lấy dữ liệu người dựng từ HSS) và Sh
Update (Để cập nhật thụng tin cho một người dựng – một định danh chung IMS
đó được đăng kớ).
Tờn thành phần thụng tin Ánh xạ tới AVP Mụ tả
User Identity User-Identity Định danh người dựng của dữ liệu
được yờu cầu
Requested-data Data-reference Chỉ ra danh sỏch cỏc thụng tin yờu
cầu Requested-domain Requested-
domain
Chỉ ra miền mà thao tỏc này cú
hiệu lực
Current-location Current-location Chỉ ra vị trớ truy nhập đó được
khởi tạo hay chưa
Service-indication Service-indication Sử dụng cựng với User identity và
data reference đưa ra một tập hợp cỏc dịch vụ liờn quan tới dữ liệu
đang được yờu cầu
Application-mỏy chủứng
dụng-identity
Origin-host Chỉ ra định danh của ASứng dụng,
sử dụng cho HSS kiểm tra lại
trong danh sỏch cho phộp của nú
(ASpermision list)
Application-name Mỏy chủ ứng
dụng-name
Sử dụng cựng với User identity và data reference như là khúa để xỏc
định tiờu chớ lọc khởi tạo Hỡnh Sh-Pull
Tờn thành phần thụng tin Ánh xạ tới AVP Mụ tả
User Identity User-Identity Định danh chung IMS của người dựng
mà dữ liệu yờu cầu được cập nhật
Data User-data Thụng tin cập nhật
Mỏy chủứng dụng identity
Origin-host Chỉ ra ASkhởi tạo yờu cầu và được sử
dụng trong kiểm tra danh sỏch
CHƯƠNG IV: CƠ SỞ LÍ THUYẾT XÂY DỰNG DỊCH VỤ
PRESENCE TRONG IMS 4.1. Giới thiệu
Dịch vụ presence trong IMS cung cấp một khả năng cho home network để quản lý thụng tin trạng thỏi thiết bị của người sử dụng. Thụng tin trạng thỏi của người sử
dụng trong IMS cú thểđược lấy từ người sử dụng, thụng tin được cung cấp bởi thực thể mạng, hoặc cú thể là thụng tin được cung cấp từ cỏc nhõn tố bờn ngoài mạng. Sử
dụng thụng tin trạng thỏi người dựng là Watcher, watcher cú thể ở bờn trong hoặc bờn ngoài mạng.
Một vớ dụ điển hỡnh của ứng dụng đặc trưng của dịch vụ presence là sổ điện thoại với thụng tin trạng thỏi được nhỳng bờn trong làm cho chỳng cú tớnh năng động rừ rệt. Thụng tin trạng thỏi là thụng tin đầu tiờn người dựng nhỡn thấy khi muốn liờn lạc. Những thụng tin này sẽảnh hưởng đến sự lựa chọn phương thức liờn lạc và thời gian để liờn lạc. Cú thể chỉ ra một vớ dụ đơn giản để thấy được vai trũ của thụng tin trạng thỏi. Khi người dựng A mở Contact để tỡm cỏch liờn lạc với một người dựng B nào đú sẽ thấy được thụng tin hiện tại của người dựng B. Nếu người dựng B đang trong một cuộc họp và khụng sẵn sàng nhận bất cứ một cuộc gọi nào thỡ người dựng A sẽ quyết định dừng liờn lạc và chờđợi khi người dựng kia kết thỳc cuộc họp.
Contact Contact cải tiến Hỡnh 4.1 Contact hiện nay và contact cải tiến với cỏc thụng tin về trạng
4.2. Dữ liệu mụ tả trạng thỏi người dựng
Thụng tin trạng thỏi người dựng bao gồm :
• Tớnh sẵn sàng của người dựng và thiết bị • Những lựa chọn khi liờn lạc • Khả năng của thiết bị • Hoạt động hiện tại • Vị trớ của thiết bị và người dựng • Dịch vụ sẵn cú hiện tại 4.2.1. Dạng cơ bản (PIDF)
PIDF được thiết kếđể mang ngữ nghĩa của thụng tin trạng thỏi người dựng từ thực thể này tới thực thể kia. PIDF được miờu tảở RFC 3863. PIDF mó húa thụng tin trạng thỏi người dựng trong tài liệu XML, cỏi mà cú thểđược vận chuyển. Giống
như bất kỳ tài liệu MIME khỏc, trong hoạt động PUBLISH và
SUBSCRIBE/NOTIFY thụng tin trạng thỏi, PIDF định nghĩa một định dạng MIME
media mới là application/pidf+xml để chỉ ra định dạng của dữ liệu và mó húa.
4.2.1.1 Chứa đựng của PIDF
Tài liệu PIDF chứa thụng tin trạng thỏi người dựng của một thực thể cung cấp thụng tin. Thụng tin này bao gồm nhiều nhõn tố, Hỡnh 4.2 chỉ ra cỏc nhõn tố
thụng thụng tin gồm một hoặc nhiều PRESENCE TUPLES, mỗi PRESENCE
TUPLES bao gồm stastus của thực thể cung cấp thụng tin trạng thỏi ( presence) với
giỏ trị open hoặc closed (online hoặc offline), gồm nhõn tố lựa chọn
COMMUNICATION ADDRESS bao gồm COMMUNICATION MEANS và
CONTACT ADDRESS. PRESENCE TUPLES cũn cú nhõn tố lựa chọn OTHER
PRESENCE MARKUP. Nhõn tố CONTACT cung cấp một liờn hệ URI , NOTE và
Hỡnh 4.2 Thụng tin trạng thỏi người dựng
• Nhõn tố <presence>: Cỏc nhõn tố của PIDF được kết hợp với khụng gian tờn XML ‘urn:ietf:params:xml:ns:pidf ’ miờu tả sử dụng thuộc tớnh xmls.
Thư mục gốc của đối tượng “application/pidf+xml” là nhõn tố
<presence> kết hợp với khụng gian tờn thụng tin trạng thỏi người dựng. Cỏi này chứa đựng một số nhõn tố <tuple> , tiếp theo bởi một số nhõn tố
khỏc. Nhõn tố <presence> phải cú thuộc tớnh ‘entity’ cú giỏ trị là ‘pres’ URL của thực thể xuất tài liệu trạng thỏi thụng tin. Nhõn tố <presence> cũng phải chứa đựng tuyờn bố khụng gian tờn ‘urn:ietf:params:ns:pidf:’
để chỉ ra tài liệu trạng thỏi cơ bản là được xõy dựng. <presence> cũng cú thể chứa đựng miờu tả khụng gian tờn cho mở rộng tài liệu presence
• Nhõn tố <tuple>: Là nhõn tố mang một PRESENCE TUPLE, chứa đựng một nhõn tố <status>, theo sau bởi một số nhõn tố mở rộng lựa chọn ( cú thể từ cỏc khụng gian tờn khỏc) và nhõn tố <contact>, và nhõn tố lựa chọn <note>, <timestamp>. Cỏc tuples cung cấp cỏch để phõn đoạn dữ
liệu. Giao thức hoặc ứng dụng cú thể chọn để phõn đoạn thụng tin kết hợp với một thực thể cung cấp thụng tin (presentity) do một thụng tin trạng thỏi đầy đủ cú thể lấp từ nhiều thiết bị hoặc nhiều ứng dụng khỏc nhau. <tuple> phải chứa đựng thuộc tớnh ‘id’ để phõn biệt cỏc tuple khỏc nhau trong cựng một thực thể cung cấp thụng tin. Trong <tuple> nhõn tố
<contact> là lựa chọn bởi vỡ một presentity cố thể cần ẩn
COMMUNICATION ADDRESS của nú hoặc cú thể là một tuple khụng
liờn quan tới COMMUNICATION MEANS. Tuple mà chứa dựng một
nhõn tố trang thỏi <basic> sẽ chứa đựng một nhõn tố địa chỉ <contact>. Cỏc <tuple> cú thể chứa đựng trạng thỏi presence đối lập nhau – một tuple cú thể cung cấp một <basic> <status> OPEN trong khi một <tuple> khỏc trong cựng một PIDF cú thể cung cấp một <basic><status> CLOSE. Thậm chớ cả hai cựng trong một nhõn tốđịa chỉ <contact>.
• Nhõn tố <basic> là nhõn tố chứa chuỗi “open” hoặc “close”. Giỏ trị
“open” và “close” chỉ ra khả năng sẵn sàng để nhận tin nhắn nhanh (INSTAN MESSAGE) nếu tuple là cho địa chỉ tin nhắn nhanh. Nú cũng chỉ ra tớnh sẵn sàng chung cho cỏc cỏch thức liờn lạc khỏc.
• Nhõn tố <contact> là nhõn tố chứa URL của địa chỉ liờn lạc
• Nhõn tố <note> là nhõn tố chỳ thớch, cú thể xuất hiện ở cỏc nhõn tố con của <presence> hoặc trong cỏc nhõn tố con của <tuple>
• Nhõn tố <timestamp>: là nhõn tố chứa đựng chuỗi chỉ ra thời gian mà trạng thỏi tuple thay đổi. Giỏ trị thời gian của nhõn tố này phải tuõn theo chuẩn định dạng thời gian IMPP RFC 3339. Đõy là một vớ dụ của PIDF của một nhận dạng presentity ( pres: alice @example.com)
4.2.2. Dạng mở rộng (RPIDF)
PIDF khụng cung cấp đầy đủ chi tiết thụng tin, RPID là mở rộng PIDF, nú cho phộp một presentity núi rừ cỏc chi tiết và nhiều thụng tin presence hơn tới watcher.
Giống PIDF, RPIDF được mó húa ở XML, nú cũng sử dụng định dạng
application/pidf+xml. RPIDF được miờu tả ở RFC 4480
4.2.2.1. Chứa đựng của RPIDF
Một thực thể presentity cú thể thiết lập thụng tin presence mở rộng bằng hoạt động tự động dựa trờn một thiết lập thớch hợp trờn phần mềm presence của