Tiểu luận môn Nền tảng cung cấp dịch vụ cho mạng thế hệ mới Giao thức SIP, bản tin SIP, định tuyến bản tin SIP, SIP trong IMS

TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI
VIỆN ĐÀO TẠO SAU ĐẠI HỌC
BÀI TẬP MÔN HỌC
Nền tảng cung cấp dịch vụ cho mạng thế hệ mới
ĐỀ TÀI 8:
Giao thức SIP, bản 9n SIP, định tuyến bản 9n SIP, SIP trong IMS…
Hà Nội, tháng 6/2012
Giảng viên hướng dẫn : TS. NGUYỄN TÀI HƯNG
Học viên cao học : MAI THỦY ANH-CB110807
PHẠM LÊ MINH-CB110881
Lớp : KTTT1
Mở đầu
Giao thức khởi tạo phiên (SIP) là một giao thức báo hiệu mới xuất hiện thực hiện điều
khiển phiên cho các kết nối đa dịch vụ. Về cơ bản, hoạt động điều khiển bao gồm khởi
tạo, thay đổi và kết thúc một phiên có liên quan đến các phần tử đa phương tiện như
video, thoại, tin nhắn, game trực tuyến, vân vân.
SIP đem lại ba năng lực chính cho mạng viễn thông. Thứ nhất, nó kích thích sự phát triển
của các mô hình ứng dụng và dịch vụ dựa trên web. Đây là một điều hết sức thuật lợi cho
nhà cung cấp dịch vụ do có thể sử dụng một nguồn tài nguyên dồi dào các công cụ sẵn
có, đồng thời cũng thuận lợi đối với người sử dụng khi người sử dụng đã quen thuộc với
kỹ thuật web và nó cũng đã được triên khai trên phần lớn các thiết bị thông minh ngày
nay. Điều này tăng cường khả năng cung cấp các dịch vụ mới một cách nhanh chóng.
Năng lực thứ hai là khả năng mở rộng, do SIP là giao thức báo hiệu đồng cấp và có tính
phân bố cao. Khác với các giao thức báo hiệu truyền thống thường có tính xử lý tập trung
cao, điển hình là SS7, trong đó hoạt động của nó tập trung tại một số điểm báo hiệu trong
một cấu trúc mạng báo hiệu phức tạp; các phần tử của SIP phân tán đến tận biên của
mạng và được nhúng tới tận các điểm đầu cuối.
Cuối cùng là khả năng phổ cập của SIP. Được phát triển bởi IETF, SIP kế thừa các đặc
điểm của hai giao thức Internet đã được phát triển rất phổ biến: đó là Hyper Text
Transport Protocol (HTTP) sử dụng cho Web và Simple Mail Transport Protocol (SMTP)
sử dụng cho e-mail. Dựa vào các nguyên tắc có được từ môi trường IP, SIP được thiết kế

