PoC Server trong một phiên có thể thực hiện hai vai trò: Điều khiển chức năng PoC hoặc tham gia vào chức năng PoC. PoC Server trong phiên PoC sẽ thực hiện một hoặc cả hai vai trò. Tuy nhiên, chỉ một PoC Server trong một phiên sẽ thực hiện chức năng điều khiển
PoC Function. Các server PoC còn lại sẽ thực hiện chức năng tham gia POC (Participating PoC).
PoC Server thực hiện chức năng điều khiển PoC thường gọi là máy chủ điều khiển (Controlling PoC Server). Tương tự, PoC Server thực hiện chức năng Participating PoC thường được gọi là Participation PoC Server.
Hình 3.27 đã đơn giản hoá chỉ ra phiên PoC với một server điều khiển PoC và bốn server tham gia PoC. Mỗi PoC server trong một miền khác nhau.
Participating PoC Server Participating PoC Server Participating PoC Server Participating PoC Server Controlling PoC Server
SIP + media + floor control traffic
Hình 3.27. Phiên PoC và Server PoC điều khiển trung tâm
Controlling PoC Server cung cấp việc vận hành phiên PoC trung tâm, bao gồm trộn các phương tiện (media mixing), điều khiển tập trung ngang hàng (centralized floor), và chính sách cho sự tham gia trong các phiên nhóm. Participating PoC server chuyển báo hiệu SIP giữa Client và Controlling PoC Server, đồng thời chuyển các bản tin điều khiển floor và điều khiển phương tiện truyền thông giữa lưu lượng truyền thông và lưu lượng điều khiển floor một cách trực tiếp với controlling PoC Server.
Hình 3.28 chỉ ra một phiên PoC khác mà controlling PoC Server cũng thực hiện chức năng participating Poc Server.
Participating PoC Server Participating PoC Server Participating PoC Server Controlling and Participating PoC Server
SIP + media + floor control traffic
Hình 3.28. Server PoC điều khiển và Server tham gia PoC 3.5.4 Các loại phiên PoC
PoC định nghĩa các loại phiên hay các chế độ thông tin sau:
One-to-one: một phiên PoC giữa hai user;
Ad-hoc PoC Group: user chọn tập các user trong kiểu mạng (ad-hoc fashion) (có được nhờ sách địa chỉ của đầu cuối) và mời tất cả họ tham gia vào phiên PoC nhiều người.
Pre-arranged PoC Group: giống như ad-hoc PoC group, nhóm POC được sắp xếp trước (pre-arranged PoC group) cũng chứa một phiên PoC đa bên. Tuy nhiên, các user tham gia vào phiên được lựa chọn trước khi thiết lập, không như ad-hoc thực hiện. Vì thế pre-arranged PoC group chứa tập các user đã được định nghĩa trước.
Chat PoC Group: cũng là các phiên PoC đa bên. Tuy nhiên, khi một user tham gia vào nhóm chat, thì không có lời mời nào được gửi đến các user khác. Ngược lại, khi user tham gia vào nhóm PoC pre-arranged, tất cả các user thuộc nhóm sẽ được mời tham gia phiên PoC này.
Những loại phiên PoC này được phân loại thành hai dạng phiên PoC: một tới một (one-to-one) và một tới nhiều người (one-to-many). Các phiên PoC one-to-many bao gồm ad- hoc, pre-arranged, và các nhóm PoC chat. Một số nhóm PoC pre-arranged có thể dùng chính sách trộn truyền thông đặc biệt, ở đó một user có thể nói với toàn bộ nhóm và lắng nghe các trả lời từ mỗi user riêng. Tuy nhiên, các user còn lại không thể nói hoặc nghe các user khác (ngoài user kia). Khi ấy phiên PoC sẽ là phiên one-to-many-to-one. Ví dụ, một người điều hành taxi cần cho các lái xe biết về các khách hàng đang đợi taxi, nhưng các lái xe đó chỉ trả lời cho người điều hành đó, không có lái xe nào khác nghe được các trả lời đó ngoài nhà khai thác và lái xe đó.
PoC định nghĩa hai loại thiết lập phiên: dùng báo hiệu on-demand và dùng phiên pre- established (phiên đã thiết lập trước đó).
Các phiên PoC one-to-one
Trong các phiên one-to-one, controlling PoC server là server PoC của phía user mời. PoC Server này vừa thực hiện làm participating PoC Server của user chủ gọi, vừa là controlling PoC Server cho phiên.
Hình 3.29 chỉ ra việc thiết lập phiên PoC one-to-one. Đầu cuối PoC tạo một yêu cầu INVITE (1) địa chỉ đến bị gọi và có mô tả phiên SDP trong thân của nó. INVITE (1) cũng mang mào đầu Accept-Contact với nhãn +g.poc.talkburst trong nó. Nhận được INVITE, S- CSCF của chủ gọi đánh giá tiêu chuẩn lọc khởi tạo cho user. Tuỳ theo tiêu chuẩn lọc, yêu cầu INVITE với nhãn đó sẽ được định tuyến đến PoC Server trong miền. Khi PoC Server nhận được INVITE (3), nó sẽ gửi forward đến miền thường trú của bị gọi. S-CSCF của bị gọi nhận được INVITE (5) và đánh giá tiêu chuẩn lọc khởi tạo cho user đầu cuối. Tuỳ theo tiêu chuẩn lọc, yêu cầu INVITE với nhãn đó sẽ được định tuyến đến PoC server của miền bị gọi. Khi PoC Server đó nhận được INVITE (7), nó tạo ra một INVITE mới (9) sẽ được định tuyến bởi lõi SIP/IP đến user đầu cuối (bị gọi).
Hình 3.29. Sự thiết lập phiên PoC one-to-one
Nhóm PoC Ad-hoc
Trong phiên PoC nhóm ah-hoc, controlling PoC server là PoC server của chủ gọi. PoC Server này vừa là participating PoC server của chủ gọi, vừa là controlling PoC server của phiên.
Hình 3.30 chỉ ra sự thiết lập phiên PoC ad-hoc. Các luồng bản tin tương tự như với PoC one-to-one. Điểm khác biệt quan trọng là INVITE (1) được tạo bởi đầu cuối chủ gọi được địa chỉ đến PoC server thường trú của nó và INVITE chứa hai nội dung trong thân (hai thân): một mô tả phiên SDP và một danh sách URI. Danh sách URI chứa địa chỉ tất cả các bị gọi. Nhận được INVITE (1), controlling PoC server tạo một yêu cầu INVITE đến mỗi địa chỉ URI trong danh sách URI. Những INVITE này chứa một nội dung trong thân là mô tả phiên SDP. Các participating PoC server định tuyến những yêu cầu INVITE này đến các đầu cuối của kết cuối.
Hình 3.30. Sự thiết lập phiên nhóm PoC ah-hoc Nhóm PoC pre-arranged.
Trong các phiên nhóm PoC pre-arranged, controlling PoC server là server PoC tổ chức pre-arranged PoC group.
Hình 3.31 chỉ ra sự thiết lập phiên pre-arranged PoC group. Server PoC participating của chủ gọi không là server controlling PoC vì pre-arranged PoC group được thuê bởi miền khác. INVITE (1) được tạo bởi đầu cuối chủ gọi không mang danh sách URI vì các thành viên của pre-arranged PoC group đã được thiết đặt ở trong mạng từ trước. Request-URI của INVITE (1) nhận dạng pre-arranged PoC group tại controlling PoC server. Server PoC của chủ gọi thực hiện như một participating PoC server, vì thế nó chuyển yêu cầu INVITE (3) đến controlling PoC server. Khi nhận được INVITE (3), controlling PoC server sẽ mời các thành viên của pre-arranged PoC group.
Nhóm PoC Chat.
Hình 3.32 chỉ ra sự thiết lập phiên PoC chat. Participating PoC server của chủ gọi không đảm nhận là controlling PoC server vì chat PoC group được thuê bởi miền mạng khác. INVITE (1) được tạo ra bởi đầu cuối chủ gọi sẽ không mang danh sách URI vì tham gia vào
một chat room không cần trigger (khởi hoạt) bất cứ lời mời nào đến các user khác. Request- URI của INVITE (1) nhận dạng chat PoC group tại controlling PoC server. PoC server của chủ gọi hoạt động như một participating PoC server nên nó chuyển INVITE (3) đến controlling PoC server. Khi nhận được INVITE (3), controlling PoC server trả lại đáp ứng 200 (OK) (5) chấp nhận user tham gia phiên chat PoC group.
Hình 3.32. Sự thiết lập phiên nhóm PoC Chat Thêm user vào một phiên PoC.
Một user mới có thể được thêm vào phiên PoC theo hai cách: user mới sẽ gửi một yêu cầu INVITE đến URI của phiên hoặc controlling PoC server gửi một INVITE đến user mới.
Những người tham gia phiên PoC có thể giúp controlling PoC server gửi yêu cầu INVITE đó đến user mới bằng cách gửi yêu cầu REFER đến controlling PoC server. Hình 3.33 chỉ ra cách một controlling PoC server nhận được multiple REFER và mời hai user mới tham gia vào phiên.
Các loại phiên khác nhau sẽ có các chính sách trao quyền khác nhau đối với những user nào có thể được thêm vào phiên PoC. Trong các phiên one-to-one và phiên ad-hoc, các user mới có thể được thêm vào phiên khi chúng được mời bởi một người đã tham gia phiên. Một user bất kỳ cũng có thể tham gia phiên bằng cách gửi yêu cầu INVITE đến URI của phiên PoC đó và nhận được sự chấp thuận. Những user muốn rời khỏi phiên, sau đó lại có thể nhập vào phiên đó thì cần được sự chấp thuận của controlling PoC server sau khi đã gửi yêu cầu INVITE.
Hình 3.33. Thêm các user mới vào một phiên PoC Sự quảng bá nhóm.
Thực tế, để tham gia vào phiên PoC pre-arranged hay chat thì user cần biết URI của nhóm PoC đó. User có thể đạt được URI nhận dạng các phiên nhóm PoC theo nhiều cách, như bằng email, cuộc thoại, hay từ một tờ báo…Ngoài ra, PoC quảng bá nhóm, cho phép user có thể lựa chọn thay đổi phiên nhờ chọn URI khác. Quảng bá nhóm là một yêu cầu MESSAGE mang thân XML chứa URI của phiên nhóm PoC và các thông tin về phiên (như chủ đề phiên chẳng hạn). Yêu cầu MESSAGE còn mang nhãn a+g.poc.group trong mào đầu Accept-Contact.
Các chế độ trả lời.
PoC định nghĩa hai chế độ trả lời: tự động hoặc thủ công. Chế độ trả lời thủ công là chế độ dùng trong các máy điện thoại truyền thống. Khi đầu cuối nhận được một lời mời tham gia phiên PoC, đầu cuối sẽ thông báo cho user (thường bằng hồi chuông). Khi đó, user sẽ quyết định có chấp nhận hay từ chối lời mời đó.
Hình 3.34. Chế độ trả lời thủ công
Ở chế độ trả lời tự động, user thiết đặt cho đầu cuối chấp nhận các phiên PoC một cách tự động. Khi đầu cuối nhận được lời mời tham gia phiên PoC, nó sẽ chấp nhận và bật phương tiện truyền thông liên quan đến phiên đó (ví dụ như một bản nhạc để báo cho user chẳng hạn). Hình 3.35 là ví dụ cho chế độ trả lời tự động.
Hình 3.35. Chế độ trả lời tự động.
3.6 DỊCH VỤ HỘI NGHỊ
Dịch vụ hội nghị là dịch vụ hội thoại giữa nhiều cá nhân tham gia. Có nhiều loại hội nghị khác nhau. Hội nghị không chỉ giới hạn có dạng thoại tham gia mà còn cho cả video và văn bản; nhờ thế người tham gia hội nghị ngoài việc thông tin thoại, còn có thể nhìn thấy nhau và gửi văn bản trực tiếp cho nhau.
3.6.1 Cấu trúc
Cấu trúc hệ thống IMS thực hiện dịch vụ hội nghị luôn có một điểm trung tâm báo hiệu, thực hiện kết nối tất cả những thành viên tham gia hội nghị lại với nhau. Điểm trung tâm này cung cấp một loạt các dịch vụ hội nghị bao gồm trộn phương tiện (Media Mixing), chuyển đổi mã (transcoding) và các thông báo danh sách người tham gia.
Có nhiều cách để tạo một hội nghi: dùng SIP tạo các hội nghi ad hoc; các hội nghị đã được lập danh mục (dùng CPCP – Conference Policy Control Protocol, là giao thức client- server được các user dùng để vận dụng các luật áp dụng trong hội nghị);
Hình 3.36 là cấu trúc hệ thống dịch vụ hội nghị. Nó nhận dạng các giao diện giữa các thực thể và các giao thức sử dụng giữa chúng. UA trong hình đại diện cho người tham gia hội
nghị, là thực thể tạo một hội nghi ad hoc hoặc tham gia hội nghị dùng CPCP đã tạo bằng cách gửi yêu cầu SIP INVITE.
Hình 3.36. Cấu trúc IMS thực hiện dịch vụ hội nghị 3.6.2 Trạng thái hội nghị
Trình bày sự kiện trạng thái hội nghị (conference state) được dùng để biết các thay đổi của các thành viên tham gia hội nghị: nhờ các thông báo user có thể biết ai đã tham gia hay rời khỏi hội nghị. Gói sự kiện (Event package) này cũng cho phép các thành viên biết được trạng thái các thành viên của user trong hội nghị.
Các user có thể đăng ký trạng thái hội nghị bằng cách gửi một yêu cầu SUBSCRIBE đến URI conference đại diện cho máy chủ hội nghị (conference server). Conference Server sẽ đảm nhận làm bộ thông báo về các event package này.
Tên của event package này là ―conference‖. Thẻ này xuất hiện trong mào đầu Event của yêu cầu SUBSCRIBE. Thân của mỗi thông báo sẽ mang thông tin trạng thái hội nghị.
Hai phần thông tin về trạng thái user là: trạng thái hiện tại của user (activity-status) và phương thức mà người tham gia vào hoặc ra khỏi hội nghị (history-status). Activity-status mang một trong các trạng thái sau: dialled-in, dialled-out, departed, booted hoặc failed.
3.6.3 Ví dụ
Khi tạo hội nghi bằng URI conference factory, người tham gia hội nghị sẽ tạo yêu cầu INVITE có URI chứa URI conference factory. Conference server tạo một tiêu điểm (focus) cho hội nghị đã tạo, phân công cho nó một URI conference và trả về mào đầu Contact chứa URI này ở phản hồi 200 OK. URI chứa một tham số ―isfocus‖ chỉ ra URI là của focus này. Khi nhận được phản hồi 200 OK cho yêu cầu INVITE, người tham dự hội nghị sẽ lưu lại nội dung của mào đầu Contact chứa URI conference. URI này có thể được dùng để chỉ cho user đến hội nghị (hình 3.37).
Hình 3.37. Tạo một hội nghị dùng URI conference factory [3]
Khi tạo một yêu cầu REFER (đã dự định cho một user) để mời user đó tham gia hội nghị, mào đầu Refer-To của yêu cầu REFER được đặt địa chỉ đến URI conference, có tham số ―isfocus‖. (hình 3.38).
Hình 3.39. Sự đăng ký trạng thái hội nghị [3]
Hình 3.40 là ví dụ về việc user dùng giao giao diện Ut, gửi bản tin CPCP tới conference server để thiết đặt hội nghị.
Trong đó user C thuộc diện đã được vào dang sách (Dial-in list), user B thì ngược lại (Dial-out list), user A đảm nhận làm điều phối (Moderator).
Lúc 7:00 GMT 28/11/2003 server conference tạo một focus. Focus đọc danh sách dial- out và tìm thấy user B trong đó. Focus sẽ gửi cho user B một lời mời tham gia vào hội nghị. User A sẽ đăng ký conference-state event package và thông báo rằng user B đã tham gia hội nghị. Một thời gian sau, user A thấy user C tham gia vào hội nghị. Lúc 15:00 GMT, focus gửi bản tin kết thúc hội nghị.
3.7 DỊCH VỤ QUẢN LÝ NHÓM
Với sự bùng nổ nhu cầu dịch vụ, một User có thể dùng nhiều thiết bị đầu cuối khác nhau như PDA, Mobile phone, PC,.. để tiện truy cập thì các dữ liệu dịch vụ cần được xây dựng một lần cho toàn bộ thiết bị đầu cuối của một User.
Một vấn đề đặt ra khi user dùng web, các user không muốn thực hiện quá nhiều hiệu chỉnh phức tạp cho trình duyệt, mặt khác web không cho phép dữ liệu dịch vụ tích hợp cùng với các ứng dụng dịch vụ chạy trên một mobile phone hay bất cứ thiết bị nào.
Xét một ví dụ, khi một user muốn tạo một dịch vụ dạnh sách hiển thị người thân (buddy list) trên máy PC và mobile phone. Khi không áp dụng quản lý nhóm, user sẽ phải tạo buddy list hai lần: một trên PC và một trên mobile. User sẽ không thể dùng dịch vụ web messenger tại quán café internet vì buddy list của họ được lưu trữ tại PC và mobile. Nếu dữ liệu buddy list được lưu trữ trên mạng thì vấn đề này sẽ được giải quyết. User chỉ cần xây dựng buddy list một lần trên bất kỳ thiết bị nào, sau đó dữ liệu buddy list sẽ được tải lên và lưu trữ trong mạng dưới dạng một danh sách. Khi user thay đổi danh sách đo, các thiết bị khác của họ cũng sẽ được thông báo để thay đổi buddy list.
Một ví dụ nữa đối với dịch vụ quản lý nhóm là sự tạo ra danh sách điều khiển truy nhập ACL (Access Control List). Alice có thể tạo một ACL cho phép Bob và John gọi cô ấy hoặc khởi tạo phiên PoC với Alice ngoại trừ Sarah. Mạng sẽ tự động từ chối bất kỳ thông tin nào từ Sarah đến Alice.
3.7.1 Khái niệm Dịch vụ Quản lý nhóm
Quản lý nhóm là dịch vụ cho phép các user lưu trữ dữ liệu dịch vụ trên mạng nhà cung cấp dịch vụ. Dữ liệu này có thể được user tạo ra, thay đổi hoặc xoá đi. Dữ liệu ở đây là bất cứ dữ liệu nào cần cho user hoàn thành dịch vụ. Ví dụ như buddy list và các danh sách trao quyền hiện tại.
Các dịch vụ như hiển thị, PoC, nhắn tin, … cần hỗ trợ quản lý nhóm để truy nhập tới nó. Một số ví dụ: