User Alice có thể đảm nhận làm một watcher. Khi Alice bắt đầu dùng ứng dụng hiển thị, cô sẽ đăng ký các thông tin hiển thị về các thực trạng hiện tại của cô.
Mặc dù IMS cho phép Alice đăng ký các hiển thị mà cô dùng riêng, nhưng trong hầu hết các trường hợp, watcher luôn đăng ký toàn bộ danh sách hiển thị của họ từ RLS của mạng thường trú.
Hình 3.8 là một quá trình đăng ký dịch vụ hiển thị. Ứng dụng Watcher trong UE của Alice sẽ gửi một yêu cầu SUBSCRIBE đến danh sách của cô (có địa chỉ: sip:alice- list<9home.net). Yêu cầu SUBSCRIBE (1) chứa trường mào đầu Event có giá trịdanh sách sự kiện (eventlist) để chỉ ra rằng đăng ký được địa chỉ đến một danh sách chứ không phải là địa chỉ đến một sự hiển thị riêng nào. S-CSCF nhận được yêu cầu (2), nó sẽ đánh giá với tiêu chuẩn bộ lọc khởi tạo. Một trong những tiêu chuẩn này chỉ ra rằng yêu cầu (3) nên được gửi
tiếp đến một Application Server thực hiện RLS. Sau khi RLS thẩm tra nhận dạng của thuê bao và trao quyền thuê bao thì RLS gửi phản hồi 200 (OK) (4). RLS cũng gửi một yêu cầu NOTIFY (7) (các phản hồi và yêu cầu này chưa chứa bất cứ thông tin hiển thị nào tại thời điểm hiện tại). RLS thuê dùng tất cả các hiển thị đã được lên danh sách trong resource list. Khi có đủ thông tin cần thiết, RLS sẽ tạo ra một yêu cầu NOTIFY khác (13) chứa một tài liệu hiển thị có toàn bộ thông tin hiển thị mà RLS đã nhận được từ PUA.
Hình 3.8. Đăng ký Watcher cho danh sách hiển thị [17]
Hình 3.9 chỉ ra RLS thuê dùng một sự hiển thị chứa trong resource list. RLS gửi một yêu cầu SUBSCRIBE (1) đến địa chỉ của sự hiển thị trong danh sách. Yêu cầu chứa một mào đầu Event có giá trị presence. Yêu cầu được gửi forward tới I-CSCF trong mạng có PA (qua S-CSCF trong mạng thường trú RLS). I-CSCF sẽ truy vấn HSS để tìm ra S-CSCF đã cấp cho sự hiển thị, rồi forward yêu cầu SUBSCRIBE (5) đến S-CSCF đó. S-CSCF đó sẽ đánh giá tiêu chuẩn lọc ban đầu để tìm ra PA, rồi S-CSCF cần forward yêu cầu này đến PA đó (6). Sau khi gửi phản hồi 200 (OK) (7), PA sẽ gửi yêu cầu NOTIFY (11) chứa thông tin hiển thị.
Hình 3.9. RLS đăng ký hiển thị [15] 3.2.3 Sự công bố hiển thị [18]
Khi ứng dụng hiển thị IMS bắt đầu, nó sẽ công bố thông tin hiển thị của thực thể hiển thị hiện tại. Đầu cuối IMS gửi yêu cầu PUBLISH (1) chứa mào đầu Event có giá trị presence. S-CSCF nhận được yêu cầu (2) và đánh giá sự hiển thị với tiêu chuẩn lọc khởi tạo. Tiêu chuẩn lọc khởi tạo sẽ chỉ ra yêu cầu này nên được forward đến PA lưu trữ thông tin hiển thị của thực thể hiển thị. PA sẽ trao quyền publication và gửi một phản hồi 200 (OK) (4).
3.3 DỊCH VỤ NHẮN TIN
Có hai chế độ vận hành của dịch vụ nhắn tin tức thời (pager-mode và session-base) phụ thuộc vào đó là các tin nhắn tức thời đơn hay nó là một phần của phiên.
Tin nhắn tức thời pager-mode được gửi dưới dạng các bản tin riêng biệt, không liên quan đến những bản tin trước và sau nó. Tin nhắn tức thời loại này tương tự với SMS (Short Message Service) trong mạng Cellular.
Tin nhắn tức thời session-base được gửi trong một phiên đang tồn tại, được thiết lập cùng với một yêu cầu INVITE (chế độ này giống như dịch vụ chat mà ta đã biết đối với mạng Internet).
3.3.1 Nhắn tin tức thời Pager-mode trong IMS
Dịch vụ nhắn tin tức thời page-mode được giới thiệu lần đầu ở Release 5 của 3GPP. 3GPP TS 23.228 [11] đã chứa các yêu cầu cho các dịnh vụ ứng dụng và các S-CSCF có thể gửi thông tin dạng văn bản tới đầu cuối IMS. Các giới thiệu của 3GPP TS 23.218 [16] có hỗ trợ cho sự mỏ rộng phương thức MESSAGE. Các đầu cuối IMS được uỷ quyền để triển khai phương thức MESSAGE (RFC 3428 ) và để cho phép sự triển khai đó được là một đặc tính tuỳ chọn đối với các S-CSCF và các AS. Tất nhiên các tin nhắn tức thời pager-mode sẽ bị ràng buộc (ví dụ về kích thước bản tin).
Mục đích chính của tin nhắn tức thời pager-mode là cho phép S-CSCF hoặc AS gửi các bản tin khẩn ngắn đến đầu cuối IMS. Khi phương thức MESSAGE được triển khai trên các đầu cuối IMS, các user có thể gửi được những tin nhắn tức thời pager-mode đến những user khác. Hình 3.11 sau là một ví dụ cho tin nhắn tức thời pager-mode.
IMS Terminal#1 P-CSCF S-CSCF I-CSCF HSS S-CSCF P-CSCF IMS Terminal#2 Originating Visited Network Originating
Home Network Terminating Home Network
Terminating Visited Network (1) MESSAGE (2) MESSAGE (3) MESSAGE (6) MESSAGE (7) MESSAGE (8) MESSAGE Evaluation of initial filter criteria (4) Diameter LIR (5) Diameter LIA Evaluation of initial filter criteria (9) 200 OK Alert user (10) 200 OK (11) 200 OK (12) 200 OK (13) 200 OK (14) 200 OK
Hình 3.11. Nhắn tin tức thời pager-mode trong IMS [18]
Hình 3.12 làm một ví dụ cho dịch vụ cung cấp bằng phương thức MESSAGE. Trong đó AS đảm nhận vai trò người điều khiển của hệ thống voicemail. AS sẽ chú ý để biết được khi nào user đăng nhập thành công vào IMS, vì thế AS có thể báo cho user biết rằng mạng có
các voicemail chờ được đem về. Dịch vụ được triển khai: user đăng ký với IMS như thường lệ, (1)-(20) trong hình 5.6; Khi sự đăng ký hoàn thành, S-CSCF sẽ đánh gia tiêu chuẩn lọc khởi tạo; Một trong các tiêu chuẩn lọc khởi tao sẽ chỉ cho S-CSCF nên thực hiện đăng ký bên thứ 3 (third-party registration)với một AS riêng; Sau đó S-CSCF gửi yêu cầu third-party REGISTER (21) đến AS đã được chỉ định. Mục đích của yêu cầu REGISTER third-party này không phải để đăng ký user với AS, mà là để chỉ cho AS rằng user vừa mới đăng kí đến S- CSCF; Nhận được yêu cầu REGISTER này (21), AS sẽ tạo ra một yêu cầu MESSAGE (23) chứa vài thông tin văn bản, cũng có thể là link đến một địa chỉ website nắm giữ bản sao của những tin nắm đang chờ được lấy về (ví dụ những tin nhắn offline) hay các thông tin thích hợp khác mà dịch vụ hộ trợ; Yêu cầu MESSAGE được gửi forward qua S-CSCF và P-CSCF như bất kỳ bản tin SIP nào khác.
Hình 3.12. Ví dụ của một dịch vụ cung cấp các tin nhắn tức thời pager-mode[18] 3.3.2 Nhắn tin tức thời Session-base trong IMS
Dịch vụ nhắn tin tức thời session-base được giới thiệu trọng Release 6 của 3GPP. Chỉ tiêu kỹ thuật của giao thức đã được chi tiết hoá mô tả trong 3GPP TS 24.247 [10] (Messaging
service using the IP Multimedia Core network subsystem Stage 3-Internet). Nhắn tin tức thời
session-base
Giao thức MSRP (Message Session Relay Protocol) được dùng để truyền tải các bản tin khẩn Session-base (*). Trong IMS, MSRP được triển khai trên các đầu cuối IMS. MRFP
cũng có thể triển khai MSRP. Có hai sơ đồ khác nhau cho việc thiết lập một phiên của các tin nhắn tức thời. Sơ đồ đầu tiên chúng ta mô tả ở hình 3.13:
IMS Terminal#1 P-CSCF S-CSCF I-CSCF HSS S-CSCF P-CSCF IMS Terminal#2 Originating Visited Network Originating
Home Network Terminating Home Network
Terminating Visited Network (1) INVITE (3) INVITE (5) MESSAGE (9) INVITE (11) INVITE (13) INVITE Evaluation of initial filter criteria (7) Diameter LIR (8) Diameter LIA Evaluation of initial filter criteria Alert user (2) 100 Trying (4) 100 Trying (6) 100 Trying (10) 100 Trying (12) 100 Trying (14) 100 Trying (15) MSRP: VISIT (16) MSRP: 200 OK (17) 180 Ringing (18) 180 Ringing (19) 180 Ringing (20) 180 Ringing (21) 180 Ringing (22) 180 Ringing (29) ACK (30) ACK (31) ACK Accept Session (23) 200 OK (24) 200 OK (25) 200 OK (26) 200 OK (27) 200 OK (28) 200 OK (32) ACK (33) ACK (34) MSRP: SEND (35) MSRP: 200 OK (36) MSRP: SEND (37) MSRP: 200 OK
Hình 3.13. Các tin nhắn tức thời Session-base: phiên MSRP end-to-end [18]
Trong hình 3.14, một đầu cuối IMS thiết lập một phiên đến điểm cuối khác. Các bản tin SIP sẽ đi qua các nút IMS (các P-CSCF, các S-CSCF, hoặc có thể qua các AS,…). Sau đó MSRP được gửi end-to-end. Khác với sự thiết lập phiên cơ bản là ở đây không có các phản hồi 183, yêu cầu PRACK hoặc yêu cầu UPDATE vì REGISTER ở MSRP chỉ chứa một luồng truyền thông được công khai trong SDP.
Hình 3.14. Chat Server - hội nghi session-base multi-part [13]
Trong sơ đồ thứ hai, MRFC và MRFP là những trung gian trong mạng, sẽ tạo điều kiện cho việc tạo các sự kiện tính cước theo kích thước của bản tin hoặc theo bất kỳ nội dung thêm nào trong các bản tin MSRP SEND. Lý do khác là MRF đang đảm nhận làm một đơn vị hội nghị nhiều bên cho các tin nhắn tức thời (ví dụ chat room). Hình 3.14 chỉ ra ví dụ của một hội nghị đa bên đó. Ở đây chúng ta cho rằng các user tham gia vào hội nghị đều thuộc cùng một mạng, mặc dù họ có thể được cấp các S-CSCF và P-CSCF khác nhau. Trong hình đó, đầu tiên user gửi một yêu cầu INVITE (1), yêu cầu đó sẽ đi qua P-CSCF và S-CSCF đã cấp cho user đó. S-CSCF sẽ gửi forward yêu cầu INVITE (5) đến MRFC. MRFC điều khiển MRFP nhờ giao thức H.248, sẽ tạo một sự kết thúc mới cho user. MRFC sẽ khởi tạo một kết nối TCP đến đầu cuối IMS và gửi một yêu cầu MSRP VISIT (8) đến đó. Đầu cuối IMS nhận được yêu cầu MSRP VISTIT sẽ phản hồi bằng một bản tin MSRP 200 (OK) (9). H.248 thực
hiện (10) để chỉ cho MRFC rằng kết nối MSRP mới đã được thiết lập, sau đó MRFC gửi phản hồi 200 (OK) (11) để hoàn thành việc thiết lập phiên.
Sau đó, một user thứ hai tham gia vào hội nghị và thiết lập phiên khác với MRFC. Tại mọi thời điểm, bất kỳ user nào cũng có thể gửi tin nhắn tức thời truyền bằng yêu cầu MSRP SEND: ví dụ khi user thứ hai gửi một yêu cầu MSRP SEND (33), MRFP sẽ gửi bản copy của yêu cầu đó (35) đến mọi người tham dự hội nghị đó.
(*) MSRP là giao thức trên nền văn bản, nó chạy trên giao thức truyền tải như TCP,
SCTP và TLS trên TCP. MSRP không dùng trên UDP và bất cứ giao thức truyền tải nào khác. Một đặc tính khác của MSRP là nó có thể chạy trên mặt bằng media. Vì thế bản tin MSRP không truyền qua các SIP proxy. Đó là một lợi thế, vì khi ấy các SIP proxy sẽ không phải bận tâm đến các tin nhắn tức thời có kích thước lớn. MSRP hỗ trợ cho các tin nhắn tức thời truyền qua không, một hoặc hai MSRP relay (là nút đặc biệt truyền các bản tin MSRP giữa hai nút MSRP khác nhau, MSRP relay nằm ở mặt bằng media). Các MSRP relay thực hiện vai trò quan trọng khi một trong các điểm cuối nằm sau NAT (Network Address Translator). Chúng hữu ích cho các nhà quản lý mạng khi cấu hình tường lửa ngang hàng (firewall traversal).
MSRP là giao thức trên nền text, gồm các bản tin yêu cầu và bản tin phản hồi. Tuy nhiên không phải mọi yêu cầu MSRP đều được trả lời bằng một đáp ứng MSRP như SIP. Có ba loại phương thức được định nghĩa trong MSRP:
SEND: gửi tin khẩn từ điểm cuối tới một điểm cuối.
REPORT: điểm cuối hoặc relay cung cấp các thông báo phân phát tin nhắn.
AUTH: dùng bởi các điểm cuối để nhận thực các relay.
Yêu cầu MSRP SEND mang thân được mã hoá theo luật MINE.
Hình 3.15 (để cho đơn giản, các proxy đã bị ẩn đi) chỉ ra một phiên nhắn tin MSRP được thiết lập. Điểm cuối gốc tạo phiên nhắn tin Alice gửi một yêu cầu SIP INVITE (1) chứa SDP đề nghị loại phương tiện tin nhắn hỗ trợ MSRP. Sau khi nhận được yêu cầu, Bob sẽ gửi phản hồi 200 OK (2) (các địa chỉ MSRP URI được nằm ở dòng a=). Sau đó Alice sẽ trả lời bằng yêu cầu ACK (3)…quá trình tiếp tục như hình 3.15, nội dung các bản tin được trình bầy như các hình 3.16, 3.17, 3.18 và 3.19.
INVITE sip:Bob.Brown@example.org SIP/2.0
Via: SIP/2.0/UDP wsl.example.com:5060;branch=z9hG4bk74gh5 Max-Forwards: 70
From: Alice <sip:Alice.Smith@example.com>;tag=hx34576s1 To: Bob <sip:Bob.Brown@example.orh
Call-ID: 2098adkj20 Cseq: 22 INVITE Contact: <sip:alice@192.0.100.2> Content-Type: application/sdp Content-Length: 220 v=0
o=alice 2890844526 2890844526 IN IP4 wsl.example.com s=-
c=IN IP4 wsl.example.com t=0 0
m=message 8231 msrp/tcp *
a=accept-type:message/cpim text/plain text/html a=path:msrp://wsl.example.com:8231/9s9cpl:tcp
Hình 3.16 Yêu cầu INVITE (1) SIP/2.0 200 OK
Via: SIP/2.0/UDP wsl.example.com:5060;branch=z9Gbk74gh5 From: Alice <sip:Alice.Smith@example.com>;tag=hx34576sl To: Bob <sip:Bob.Brown@example.org>;tag=ba03s
Call-ID: 63287762982201885110192.0.100.2 Cseq: 1 INVITE Contact: <sip:bob@bob.example.org> Content-Type: application/sdp Content-Length: 215 v=0
o=bob 2890844528 289084458 IN IP4 bob.example.org s=-
c=IN IP4 bob.example.org t=0 0
m=message 7283 msrp/tcp *
a=accept-type:message/cpim text/plain text/html a=path:msrp://bob.example.org:7283/d9s9a;tcp
MSRP 230cmqj SEND To-Path: msrp://bob.example.org:7283/d9s9a;tcp From-Path: msrp://wsl.example.com:8231/9s9cpl;tcp Message-ID: 309203 Byte-Range: 1-20/20 Content-Type: text/plain This is Alice typing ---230cmqj$
Hình 3.18. Yêu cầu MSRP SEND chứa tin nhắn (5) MSRP 230cmqj 200 OK To-Path: msrq://wsl.example.com:8231/9s9cpl;tcp From-Path: msrp://bob.example.org:7283/d9s9a;tcp Message-ID: 309203 Byte-Range: 1-20/20 ---230cmqj$ Hình 3.19. Phản hồi MSRP 200 (6)
MSRP relay - để truyền các gói MSRP giữa các điểm cuối thì cần thực thể này, nó nằm ở mặt bằng media. Trước khi dùng MSRP relay để truyền các gói MSRP thì user cần tạo kết nối TLS đến relay, nhận thực (bằng cách gửi AUTH MSRP), nếu nhận thực thành công, relay sẽ cung cấp cho điểm cuối một MSRP URI để user có thể dùng cho các phiên MSRP.
Hình 3.20. Sự nhận thực ở MSRP relay
Chú ý: AUTH thứ hai (4) chứa tên user và password cho khu vựct này (tên khu vực relay được chứa trong 401 (3)). Yêu cầu SIP INVITE (6) sẽ chứa cả MSRP URI của điểm cuối và của relay.
Hình 3.21 sẽ mô tả sơ lược về quá trình nhắn tin, nhìn trên mặt bằng media đối với các MSRP relay.
Hình 3.21. Sự thiết lập phiên end-to-end với MSRP relay [19] 3.4 Dịch vụ Push to talk
Push to talk (Dịch vụ thoại IP thời gian thực )hay còn gọi là dịch vụ cho phép thông tin thoại theo phương thức truyền đơn công điểm - điểm hoặc điểm - đa điểm. Các phiên Push to talk thông tin theo phương thức: một bên nói, bên kia hoặc các bên nghe.
Dịch vụ Push to talk là dịch vụ dựa trên truyền multi-unicast (điểm A tới nhóm B, C; nhưng hướng ngược lại thì là unicast). Bên gửi sẽ gửi một lưu lượng dữ liệu gói đến máy chủ ứng dụng dành cho dịch vụ này, máy chủ sẽ thực hiện nhân bản dữ liệu rồi gửi đến các máy khách (bên nghe trong nhóm).
3.4.1 URI-list Services (Danh sách dịch vụ URI)
User có thể gửi một tin nhắn đến một vài người bạn để báo cho họ về việc gặp mặt ở rạp phim. Như vậy tất cả các bản tin sẽ có cùng nội dung (ví dụ: ―let’s meet at seven‖). URI- list service được thiết kế cho mục đích gửi một nội dung đến nhiều địa chỉ.
Các server cung cấp URI-list service sẽ thực hiện phiên tương tự nhau đối với các thành viên (được nhận dạng bởi các URI đó) của danh sách đã được UE cung cấp. User sẽ gửi đến server một yêu cầu MESSAGE với hai nội dung thân: nội dung thứ nhất chính là nội dung của tin nhắn tức thời đó (―Let’s meet at seven‖), nội dung thứ hai là danh sách các URI dưới dạng mã XML. Khi nhận được yêu cầu MESSAGE, server sẽ gửi yêu cầu MESSAGE đến các URI có trong danh sách, như hình 3.22.
Hình 3.22. URI-list Service và yêu cầu MESSAGE
Hình 3.23. chỉ ra cách bản tin cần chuyển nếu Alice (user trong ví dụ này) không dùng URI-list server. Khi ấy mạng truy nhập của Alice sẽ có 6 bản tin thay vì hai bản tin như hình 5.22.
Hình 3.23. Các MESSAGE không dùng URI-list Service
Ngoài yêu cầuMESSAGE, URI-list service còn được dùng trong yêu cầu INVITE và SUBSCRIBE. INVITE URI-list service có thể được dùng để thiết lập một hội nghị nhiều người tham dự, SUBSCRIPBE URI-list service có thể được dùng để đăng ký thông tin hiển thị cho một vài user.
3.4.2 Multiple REFER
URI-list service dùng để thiết lập các phiên PoC nhiều người tham gia và để gửi các tin nhắn đến nhiều người tham gia PoC. Multiple-REFER được dùng để mời các user vào một phiên PoC.
Hình 3.24. REFER
Ngoài ra phương thức REFER được dùng để yêu cầu một user liên kết với một tài nguyên. REFER thường được dùng để chuyển tiếp cuộc gọi. Ví dụ Bob đang gọi cho Alice