là giao thức độc lập với ứng dụng, rất mềm dẻo và có khả năng áp dụng trong nhiều môi
trường khác nhau và cung cấp các dịch vụ đa dạng.
Tóm lại, đặc điểm của SIP là đơn giản, mở, dễ dàng triển khai, và tương thích với các
giao thức IP đã có.
1. Giao thức SIP
SIP là một giao thức báo hiệu thường được sử dụng để thiết lập, chỉnh sửa, và kết thúc
một phiên giữa hai điểm đầu cuối. SIP có thể được sử dụng để thiết lập một cuộc gọi
giữa hai bên, một cuộc gọi nhiều bên, hoặc một phiên multicast cho các cuộc gọi
Internet, các cuộc gọi đa phương tiện và phân phối đa phương tiện.
Một cách đơn giản để mô tả SIP là xem xét một mô hình sử dụng. Giả sử một người
dùng có định danh là A muốn thiết lập cuộc gọi với người dùng có định danh là B.
Trong viễn thông, người dùng A và người dùng B có thể giao tiếp thông qua một thiết
bị được gọi là tác nhân người dùng (User Agent). Một ví dụ về User Agent là một
soft phone, một chương trình phần mềm sử dụng để thiết lập cuộc gọi điện thoại qua
Internet. Một ví dụ khác là VoIP Phone, một loại điện thoại cho phép sử dụng VoIP
(Voice over IP). Dưới đây là các bước cần thiết để thiết lập một cuộc gọi:
• A mời B bắt đầu cuộc hội thoại. Như một phần của lời mời, A sẽ chỉ
ra loại media nào sẽ được hỗ trợ.
• B nhận lời mời, gửi đáp ứng trung gian tới người dùng A, và sau đó đánh
giá lời mời.
• Khi B sẵn sàng chấp nhận lời mời, nó gửi một xác nhận lại cho người
dùng A. Như một phần của xác nhận, B cũng chỉ ra loại media mà nó hỗ
trợ.
• A kiểm tra xác nhận mà nó nhận được từ B và quyết định xem liệu media hỗ
trợ bởi A và B có giống nhau không. Nếu A và B hỗ trợ cùng một loại media, cuộc
gọi sẽ được thiết lập giữa A và B.
SIP cung cấp một phương thức chuẩn để thực hiện các bước này. Nó thực hiện việc
này bằng cách định nghĩa ra các phương thức yêu cầu (request), đáp ứng (response),
mã đáp ứng (response code) và các trường điều khiển đặc trưng cho báo hiệu và
điều khiển cuộc gọi. Giao thức này được chuẩn hóa bởi IETF (Internet Engineering

Task Force) theo RFC 3261 và hiện nay nó được chấp nhận rộng rãi như một
chuẩn báo hiệu cho 3GPP (3
rd
Generation Partnership Project) và như là một
thành phần không thể thiếu trong kiến trúc IMS.
1.1. SIP liên hệ với HTTP như thế nào
Như đã nói ở trên, SIP kế thừa các đặc tính quan trọng của HTTP. Nó chia sẻ nhiều đặc
điểm quan trọng với HTTP và cũng chính vì vậy nhiều người thường thắc mắc
liệu SIP có sử dụng HTTP như một giao thức nền? Câu trả lời là không. SIP là một
giao thức hoạt động ở cùng một tầng UDP, SCTP như là các giao thức nền của lớp
dưới. Tuy nhiên SIP có rất nhiều điểm giống với HTTP. Ví dụ, tương tự như
HTTP, SIP cũng là một giao thức dựa trên văn bản (text-based) và người dùng có khả
năng đọc được. Cũng giống như HTTP, SIP sử dụng cơ chế yêu cầu – đáp ứng
(request – response mechanism) với các phương thức đặc trưng, mã đáp ứng và
các trường điều khiển. Tuy nhiên, một điểm khác biệt quan trọng giữa HTTP và SIP là
cơ chế yêu cầu – đáp ứng trong SIP là không đồng bộ một yêu cầu không nhất thiết
theo sau nó là một đáp ứng tương ứng. Thực tế, yêu cầu SIP thường có thể gây ra một
vài yêu cầu khác được tạo ra.
SIP là một giao thức ngang hàng (peer-to-peer protocol). Điều này có nghĩa là người
dùng cuối (User Agent) có thể hoạt động như một Server cũng như có thể hoạt động
như một Client. Đây là một điểm khác biệt giữa SIP và HTTP. Trong HTTP, máy
client thì sẽ luôn luôn là máy client, máy chủ sẽ luôn luôn là máy chủ.
SIP hỗ trợ các phương thức yêu cầu và mã đáp ứng sau:
• REGISTER: sử dụng bởi client để đăng ký địa chỉ với máy chủ ứng dụng.
• INVITE: chỉ ra rằng người dùng hay dịch vụ đang được mời tham gia
vào một phiên. Phần thân của bản tin này bao gồm một mô tả phiên mà
người dùng dịch vụ đang được mời.
• ACK: xác nhận rằng client nhận được đáp ứng cuối cùng của một bản tin
invite. Phương thức này chỉ được sử dụng với yêu cầu invite.
• CANCEL: sử dụng để bỏ qua một yêu cầu đang chờ xử lý.

• BYE: gửi một user client agent để chỉ định với máy chủ là nó muốn kết
thuc cuộc gọi.
Mã hồi đáp:
• 1xx: thăm dò. Một ACK chỉ định một hành động đã được nhận thành công,
được hiểu và được chấp nhận.
• 3xx: chuyển hướng. Yêu cầu thêm các hành động khác để xử lý yêu cầu.
• 4xx: lỗi client. Yêu cầu có chứa cú pháp sai và không thể hoàn thành
ở máy chủ.
• 5xx: lỗi máy chủ. Máy chủ thất bại trong việc hoàn thành một yêu cầu hợp
lệ.
• 6xx: lỗi toàn cục. Yêu cầu không thể hoàn thành ở bất cứ máy chủ
nào.
Giao thức mô tả phiên (SDP) là một định dạng cho việc mô tả định dạng media
và loại media được dùng trong một phiên. SIP sử dụng SDP như là một phần tải
trong bản tin của nó để thực hiện chức năng trao đổi khả năng giữa các người dùng.
Ví dụ, nội dung của SDP có thể chỉ ra loại mã hóa hỗ trợ bởi user agent và giao thức
sử dụng trao đổi thời gian thực (RTP).
1.2. Bản tin SIP
Cấu trúc của bản tin SIP:
Hình 3-20 : Cấu trúc bản tin SIP
Hình trên chỉ ra cấu trúc thành phần của một bản tin SIP. Có 3 thành phần quan trọng:
• Dòng yêu cầu: chỉ ra phương thức yêu cầu, địa chỉ và phiên bản SIP.
• Trường điều khiển: chỉ ra dữ liệu về phiên hay cuộc gọi được thiết lập hay
kết thúc.
• Phần thân bản tin: cung cấp payload, SDP mô tả media của phiên.
1.3. Phiên giao dịch (Transaction)
Mặc dù nói các bản tin SIP được gửi đi một cách độc lập qua mạng nhưng thực tế
chúng thường được sắp xếp vào các transaction (giao dịch) bởi các user agent và một
số kiểu proxy server nào đó. Do đó có thể nói giao thức SIP là một giao thức hỗ trợ
transaction.

Một transaction là một luồng các bản tin SIP được truyền đi một cách tuần tự giữa các
phần tử mạng. Một transaction là một luồng bản tin SIP được truyền đi một cách tuần tự
giữa các phần tử mạng. Một transaction chứa thông tin yêu cầu và tất cả các thông tin
phản hồi cho thông tin yêu cầu đó hoặc thậm chí nhiều hơn các thông tin phản hồi cuối
(final response).
Nếu một transaction được khởi tạo bởi bản tin yêu cầu INVITE thì transaction
đó cũng bao gồm cả bản tin ACK nếu như phản hồi cuối không phải là kiểu 2xx.
Nếu như phản hồi cuối là kiểu 2xx thì bản tin ACK sẽ không được xem là một
thành phần trong transaction.
Nếu như vậy chúng ta có thể thấy rằng ở đây có sự cư sử không được công bằng – ACK
được coi là một thành phần trong transaction với một lời từ chối ở phản hồi cuối, trong
khi nó lại không phải là một thành phần transaction khi được chấp nhận ở phản hồi cuối.
Lý do cho sự phân biệt này là sự quan trọng của tất cả các bản tin 200 OK. Không những
nó thiết lập một phiên mà bản tin 200 OK còn được sinh ra bởi các thực thể khi
một proxy server chuyển hướng yêu cầu và tất cả các proxy server đó phải chuyển bản
tin 200OK về đến user agent. Do đó, trong trường hợp này user agent phải lãnh
trách nhiệm và truyền lại bản tin 200 OK cho đến khi chúng nhận được bản tin ACK.
Một lưu ý khác nữa là chỉ có bản tin INVITE là được truyền lại.
Các thực thể SIP có khái niệm về transaction được gọi là stateful. Các thực thể này
tạo một trạng thái kết nối với một transaction được lưu trong bộ nhớ trong suốt khoảng
thời gian diễn ra transaction. Khi có thông tin yêu cầu hay phản hồi đến, một thực thể
stateful sẽ cố gắng kết nối yêu cầu (hoặc phản hồi) đó tới một transaction đã tồn tại
sẵn. Để có khả năng làm được điều đó, nó phải lấy thông tin xác định tính duy nhất của
transaction (gọi là identifier)
Hình 3-21 : Transaction
1.4. Hội thoại (dialog)
Ở trên chúng ta đã biết đến transaction, đó là một transaction bao gồm bản tin INVITE
và các bản tin phải hồi, một transaction khác bao gồm bản tin BYE và thông tin phản
hồi (200 OK) khi một phiên làm việc kết thúc. Nhưng chúng ta có thể thấy rằng
cả hai transaction này có liên quan đến nhau và cùng thuộc một hội thoại (dialog).

Một dialog đặc trưng cho mối quan hệ SIP ngang hàng giữa hai user agent. Một
dialog tồn tại trong một khoảng thời gian và nó là một khái niệm rất quan trọng
đối với các user agent. Dialog thích hợp dễ dàng với việc sắp xếp tuần tự và định
tuyến cho các bản tin SIP giữa các thiết bị cuối.
Dialog được xác định bằng call-id, thẻ from và thẻ to. Các bản tin mà có cùng 3
identifier trên thì thuộc về cùng một dialog. Trường điều khiển Cseq được dùng để sắp
xếp thứ tự các bản tin trong cùng một dialog không các user agent sẽ xử lý nó như là
các yêu cầu không được sắp xếp hoặc là sẽ gửi lại bản tin đó. Trong thực tế, số Cseq
xác định một transaction bên trong một dialog bởi chúng ta đã nói ở trên là các yêu cầu
và các thông tin được phản hồi của nó được gọi là một transaction. Điều đó có nghĩa là
chỉ có duy nhất một transaction hoạt động tại một thời điểm trong dialog. Do đó cũng có
thể gọi dialog là một tập tuần tự của các transaction. Hình vẽ dưới đây minh họa các
bản tin truyền đi bên trong một dialog.
Hình 3-22 : Luồng cuộc gọi trong một hội thoại SIP
Một vài bản tin dùng để thiết lập ra một dialog. Nó cho phép biểu diễn rõ ràng, chi
tiết mối quan hệ giữa các bản tin và còn dùng để gửi bản tin mà không liên quan đến
các bản tin khác đến các bản tin nằm ngoài một dialog. Điều đó được thực hiện một
cách dễ dàng bởi user agent không lưu trạng thái của dialog.
Lấy ví dụ, bản tin INVITE thiết lập một dialog, bởi sau đó sẽ có bản tin yêu cầu BYE
dùng để kết thúc dialog tạo ra bởi bản tin INVITE ở trên. Bản tin BYE này được gửi
bên trong dialog được thiết lập bởi bản tin INVITE.
Nhưng nếu user agent gửi một bản tin yêu cầu message, đó là một yêu cầu không thiết
lập bất cứ dialog nào. Khi đó bất cứ các bản tin theo sau bản tin đó (kể cả bản tin
message) cũng được gửi đi một cách độc lập với bản tin trước đó.
1.5. Trường điều khiển Record-Route, Route và Contact
Hình 3-9 mô tả luồng bản tin nơi proxy tại domain.com giữ nguyên đường dẫn cho tất
cả các yêu cầu gửi tới bên trong dialog. Các yêu cầu proxy để giữ nguyên đường dẫn
bằng cách thêm một trường điều khiển Record-Route vào yêu cầu INVITE (2). Tham
số lr xuất hiện ở phần cuối của URI chỉ ra rằng proxy này là phù hợp với RFC 3261
(các proxy cũ hơn được sử dụng với một cơ chế định tuyến khác).

Alice nhận được trường điều khiển Record-Route cùng với URI của proxy trong bản
tin yêu cầu INVITE (2), và Bob nhận được nó trong bản tin hồi đáp 200 OK (4).
Từ thời điểm này, cả Bob và Alice sẽ chèn trường điều khiển Route vào trong các
bản tin yêu cầu của họ, để chỉ ra rằng proxy tại domain.com cần được đi qua. Bản tin
hồi đáp ACK (5) và (6) là một ví dụ về một yêu cầu với trường điều khiển Route được
gửi từ Bob tới Alice. Bản tin BYE (7) và (8) cho thấy các yêu cầu trong các hướng
ngược nhau (ví dụ từ Alice tới Bob) sử dụng cùng cơ chế Route.
2. Máy chủ ứng dụng
Máy chủ ứng dụng (Application Server) là một dụng cụ (engine) phần mềm thực hiện
các ứng dụng cho các máy tính hoặc các thiết bị client thông qua Internet và sử
dụng HTTP. Máy chủ trong IMS bên cạnh những đặc điểm chung như vậy còn có
những đặc điểm riêng. Trong chương này, chúng ta sẽ đi vào tìm hiểu kỹ hơn về khái
niệm, vai trò, các chế độ hoạt động cũng như tương tác của máy chủ ứng dụng IMS với
các thành phần khác trong hệ thống.
2.1. Tổng quan về máy chủ ứng dụng
Trong một mạng, luôn có nhiều hơn một máy chủ ứng dụng. Điển hình, có một vài
máy chủ chuyên mà mỗi loại chuyên cung cấp một dịch vụ riêng biệt. Một vài máy chủ
ứng dụng sẽ triển khai một vài công nghệ, như công nghệ Java, SIP serlvets, hoặc
SIP CGI (Common Gateway Interface). Tất cả các loại máy chủ ứng dụng này
được miêu tả bằng cách triển khai một giao diện SIP kết nối tới S-CSCF. Giao diện
được định nghĩa giữa S-CSCF và máy chủ được biết đến là giao diện điều khiển
dịch vụ IMS (ISC – IMS Service Control).
Máy chủ có thể được đặt tại mạng nhà hoặc đặt tại mạng của nhà cung cấp dịch vụ
thứ ba. Nhưng S-CSCF có nhiệm vụ phải quyết định có kết nối với một máy chủ ứng
dụng nào trong cài đặt phiên hay không. Một điểm nữa, bất kể một máy chủ ứng dụng
nào có thể triển khai trên các giao thức khác nhau như HTTP (Hypertext Transfer
Protocol, mô tả ở RFC 2616 [101]) hay WAP (Wireless Application Protocol [233]),
mặc dù lựa chọn này không được mô tả trong các tiêu chuẩn của IMS.
2.2. Chức năng của máy chủ ứng dụng trong mô hình IMS
Cần luôn nhớ rằng, máy chủ ứng dụng không phải là các thực thể IMS thuần

Hình 4-24 : Hướng tiếp cận dịch vụ trong kiến trúc IMS
Tuy nhiên, máy chủ ứng dụng được mô tả ở đây như là một phần chức năng
của IMS vì máy chủ ứng dụng là các thực thể cung cấp các dịch vụ đa phương
tiện trong kiến trúc IMS, như Presence và Push to talk trong mạng tế bào.
Chức năng của máy chủ ứng dụng là:
• Khả năng xử lý và tác động đến các phiên SIP nhận được từ IMS.
• Khả năng khởi tạo các yêu cầu SIP.
• Khả năng gửi các thông tin thanh toán để thực hiện các chức năng tính cước.
Giá trị chính của IMS trong lĩnh vực dịch vụ là sự kết hợp tiềm năng của các
dịch vụ trên Internet với các dịch vụ truyền thông truyền thống và dịch vụ
Multimedia mới. IMS cho phép cung cấp sự truy nhập ở mọi nơi vào tất cả các
dịch vụ này nhưng có sự cung cấp các giá trị mới tương ứng, như bảo mật và
chất lượng dịch vụ (QoS) trên các máy chủ ứng dụng. Các máy chủ ứng dụng
này có thể được đưa vào kiến trúc IMS bằng cách định nghĩa các giao diện
tính cước, quản lý và điều khiển chuyên dụng. Một máy chủ là phục vụ cho một
dịch vụ và một người dùng, cũng có thể có nhiều hơn một dịch vụ, và như vậy rất
có thể sẽ có một hay một vài máy chủ ứng dụng cung cấp cho một thuê bao.
Thêm vào đó, cũng có thể có một hay một vài máy chủ ứng dụng liên quan tới
một phiên. Ví dụ như, một nhà cung cấp có thể có một máy chủ ứng dụng để
điều khiển việc kết thúc lưu lượng tới các người dùng dựa trên sở thích của
người dùng đó (ví dụ như chuyển hướng tất cả các phiên multimedia tới máy trả
lời tự động trong khoảng từ 5 p.m đến 7 a.m) và một máy chủ ứng dụng khác để
làm thích nghi nội dung của tin nhắn tùy theo năng lực của thiết bị người dùng
(kích thước màn hình, độ phân giải…).
SIP AS (SIP Application Server) là phần liên quan đến dịch vụ trong IMS.
Các giao diện lập trình ứng dụng – API (Application Programming Interface) đã
được định nghĩa cho phép các nhà phát triển sử dụng hầu hết các mô hình lập
trình. SIP AS được kích hoạt bởi S-CSCF, S-CSCF sẽ định hướng các phiên
cụ thể đến SIP AS dựa trên các thông tin lọc khởi tạo thu được từ HSS. Sau đó dựa
trên các nguyên tắc lựa chọn của mình, SIP AS sẽ quyết định các ứng dụng nào sẽ

