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. (adsbygoogle = window.adsbygoogle || []).push({});
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 (adsbygoogle = window.adsbygoogle || []).push({});
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 bằng máy di động SIP vì anh đang đi trên phố, khi đến văn phòng Bob muốn chuyển sang liên lạc bằng máy cố định SIP, Bob sẽ gửi yêu cầu REFER đến UE Alice. Bob cũng có thể dùng cùng cơ chế REFER đó để chuyển cuộc gọi của anh với Alice đến một người khác (ông chủ của Bob chẳng hạn), trong trường hợp đó, Bob cần chắc chắn rằng Alice có thể liên lạc được với ông ta. Vì thế để đảm bảo điều này Alice cần gửi lại Bob một phản hồi NOTIFY (hình 3.25). Bob cũng có thể dùng REFER để yêu cầu UE của Alice liên lạc với một non-SIP URI. Trong trường hợp đó nếu Bob muốn Alice xem web cá nhân mới của anh ta, anh sẽ gửi một yêu cầu REFER đến UE Alice yêu cầu nó liên lạc đến HTTP URI của trang web cá nhân đó.
3.5 CẤU TRÚC MẠNG DỊCH VỤ TRONG POC IMS. ( POC: Push to talk over the Cellular service-Dịch vụ đàm thoại trên Cell) the Cellular service-Dịch vụ đàm thoại trên Cell)
3.5.1 Khái Quát. Remote PoC Remote PoC Network XDMC PoC Client User Equipment SIP/IP Core XDM-1 PoC-1 Access Network XDM-3 PoC-3 PoC-2 PoC Server XDM-2 PoC-6 PoC XDMS PoC-8 PoC-4 PoC-5 PoC-7 Aggeriation Proxy XDM-4 Shared XDMS Hình 3.26. Cấu trúc PoC
UE chứa hai yếu tố logic: PoC Client và XDMC (XML Document Management Client). PoC Client dùng SIP để thông tin với mạng lõi SIP/IP qua giao diện POC-1, và RTP và TBCP (Talk Burst Control Protocol) để thông tin với PoC Server qua giao diện POC-3. TBCP là giao thức điều khiển thấp nhất dựa trên RTCP (Real Time Transport Protocol ) được dùng để báo hiệu cho user nào được cho phép nói khi đó.
XDMC dùng SIP để thông tin với lõi SIP/IP qua giao diện XDM-1 và XCAP để thông tin với Aggregation Proxy qua giao diện XDM-3. Giao diện XDM-3 được dùng để thực hiện sự quản lý tài liệu (ví dụ, thiết đặt một danh sách URI) và giao diện XDM-2 được dùng để đăng ký cho những thay đổi trong các tài liệu được lưu trữ trong mạng.
Aggregation Proxy (khối Proxy) hoạt động như một điểm đơn cho XDMC liên lạc với mạng. Khối Proxy thực hiện nhận thực user và định tuyến các bản tin XCAP từ XDMC (nhận được qua giao diện XDM-3) đến Server thích hợp (PoC XDMS hoặc XDMS chia sẻ). Khối Proxy dùng XCAP để thông tin với PoC XDMS qua giao diện POC-7 và với XDMS chia sẻ qua giao diện XDM-4.
PoC XDMS quản lý các tài liệu đặc trưng cho PoC (ví dụ như các thành viên của một nhóm PoC). Theo cách khác, XDMS chia sẻ sẽ quản lý các tài liệu cần thiết cho PoC và có thể được chia sẻ với các service khác (như các tài liệu liên quan đến sự hiển thị).
PoC XDMS dùng XCAP để thông tin với Khối Proxy qua giao diện POC-7 và với PoC server qua giao diện POC-8. PoC XDMS dùng SIP để thông tin với lõi SIP/IP qua giao diện POC-6.
XDMS chia sẻ dùng XCAP để thông tin vối Khối Proxy qua giao diện XDM-4 và PoC Server qua giao diện POC-5. XDMS chia sẻ dùng SIP để thông tin với lõi SIP/IP qua giao diện XDM-2. Khi các tài liệu được quản lý bởi XDMS chia sẻ thì nó có thể được chia sẻ với các dịch vụ khác, và XDMS chia sẻ sẽ thêm các giao diện đối với các dịch vụ đó. Ví dụ, giao diện giữa XDMS chia sẻ và Presence Server.
PoC Server dùng SIP để thông tin với lõi SIP/IP qua giao diện POC-2. Nó dùng RTP và TBCP để thông tin với PoC Client qua giao diện POC-3 và với các mạng PoC qua giao diện POC-4. Thêm nữa, PoC Server dùng XCAP để thông tin với PoC XDMS qua giao diện