được triển khai trên máy chủ ứng dụng tương ứng, các máy chủ ứng dụng này
được SIP AS lựa chọn để điều khiển phiên. Trong suốt quá trình thực thi dịch vụ
logic, SIP AS cũng có thể giao tiếp với HSS để truy nhập các thông itn bổ
xung liên quan đến thuê bao.
2.3. Các chế độ hoạt động của máy chủ ứng dụng
Từ góc độ của SIP thì một máy chủ ứng dụng có thể đóng vai trò như là
originating(terminating) UA, Sip Proxy AS, Sip Redirect AS hoặc Sip
B2BUA (back-to-back user agent). Một máy chủ ứng dụng có thể hoạt động với nhiều
vai trò khác nhau phụ thuộc vào dịch vụ cung cấp cho người dùng này hoạt động như
một SIP User Agent (SIP UA) và trả lời bằng bản tin 200OK được gửi qua S-CSCF và
P-CSCF tới thiết bị đầu cuối. Một ví dụ của dịch vụ mà sử dụng mô hình này là dịch
vụ mà trong đó AS được yêu cầu xử lý các bản tin SIP thay cho một người dùng.
Mô hình này được sử dụng trong dịch vụ Presence.
AS
IM S
Home
Netw

Hình 4-25 : AS hoạt động như một SIP UA
Ví dụ của dịch vụ sử dụng mô hình này là bất kỳ dịch vụ nào yêu cầu máy
chủ điều khiển yêu cầu SIP thay cho người dùng. Mô hình này được sử dụng
trong dịch vụ kiểm tra trạng thái người dùng (khi một watcher đăng ký thông
tin trạng thái người dùng của presentity, hoặc người sử dụng).
2.4. AS hoạt động như back-to-back user agent
Một Back-to-Back User Agent (B2BUA) chỉ đơn giản là hai SIP UA kết nối
với nhau. Hình 4-3 chỉ ra cấu trúc logic của một B2BUA.
Hình 4-27 : AS ứng dụng đóng vai trò SIP B2BUA
Một yêu cầu 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 đáp ứng A và tạo
ra một yêu cầu 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 yêu
cầu BYE đến các thành viên tham gia phiên để giải phóng phiên.
2.5. AS đóng vai trò như là SIP Proxy Server
Trong cấu hình này AS đóng vai trò là Sip Proxy AS để cung cấp dịch vụ. Cấu hình
được chỉ ra như trong hình 4-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 yêu cầu INVITE 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.
Theo hình 4-6 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ứa 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êu biểu về khả năng ứng dụng như Sip Redirect server là
provision của dịch vụ chuyển tiếp cuộc gọi.
2.6. Giao diện AS với các thành phần khác trong mạng
2.6.1. Giao diện với IMS Core – ISC
Giao diện điều khiển dịch vụ IMS (IMS Service Control – ISC) là giao diện đóng
vai trò cầu nối giữa mạng lõi và các máy chủ ứng dụng (cụ thể là giữa
S-CSCF với máy chủ ứng dụng). Giao diện giữa S-CSCF và máy chủ ứng
dụng được sử dụng để cung cấp dịch vụ giá trị gia tăng trong máy chủ ứng
dụng cho thuê bao. Có hai trường hợp được đưa ra ở đây:

• S-CSCF tương tác với máy chủ ứng dụng trong mạng chủ.
• S-CSCF tương tác với máy chủ ứng dụng trong mạng nhà cung cấp thứ
ba hay mạng khách.
Giao diện ISC cần hỗ trợ đăng ký thông báo sự kiện giữa S-CSCF và máy
chủ ứng dụng để cho phép máy chư ứng dụng nhận được các thông tin về các
định danh công cộng thuê bao, trạng thái đăng ký và khả năng thuộc tính của
UE.
• 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 máy chủ ứng dụng cho quá trình xử lý tiếp theo. Khi đó
máy chủ ứng dụng có thể đóng vai trò UA đích, SIP Proxy hay SIP
Redirect Server.
• Máy chủ ứ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. Ví dụ như 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.
Giao diện ISC còn giúp cho các loại máy chủ ứng dụng khác nhau (SIP AS, OSA-
SCS, IM-SSF) đều hoạt động như một SIP AS tương tác với S-CSCF.
2.6.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à máy chủ ứng dụng tải dữ liệu về từ HSS hay
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ụ thực thi các
Script 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 cung cấp dịch vụ đăng ký và thông báo, để máy chủ ứng dụng 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 dữ liệu
này thay đổi thì HSS sẽ thông báo tới máy chủ ứng dụ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à mày chủ ứng dụng 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 máy chủ ứng dụng 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, cấp quyền 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 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ư client hoặc server.
• Diameter peer: một nút diameter mà đến nó một nút diameter có thể kết
nối và 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
ứng mà không cần sửa đổi bản tin.
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 dữ liệu cần
thiết để cấp phát các dịch vụ logic. 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 đề cập đến các loại dữ liệu khác nhau, có thể là
bất cứ thông tin nào trong số:
• Respository 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 trung định danh 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 công cộng của người dùng: REGISTERED,
NOT_REGISTERED, AUTHENTICATION, PENDING và
REGISTERED_UNREG_SERVICES.
• S-CSCF name: chứa tên và địa chỉ của S-CSCF phục vụ người dùng.
• Initial filter criteria: chứa các thông tin kích hoạt cho một dịch vụ.
Một máy chủ ứng dụng có thể chỉ cần lấy các tiêu chí lọc khởi tạo để
định tuyến bản tin SIP tới máy chủ ứ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.
• Charging information: chứa địa chỉ các chức năng tính cước.
Hình 4-30 : 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 chế độ:
data handling và subscription/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 ta truy nhập dữ liệu từ HSS, ta đang tạo ra một yêu cầu
Sh Pull Request, và khi ta chứa dữ liệu vào trong HSS thì ta đang thực
hiện một yêu cầu Sh Update.
• Subscription/notification : chế độ này chi 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 ở mức đ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).
3. Sip trong IMS

3.1. Mô hình SIP Servlet
SIP Servlet là một thành phần ứng dụng của Java cơ bản, được quản lý bởi một SIP
Servlet container và được thực thi bởi các bản tin SIP. Giống như các thành phần
Java cơ bản khác, các servlet là các lớp Java trên nền tảng độc lạp mà nó được biên
dịch thành mã máy, các mã máy này có thể được nạp tự động vào và chạy như là một
máy chủ ứng dụng SIP. Các container thi thoảng còn được gọi là các phương tiện
servlet, là các phần mở rộng của máy chủ cung cấp các chức năng servlet. Servlet
tương tác với các client này 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à một bộ phận máy chủ là một bộ phận máy chủ ứng dụng cung cấp
dịch vụ mạng thông qua các yêu cầu nhận được và hồi đáp gửi đi. Servlet containter
quyết định các ứng dụng nào để gọi và trong lệnh nào. Một servlet container vừa chứa và
vừa quản lý các servlet thông qua vòng đời của chúng. Một servlet container có thể
được dựng lên bởi một máy chủ SIP, hoặc được cài đặt như là một bộ phận bổ xung
tới SIP server thông qua các giao diện lập trình ứng dụng mở rộng riêng của server đó.
Một SIP servlet container có thể vừa được dựng lên hoặc có khả năng được cài vào
servlet, kích hoạt các máy chủ ứng dụng. Một SIP servlet container quản lý các điểm lắng
nghe (listener) của mạng và các điểm đó SIP theo chiều đến (một điểm lắng nghe
được tổ hợp bởi giao thức vận chuyển, địa chỉ IP và số hiệu cổng). Các đặc tính SIP
yêu cầu tất cả các nhân tố SIP hỗ trợ cả UDP và TCP, và có thể là TLS, SCTP, và một số
các lớp vận chuyển khác. Một servlet container có thể đặt các giới hạn bảo mật ở trên
môi trường mà một servlet thực thi. Trong môi trường J2SE 1.2 và J2EE 1.3, các giwosi
hạn này nên được đặt bằng cách sử dụng các kiến trúc cho phép định nghĩa Java2
Platform.
SIP Servlet cũng tương tự như HTTP Servlet ngoại trừ việc chúng xử lý các yêu cầu
SIP. Chúng thực hiện việc này bày cách định nghĩa các phương thức đặc tả cho mỗi
yêu cầu SIP. Ví dụ HTTP Servlet định nghĩa phương thức doPost() viết đè lên
phương thức Service() để xử lý yêu cầu Post. Trong khi đó, SIP Servlet sử dụng
giao thức doInvite() viết đè lên phương thức Service() để xử lý yêu cầu Invite. SIP
servlet và HTTP servlets có thể được đóng gói với nhau với tài nguyên khác nhau như

các thư viện và các lớp khác nhau, nội dung tĩnh (tập tin âm thanh, tệp hình ảnh, video,
…) và một vài tập tin cấu hình để tạo ra một ứng dụng hội tụ.
3.2. Các khái niệm chính của SIP Servlet API
Khái niệm chính của SIP Servlet tương tự như HTTP Servlet.Các phần dưới đây sẽ mô tả
phần chính của một vài khái niệm.
3.2.1. Mục đích của SIP Servlet API
Một số thuộc tính quan trọng của API bao gồm:
• SIP Signaling: chấp nhận cho các ứng dụng thực hiện hoàn thành
một chuỗi các hành động của tín hiệu SIP, bao gồm hỗ trợ các nhiệm vụ
như User Agent Client (UAC), User Agent Server (UAS) và
proxy. • Tính đơn giản: các Container xử lý các việc phức tạp không
cần thiết như quản lý các điểm lắng nghe mạng, truyền lại, Cseq,
Call-ID thông qua các trường điều khiển, định tuyến,…
• Các ứng dụng hội tụ: các Container có khả năng hỗ trợ cho các ứng
dụng hội tụ, đó là các ứng dụng có thể chia ra thành nhiều các giao
thức và các loại media khác nhau, ví dụ như web, telephony và
presence.
• 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
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ể dùng cho một vài các ứng dụng thực thi
trên các yêu cầu hoặc hồi đáp theo chiều đến hoặc đi. Mỗi một ứng
dụng có một bộ các quy tắc của nó và thực thi một cách độc lập với các
ứng dụng khác một cách rành mạch và tạo thành theo thứ tự.
• Carrier grade (cấp độ carrier): các servlet lưu trữ dữ liệu ứng dụng
trong các container quản lý các phiên đối tượng. Việc triển khai có thể
tiếp tục tái tạo dữ liệu này để đạt được hiệu quả cao.
3.2.2. Vòng đời của SIP Servlet
Vòng đời của một servlet được bắt đầu tính từ khi nó được nạp vào trong 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.
• Bộ chứa gọi phương thức init(). Phương thức khởi tạo servlet và phải
được gọi trước khi servlet có thể phục vụ bất kỳ yêu cầu nào. Trong toàn
bộ vòng đời của một servlet, phương thức init() chỉ được gọi một lần.
• Sau quá trình khởi tạo, servlet có thể phục vụ các yêu cầu từ phía
client. Mỗi một yêu cầu được phục vụ 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 làm và gửi nó đi với một