Iptv Tren Ims

BỘ GIÁO DỤC VÀ ĐÀO TẠO CỘNG HÒA XÃ HÔI CHỦ NGHĨA VIỆT NAMTRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI

--------------------------------------------------Độc lập - Tự do - Hạnh phúc---------------------------------

NHIỆM VỤ ĐỒ ÁN TỐT NGHIỆP

Họ và tên sinh viên: .…………….………….…….. Số hiệu sinh viên: ………………

Khoá:…………………….Khoa: Điện tử - Viễn thông Ngành: ……………….........

1. Đầu đề đồ án:

………………………………………………..………………………………………………………………………

……………………………………………………………………………………………………………..………...

2. Các số liệu và dữ liệu ban đầu:

……………………………………..……………………………………………..……..……………………………

……………………………………………………………………………………………………………………………….

…..………………………..…………………………………………………………………………………….

3. Nội dung các phần thuyết minh và tính toán:

………………………………………………………………………………………………………………..….

………………………………………………………………………………………………………………………………

……..….

………………………………………………………………………………………………………………………………

………..….……………………………………………………………………………………………

4. Các bản vẽ, đồ thị ( ghi rõ các loại và kích thước bản vẽ ):

………………………………………………………………………………………………………………………..….

…………………………………………………………………………………………………………………………..

……….………………………………………………………………………………………………………….

5. Họ tên giảng viên hướng dẫn: ………………………………………………………..……………………

6. Ngày giao nhiệm vụ đồ án: ………………………………………………….……………

7. Ngày hoàn thành đồ án: ………………………………………………………………………..………

Ngày tháng năm

Chủ nhiệm Bộ môn Giảng viên hướng dẫn

Sinh viên đã hoàn thành và nộp đồ án tốt nghiệp ngày tháng năm

Cán bộ phản biện

BỘ GIÁO DỤC VÀ ĐÀO TẠO

TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI---------------------------------------------------

BẢN NHẬN XÉT ĐỒ ÁN TỐT NGHIỆP

Họ và tên sinh viên: ....................................................................... Số hiệu sinh viên: ...........................

Ngành: .................................................................................................. Khoá: ....................................................

Giảng viên hướng dẫn:..............................................................................................................................................

Cán bộ phản biện: .......................................................................................................................................

1. Nội dung thiết kế tốt nghiệp:

...................................................................................................................................................................................................

...................................................................................................................................................................................................

...................................................................................................................................................................................................

...................................................................................................................................................................................................

...................................................................................................................................................................................................

...................................................................................................................................................................................................

......................................................................................................................

2. Nhận xét của cán bộ phản biện:

...................................................................................................................................................................................................

...................................................................................................................................................................................................

...................................................................................................................................................................................................

...................................................................................................................................................................................................

...................................................................................................................................................................................................

...................................................................................................................................................................................................

...................................................................................................................................................................................................

...................................................................................................................................................................................................

...................................................................................................................................................................................................

...................................................................................................................................................................................................

..........................................................................

Ngày tháng năm

Cán bộ phản biện

( Ký, ghi rõ họ và tên )

Thiết kế và triển khai dịch vụ IPTV trên nền IMS

Khoa điện tử viễn thông - Đt4 K50

Giang Kỳ Nam

LỜI NÓI ĐẦU

Trong những năm qua xu hướng hội tụ mạng Internet, mạng di động và mạng

PSTN đang là xu hướng được quan tâm hàng đầu trong lĩnh vực thông tin liên lạc.

Nhiều kiến trúc mới đã ra đời trong quá trình phát triển hợp nhất các mạng với mục

đích tạo ra một mạng toàn IP duy nhất. Phân hệ IP Multimedia Subsystem (IMS) là

một trong những kiến trúc đã ra đời trong xu thế phát triển đó. Với IMS người dùng

có thể liên lạc khắp mọi nơi nhờ tính di động của mạng di động và đồng thời có thể

sử dụng những dịch vụ hấp dẫn từ mạng Internet. IMS đã thực sự trở thành chìa

khóa để hợp nhất mạng di động và mạng Internet. IMS đồng thời cũng trở thành

một phân hệ trong mô hình mạng thế hệ mới (NGN) của tất cả các hang sản xuất

các thiết bị viễn thông và các tổ chức chuẩn hóa trên thế giới.

IMS được chuẩn hóa bởi 3GPP và 3GPP2 dựa trên giao thức báo hiệu SIP và

các giao thức mở khác do IETF chuẩn hóa nên rất dễ dàng tích hợp với các dịch vụ

mới. IMS đồng thời cũng hỗ trợ nhiều loại hình truy cập khác nhau do đó nó hứa

hẹn sẽ mang lại một số lượng lớn khách hàng sử dụng các dịch vụ xây dựng trên đó.

Trong thời gian thực tập tại phòng lab 618 thư viện điện tử của bộ môn kỹ

thuật thông tin để tìm hiểu về kiến trúc IMS và triển khai các dịch vụ mới trên IMS,

được sự gợi ý của tiến sĩ Nguyễn Tài Hưng em đã lựa chọn đề tài “Thiết kế và

triển khai dịch vụ IPTV trên kiến trúc mạng IMS”.

Em xin chân thành cám ơn TS. Nguyễn Tài Hưng và TS. Nguyễn Hữu Thanh đã

giúp đỡ tận tình cho em trong thời gian làm đồ án vừa qua.

Em xin chân thành cám ơn

Hà Nội, ngày 20 tháng 05 năm 2010

Sinh viên

Giang Kỳ Nam



Giang Kỳ Nam

TÓM TẮT ĐỒ ÁN

Trong những năm gần đây, dịch vụ IPTV đang là chủ đề nóng thu hút sự

quan tâm của nhiều nhà cung cấp dịch vụ mạng viễn thong di động trên thế giới.

Bên cạnh đó kiến trúc mạng IMS nổi lên như 1 xu hướng trong kiến trúc mạng thế

hệ tiếp theo. Như vậy triển khai dịch vụ IPTV trên nền IMS sẽ mang lại cho người

dùng những trải nghiệm dịch vụ như thế nào và tính thực tế của nó ra sao?

Trong đề tài này, tôi chỉ ra giải pháp thiết kế triển khai dịch vụ trên nền tảng

IMS, so sánh nó với những kiến trúc truyền thống để thấy được ưu điểm của nó về

tốc độ và chi phí cho phát triển dịch vụ trong mạng viễn thông nói chung. Theo đó

tôi đưa ra mô hình của dịch vụ IPTV trên kiến trúc IMS, sử dụng các siao thức SIP,

Diameter, công nghệ Sip Servlet để triển khai nó và chứng minh tính mềm dẻo và

đa tính năng, dễ dàng mở rộng của IMS.

ABSTRACTION

Today, IPTV is presently a hot topic that is attracting the attention of many

telecom network operators. Beside, IMS emerges to be the trend in developing the

architecture of the next generation network. So what will IMS based IPTV bring to

the end users in terms of service experience and how does it become reality?

In this project, I present a solution in designing and developing services in

IMS architecture, put it in comparison to traditional architecture to realize its

advantages regarding speed and cost of service development in telecom network in

general. After that, I bring out IMS based IPTV architecture that implements SIP,

Diameter protocol, Sip servlet technology and develop it to demonstrate the

flexibility, multi function and scalability of IMS.

5



Giang Kỳ Nam

MỤC LỤC

1 CHƯƠNG I : MỞ ĐẦU ....................................................................................... 15 1.1 Tầm quan trọng của đề tài .............................................................................. 15 1.2 Nội dung nghiên cứu ...................................................................................... 16

2 CHƯƠNG II : VỀ KIẾN TRÚC IMS ................................................................... 17 2.1 Kiến trúc tổng quát IMS ................................................................................. 17

2.1.1 Mạng truy nhập ....................................................................................... 18 2.1.2 Mạng lõi .................................................................................................. 19 2.1.3 Tầng dịch vụ ............................................................................................ 29

2.2 Định danh trong IMS ..................................................................................... 30 2.2.1 Định danh người dùng công cộng ............................................................ 30 2.2.2 Định danh người dùng riêng .................................................................... 32 2.2.3 Mối quan hệ giữa định danh công cộng và định danh riêng .................... 32 2.2.4 Định danh dịch vụ công cộng .................................................................. 34

2.3 SIM, USIM và ISIM trong 3GPP ................................................................... 35 2.3.1 SIM .......................................................................................................... 36 2.3.2 USIM ....................................................................................................... 36 2.3.3 ISIM ........................................................................................................ 36

2.4 Tiêu chuẩn lọc ................................................................................................ 37 2.5 Triển khai kiến trúc IMS ................................................................................ 43

3 CHƯƠNG III : CÁC GIAO THỨC QUAN TRỌNG ........................................... 46 3.1 Giao thức SDP ............................................................................................... 46

3.1.1 Mô tả phiên .............................................................................................. 46 3.1.2 Mô hình Offer/Answer ............................................................................ 48 3.1.3 SIP và SIPS URIs .................................................................................... 49 3.1.4 Định vị người dùng .................................................................................. 50

3.2 Giao thức Diameter ........................................................................................ 51 3.2.1 Gói tin Diameter ...................................................................................... 52 3.2.2 Phiên giao dịch ........................................................................................ 53 3.2.3 Triển khai giao thức trong đề tài .............................................................. 55

3.3 Giao thức SIP ................................................................................................. 59 3.3.1 SIP liên hệ với HTTP như thế nào ........................................................... 60 3.3.2 Bản tin SIP .............................................................................................. 62 3.3.3 Phiên giao dịch (Transaction) .................................................................. 63 3.3.4 Hội thoại (dialog) .................................................................................... 65 3.3.5 Trường điều khiển Record-Route, Route và Contact ............................... 67

4 CHƯƠNG IV : MÁY CHỦ ỨNG DỤNG ............................................................ 69 4.1 Tổng quan về máy chủ ứng dụng ................................................................... 69

6



Giang Kỳ Nam

4.2 Chức năng của máy chủ ứng dụng trong mô hình IMS .................................. 69 4.3 Các chế độ hoạt động của máy chủ ứng dụng ................................................ 71

4.3.1 AS hoạt động như SIP User Agent .......................................................... 71 4.3.2 AS hoạt động như back-to-back user agent ............................................. 72 4.3.3 AS đóng vai trò như là SIP Proxy Server ................................................ 73 4.3.4 AS đóng vai trò như là SIP Redirect Server ............................................ 74

4.4 Giao diện AS với các thành phần khác trong mạng ........................................ 75 4.4.1 Giao diện với IMS Core – ISC ................................................................ 75 4.4.2 Giao diện với HSS – Sh ........................................................................... 76

4.5 Quá trình cung cấp dịch vụ ............................................................................ 81 4.5.1 Giới thiệu ................................................................................................. 81 4.5.2 Sự hình thành tiêu chuẩn lọc khởi tạo ...................................................... 81 4.5.3 Lựa chọn máy chủ ứng dụng ................................................................... 84 4.5.4 Hành vi của máy chủ ứng dụng ............................................................... 86 4.5.5 Máy chủ ứng dụng tương tác với HSS ..................................................... 86 4.5.6 Máy chủ ứng dụng gửi yêu cầu về S-CSCF ............................................. 87

5 CHƯƠNG V : DỊCH VỤ IPTV TRÊN NỀN IMS ............................................... 88 5.1 Giới thiệu dịch vụ IPTV trên nền IMS ........................................................... 88 5.2 Các luồng xử lý cuộc gọi trong IPTV nền IMS .............................................. 90

5.2.1 Đăng ký vào mạng IMS ........................................................................... 90 5.2.2 Call flows của các chức năng chính trong dịch vụ IPTV ......................... 93 5.2.3 Các tình huống khi đăng nhập và sử dụng dịch vụ IPTv ....................... 101

6 CHƯƠNG VI : THIẾT KẾ DỊCH VỤ IPTV ...................................................... 103 6.1 Tổng quan về công nghệ SIP Servlet ........................................................... 103

6.1.1 Mô hình SIP Servlet .............................................................................. 103 6.1.2 Các khái niệm chính của SIP Servlet API ............................................. 104

6.2 Thiết kế dịch vụ ........................................................................................... 112 6.2.1 Yêu cầu .................................................................................................. 112 6.2.2 Kiến trúc hệ thống ................................................................................. 112 6.2.3 Thiết kế các lớp cho dịch vụ .................................................................. 115 6.2.4 Kịch bản thực thi ứng dụng ................................................................... 126

6.3 Cài đặt và sử dụng dịch vụ ........................................................................... 126 6.3.1 Yêu cầu hệ thống ................................................................................... 126 6.3.2 Hướng dẫn cài đặt .................................................................................. 126 6.3.3 Kết quả thu được ................................................................................... 126

1. Poster paper gửi tại hội nghị TridentCom – Berlin ............................................ 128 2. Cài đặt Open IMS Core lên Ubuntu ................................................................... 136 3. Cài đặt máy chủ ứng dụng sailfin ...................................................................... 138 4. Cài đặt dịch vụ IPTV lên máy chủ Sailfin ......................................................... 139

Provisioning FHoSS .......................................................................................... 139 Povisioning content database ............................................................................ 139 Povisioning Diameter Peer ................................................................................ 139

7



Giang Kỳ Nam

Povisioning User Repository ............................................................................. 139 Cấu hình máy chủ IPTV .................................................................................... 139

Tạo JDBC Resources cho MySQL(để kết nối tới máy chủ MySql) .............. 140 JDBC Connection Pool ................................................................................. 140

5. Chạy thử với HUT - Communicator .................................................................. 147 Ngữ cảnh: .......................................................................................................... 147 Thiết lập dịch vụ Iptv và Parental control: ........................................................ 147 Hoạt động .......................................................................................................... 152

8



Giang Kỳ Nam

DANH SÁCH HÌNH VẼ

Hình 2-1 : Kiến trúc IMS.........................................................................................18Hình 2-2 : Giao tiếp giữa PSTN/CS gateway và mạng CS......................................25Hình 2-3 : P-CSCF đặt tại mạng khách....................................................................28Hình 2-4 : P-CSCF đặt tại mạng chủ ......................................................................28Hình 2-5 : Quan hệ giữa định danh người dùng riêng và định danh người dùng công cộng theo 3GPP R5.................................................................................................33Hình 2-6 : Quan hệ giữa định danh người dùng riêng và định danh người dùng công cộng theo 3GPP R6.................................................................................................34Hình 2-7 : Cấu trúc của User Profile.......................................................................39Hình 2-8 : Cấu trúc tiêu chuẩn lọc khởi tạo.............................................................40Hình 2-9 : Sơ đồ các khối chức năng trong kiến trúc IMS.......................................43Hình 3-10 : Một ví dụ về mô tả phiên SDP..............................................................47Hình 3-11 : Các kiểu trong SDP..............................................................................48Hình 3-12 : Mô tả phiên SDP của Bob....................................................................49Hình 3-13 : Alice đăng ký vị trí người dùng với tên miền domain.com registrar... .51HÌnh 3-14: Cấu trúc gói tin Diameter......................................................................52HÌnh 3-15: Cấu trúc AVP trong gói tin Diameter....................................................53HÌnh 3-16: Diameter transaction.............................................................................54HÌnh 3-17: IFC của người dùng tải về từ HSS.........................................................57HÌnh 3-18: Repository data của 1 người dùng IPTV...............................................58Hình 3-19 : Các bước thiết lập một cuộc gọi...........................................................60Hình 3-20 : Cấu trúc bản tin SIP..............................................................................63Hình 3-21 : Transaction...........................................................................................65Hình 3-22 : Luồng cuộc gọi trong một hội thoại SIP...............................................66Hình 3-23 : Cách sử dụng Record-Route, Route và Contact....................................68Hình 4-24 : Hướng tiếp cận dịch vụ trong kiến trúc IMS........................................70Hình 4-25 : AS hoạt động như một SIP UA............................................................72Hình 4-26 : Kiến trúc logic của SIP B2BUA...........................................................73Hình 4-27 : AS ứng dụng đóng vai trò SIP B2BUA................................................73Hình 4-28 : AS đóng vai trò SIP Proxy AS.............................................................74Hình 4-29 : AS đóng vai trò SIP Redirect Server....................................................74Hình 4-30 : Sh data uml diagram.............................................................................79Hình 4-31 : Thành phần của Service Point Trigger.................................................82Hình 4-32 : Ví dụ về User Profile............................................................................84HÌnh 5-33:Quá trình đăng ký của user vào mạng IMS (tiếp)...................................90HÌnh 5-34: Quá trình đăng ký của user vào mạng IMS (tiếp)..................................91HÌnh 5-35: Quá trình đăng ký của user vào mạng IMS (tiếp)..................................92HÌnh 5-36: Người dùng thông thường ....................................................................94HÌnh 5-37: Đăng nhập với dịch vụ IPTV trường hợp có Access control.................95

9



Giang Kỳ Nam

HÌnh 5-38: Dịch vụ truyền hình cơ bản...................................................................96HÌnh 5-39: Dịch vụ VoD tiêu chuẩn........................................................................99HÌnh 5-40: Dịch vụ VoD nâng cao........................................................................100Hình 6-41 : Vòng đời của Servlet..........................................................................106Hình 6-42 : Minh họa cấu trúc phân cấp của đối tượng SipServletRequest và SipServletResponse...............................................................................................110HÌnh 6-43: Mô hình tổng quát dịch vụ IMS based IPTV.......................................113HÌnh 6-44: sơ đồ lớp cho gói user profile..............................................................116HÌnh 6-45: Sơ đồ lớp gói servlets..........................................................................117HÌnh 6-46: Các lớp trong gói tools........................................................................118HÌnh 6-47: Sơ đồ lớp gói diameter........................................................................119HÌnh 6-48: Lưu đồ thuật toán khởi tạo dịch vụ.....................................................122HÌnh 6-49: Lưu đồ thuật toán đăng nhập vào dịch vụ............................................123HÌnh 6-50: Lưu đồ thuật toán xử lý yêu cầu kênh.................................................125

DANH SÁCH BẢNG BIỂU

Bảng 3-1: Diameter commands...............................................................................52Bảng 3-2: Diameter AVPs.......................................................................................53

10



Giang Kỳ Nam

DANH SÁCH CÁC TỪ VIẾT TẮT

STT Từ viết

tắt

Tên đầy đủ

01 3GPP Third Generation Partnership Project

02 3GPP2 Third Generation Partnership Project 2

03 ACK Acknowledgment

04 ADSL Asymmetric Digital Subscriber Line

05 AS Application Server

06 ATM Asynchoronous Transfer Mode

07 B2BUA Back-to-back User Agent

08 BGCF Breakout Gateway Control Function

09 BICC Bearer Independent Call Control

10 COPS Common Open Policy Service

11 CSCF Call Session Control Function

12 DHCP Dynamic Host Configuration Protocol

13 DNS Domain Name System

14 ENUM Telephone Number Mapping

15 GGSN Gateway GPRS Support Node

16 GPRS General Packet Radio Service

17 GSM Global System for Mobile Communications

18 HLR Home Location Register

19 HSS Home Subscriber Serverhttp://www.acronymfinder.com/Global-

System-for-Mobile-Communications-%28cellular-phone-20 HTTP Hypertext Transfer Protocol

21 I-CSCF Interrogating-CSCF

22 IETF Internet Engineering Task Force

23 IFC Initial Filter Criteria

24 IM-SSF IP Multimedia Service Switching Function

25 IMS IP Multimedia Subsystem

11

http://www.acronymfinder.com/Global-System-for-Mobile-Communications-(cellular-phone-technology)-(GSM).html



Giang Kỳ Nam

26 IMSI International Mobile Subscriber Identifier

27 IP Internet Protocol

28 IP-CAN IP Connectivity Access Network

29 ISC IMS Service Control

30 ISIM IP multimedia Services Identity Module

31 ISUP ISDN User Part

32 ITU-T International Telecommunication Union-Telecommunications

33 MAP Mobile Application Part

34 MEGACO Media Gateway Control

35 MGCF Media Gateway Control Function

36 MGW Media Gateway

37 MIME Multipurpose Internet Mail Extensions

38 MRF Media Resource Function

39 MRFC Media Resource Function Controllers

40 MRFP Media Resource Function Processors

41 MSISDN Mobile Subscriber ISDN Number

42 NAI Network Access Identifier

43 OSA-SCS Open Service Access–Service Capability Server

44 P-CSCF Proxy-CSCF

45 PA Presence Agent

46 PDF Policy Decision Function

47 PEP Policy Enforcement Point

48 PIDF Presence Information Data Format

49 PS Presence Agent

50 PSI Public Service Identity

51 PSTN Public Switched Telephone Network

52 PUA Presence User Agent

53 QoS Quality of Service

12



Giang Kỳ Nam

54 RTP Real-Time Transport Protocol

55 RTCP RTP Control Protocol

56 S-CSCF Serving-CSCF

57 SCTP Stream Control Transmission Protocol

58 SDP Session Description Protocol

59 SFC Subsequent Filter Criteria

60 SGSN Serving GPRS Support Node

61 SGW Signalling Gateway

62 SIM Subscriber Indetity Module

63 SIP Session Initiation Protocol

64 SLF Subscriber Location Function

65 SPT Service Point Trigger

66 SS7 Sinaling System No. 7

67 TCP Transmission Control Protocol

68 THIG Topology Hiding Inter-network Gateway

69 UA User Agent

70 UAC User Agent Client

71 UAS User Agent Server

72 UDA User Data Answer

73 UDP User Datagram Protocol

74 UDR User Data Request

75 UE User Equipment

76 UICC Universal Integrated Circuit Card

77 UMTS Universal Mobile Telecommunication System

78 URI Uniform Resource Identifier

79 URL Uniform Resource Locator

80 USIM Universal Subscriber Identity Module

81 VoIP Voice over IP

13



Giang Kỳ Nam

82 VoD Video on Demand

83 WAP Wireless Application Protocol

84 WLAN Wireless Local Access Network

85 WLSS WebLogic SIP Server

86 XML Extensible Markup Language

14



Giang Kỳ Nam

1 CHƯƠNG I : MỞ ĐẦU

1.1 Tầm quan trọng của đề tàiIMS là 1 công nghệ trong đó hội tụ và triển khai thoại và dữ liệu trên 1

platform duy nhất, và là 1 kiến trúc mở sử dụng giao thức Internet. Với IMS,

rất nhiều dịch vụ đa phương tiện có thể được cung cấp bởi chỉ 1 nhà mạng hay

với chỉ 1 thiết bị mọi lúc mọi nơi. Trong quá khứ, truyền thông không dây và

có dây và hệ thống cáp được triển khai tách biệt, nhưng giờ đây, những hệ

thống như thế có thể hội tụ lại thành 1 mạng truy cập thông qua nền tảng IMS

và qua 1 nền tảng duy nhất đó, các nhà cung cấp dịch vụ có thể giảm chi phí

quản lý và tăng hiệu suất hoạt động của mình.

Thêm vào đó, với vai trò là 1 kiến trúc tiêu chuẩn, IMS làm tăng tính tương

thích giữa các nhà cung cấp thiết bị cũng như dịch vụ, do đó làm tăng tốc độ

phát triển ứng dụng 1 cách đáng kể. Có nghĩa là càng ngày càng có nhiều dịch

vụ thân thiện, tiện lợi hướng tới người dùng hơn dẫn đến làm tăng sự thoải

mái của khách hàng.

IPTV là một trong những dịch vụ mà IMS có thể cung cấp tới người dùng. Ý

tưởng của dịch vụ này cũng không ngoài mục đích đem lại sự tiện lợi cho

người dùng:

“Hàng ngày đi làm về Nam hay xem TV trên xe bus. Chương trinh ưa thích

của anh ý là kênh thông tinh quốc gia VTV1. Sau khi quay số đến 1 địa chỉ

dạng email ([email protected]), kênh truyền hình này lập tức được trả về

và hiển thị trên màn hình điện thoại, dễ dàng và đơn giản như là thực hiện 1

cuộc gọi tới bạn bè. Tất cả những kênh ưa thích đều được lưu giữ trên máy

chủ của nhà cung cấp và được chia sẻ với chiếc Setopbox ở nhà anh ý.”

15

mailto:[email protected]



Giang Kỳ Nam

“Nam rất háo hức về bộ phim Iron man2. 1 ngày anh nhận được tin nhắn từ

dịch vụ IPTv mà anh đã đăng ký là Iron man2 đã có trên kho phim theo yêu

cầu. Tối hôm đó Nam quay số tới [email protected] bằng chiếc STB ở

nhà, sau đó chọn bộ phim ưa thích của mình trong danh sách kênh trả về của

nhà mạng.”

“Nam rất hài lòng với chất lượng cũng như giá của bộ phim và trên màn hình

ti vi anh mở danh sách bạn bè ra và gửi 1 tin nhắn ngắn tới người bạn của

mình là Hùng([email protected])”

…

Tất nhiên ngữ cảnh trên chưa thực tế ở thời điểm hiện tại, tuy nhiên trong 1

tương lai rất gần, câu chuyện này sẽ trở nên phổ biến. Những giao tiếp tương

tác dịch vụ như thê sẽ trở nên rất dễ dàng khi được hỗ trợ bởi kiến trúc IMS

1.2 Nội dung nghiên cứuVới mực đích nghiên cứu là phát triển ứng dụng theo kiến trúc IMS nên trong

đề tài này em sẽ tập trung tìm hiểu tổng quan về IMS, máy chủ ứng dụng và

về dịch vụ IPTV:

• Tổng quan về IMS: tìm hiểu về kiến trúc IMS, các thành phần, chức

năng của từng thành phần, kiến trúc triển khai và một số các khái niệm

quan trọng sử dụng trong IMS.

• Các giao thức liên quan: giới thiệu về 1 số giao thức quan trọng chủ

yếu dùng trong mạng IMS, phục vụ cho đề tài.

• Giới thiệu dịch vụ IPTV: tổng quát về dịch vụ IPTV, các call flow

quan trọng trong dịch vụ, các tình huống trong sử dụng dịch vụ.

• Thiết kế dịch vụ IPTV: thiết kế dịch vụ từ các yêu cầu thực tế, sơ đồ

lớp.

16





Giang Kỳ Nam

• Triển khai dịch vụ: các bước sử dụng dịch vụ đối với người dùng

cuối.

2 CHƯƠNG II : VỀ KIẾN TRÚC IMS

Trong chương này sẽ nói về kiến trúc IMS, chi tiết các thành phần của nó và 1

số khái niệm cơ bản liên quan đến mạng IMS và kết nối giữa nó và các kiến

trúc mạng khác

2.1 Kiến trúc tổng quát IMSTrước khi tìm hiểu kiến trúc tổng quát IMS, chúng ta nên nhớ rằng 3GPP

không chuẩn hóa theo nút mà theo chức năng. Điều đó có nghĩa là kiến trúc

IMS là một tập hợp các chức năng được kết nối với nhau bởi các giao diện đã

được chuẩn hóa. Các nhà triển khai có thể kết hợp hai chức năng vào một nút.

Tương tự, các nhà triển khai có thể tách một chức năng thành hai hay nhiều

nút.

Nhìn chung thì hầu hết những dịch vụ cung cấp đều tuân theo kiến trúc IMS

một cách chặt chẽ và triển khai mỗi chức năng trong một nút riêng. Tuy nhiên,

việc tìm kiếm các nút triển khai nhiều hơn một chức năng và các chức năng

được phân phối qua nhiều hơn một nút là hoàn toàn có thể.

17



Giang Kỳ Nam

Hình 2-1 : Kiến trúc IMS

Trong hình 2-1 minh họa một cái nhìn tổng quan về kiến trúc IMS như chuẩn

hóa của 3GPP. Trong hình chỉ ra hầu hết các giao diện báo hiệu trong hệ

thống IMS, nó thường được đề cập đến bởi hai hay ba ký tự mã hóa. Chúng ta

không thể vẽ tất cả các giao diện được định nghĩa trong IMS mà chỉ có thể liệt

kê hầu hết những nút giao diện có liên quan. Trong IMS được phân chia thành

3 phần: mạng truy nhập, mạng lõi và tầng dịch vụ.

2.1.1 Mạng truy nhập

Ở phía bên trái hình 2-1, chúng ta có thể nhìn thấy các đầu cuối IMS di động

thường được nhắc đến như là các thiết bị người dùng (User Endpoint). Đầu

cuối IMS được nối vào mạng chuyển mạch gói như là GPRS thông qua

đường truyền vô tuyến.

Chú ý rằng, mặc dù hình trên chỉ chỉ ra một thiết bị đầu cuối IMS nối vào

mạng sử dụng đường truyền vô tuyến nhưng IMS cũng hỗ trợ các loại thiết

bị và các cách truy nhập khác. Thiết bị hỗ trợ cá nhân PDAs và máy tính là

18



Giang Kỳ Nam

các ví dụ về các thiết bị có thể kết nối tới IMS. Một ví dụ khác về phương

pháp truy cập là WLAN và ADSL.

2.1.2 Mạng lõi

Phần còn lại của hình chỉ ra các nút bao gồm trong mạng lõi IMS. Các nút

này là:

• Một hay vài cơ sở dữ liệu người dùng, còn gọi là HSS và SLF.

• Một hay vài máy chủ ứng SIP gọi là CSCF (Call Session Control

Function).

• Một hay vài MRF mỗi cái được chia nhỏ thành MRFC và MRFP.

• Một hay vài BGCF (Breakout Gateway Control Functions).

• Một hoặc vài PSTN gateways, được chia nhỏ hơn thành SGW và

MGCF.

2.1.2.1 Cơ sở dữ liệu HSS và SLF

HSS (Home Subscriber Server) là trung tâm lưu trữ dữ liệu các thông tin

liên quan đến người dùng. Về kỹ thuật thì HSS giống như HLR (Home

Location Register), HLR là một nút trong mạng GSM. HSS bao gồm các

thông tin thuê bao liên quan đến người dùng được yêu cầu để điều khiển

các phiên đa phương tiện. Những dữ liệu này bao gồm, thông tin vị trí,

thông tin bảo mật (bao gồm các thông tin nhận thực và phân quyền), các

thông tin về tiểu sử người dùng (bao gồm các dịch vụ mà người dùng đăng

ký thuê bao), và S-CSCF cấp phát tới người dùng.

Một mạng có thể chứa một hoặc một vài HSS, trong trường hợp số lượng

thuê bao quá nhiều so với sự quản lý của một HSS. Trong tất cả trường

hợp, tất cả các dữ liệu liên quan đến một người dùng cụ thể được chứa

trong một HSS. Các mạng với một HSS sẽ không cần SLF (Subscriber

19



Giang Kỳ Nam

Location Function). Mặt khác, mạng với nhiều hơn một HSS yêu cầu có

SLF.

SLF là một cơ sở dữ liệu đơn giản ánh xạ địa chỉ người dùng tới HSS quản

lý tương ứng. Một nút yêu cầu truy vấn SLF, với một địa chỉ người dùng là

đầu vào, sẽ thu được ở đầu ra là HSS có chứa thông tin liên quan đến người

dùng đó.

Cả HSS và SLF đều thực thi giao thức Diameter với các đặc trưng ứng

dụng diameter cho IMS.

2.1.2.2 Chức năng điều khiển cuộc gọi phiên

Điều khiển cuộc gọi phiên (CSCF) là một máy chủ SIP, là một nút cần thiết

trong IMS. Các CSCF xử lý các bản tin báo hiệu SIP trong IMS. Có ba loại

CSCF phụ thuộc vào các chức năng mà chúng cung cấp:

• Proxy-CSCF (P-CSCF) : là một máy chủ SIP, là điểm đầu tiên liên

lạc giữa đầu cuối IMS và mạng IMS. Nó có thể được đặt ở mạng

khách (trong toàn bộ mạng IMS) hoặc mạng chủ. Một vài mạng có

thể sử dụng thiết bị kiểm soát biên giới phiên SBC (Session Border

Controller) để thực hiện chức năng này. Để kết nối với hệ thống

IMS, người dùng trước tiên phải gửi đăng ký tới P-CSCF trong

mạng mà nó đang kết nối. Địa chỉ của P-CSCF được truy cập thông

qua giao thức DHCP (Dynamic Host Configuration Protocol) hoặc

sẽ được cung cấp khi người dùng tiến hành thiết lập kết nối PDP

(Packet Data Protocol) trong mạng thông tin di động tế bào. Chức

năng của P-CSCF bao gồm:

o P-CSCF có nhiệm vụ đảm bảo chuyển tải các yêu cầu từ UE

đến máy chủ SIP (ở đây là S-CSCF) cũng như bản tin phản

hồi từ máy chủ SIP về UE.

20



Giang Kỳ Nam

o P-CSCF được gán cho đầu cuối IMS trong suốt quá trình

đăng ký, và không thay đổi trong suốt quá trình đăng ký.

o P-CSCF nằm trên đường đi của tất cả các bản tin báo hiệu và

có thể được gán vào mỗi bản tin.

o P-CSCF xác thực người dùng và thiết lập kết nối bảo mật

IPSec với thiết bị đầu cuối IMS của người dùng. P-CSCF còn

có vai trò ngăn cản các tấn công như spoofing, replay để đảm

bảo sự bảo mật và an toàn cho người dùng.

o P-CSCF có thể nén và giải nén các bản tin SIP dùng sigcomp,

để giảm thiểu khối lượng thông tin báo hiệu truyền trên

những đường truyền tốc độ thấp (hay giảm độ trễ khi truyền

trên các kênh có băng thông hẹp).

o P-CSCF có thể tích hợp chức năng quyết định chính sách

PDF (Policy Decision Function) nhằm quản lý và đảm bảo

QoS cho các dịch vụ đa phương tiện.

o P-CSCF cũng tham gia vào quá trình tính cước dịch vụ.

• Interrogating-CSCF (I-CSCF) : là một máy chủ SIP khác được

đặt ở biên của miền quản trị. Địa chỉ IP của I-CSCF được công bố

trong DNS (Domain Name System) của miền, vì thế các máy chủ

ứng dụng ở xa có thể tìm thấy I-CSCF và sử dụng I-CSCF như một

điểm chuyển tiếp cho các gói tin SIP tới miền này. Các chức năng

của I-CSCF bao gồm:

o Định tuyến bản tin yêu cầu SIP nhận được từ một mạng khác

đến S-CSCF tương ứng. Để làm được điều này, I-CSCF sẽ

truy vấn HSS thông qua giao diện Diameter Cx để cập nhật

địa chỉ S-CSCF tương ứng của người dùng (giao diện Dx

21



Giang Kỳ Nam

được dùng để từ I-CSCF tới SLF để định vị HSS cần thiết).

Nếu như chưa có S-CSCF nào được gán cho UE, I-CSCF sẽ

tiến hành gán một S-CSCF cho người dùng để nó xử lý yêu

cầu SIP.

o Ngược lại, I-CSCF sẽ định tuyến bản tin yêu cầu SIP hoặc

bản tin trả lời SIP đến một S-CSCF/I-CSCF nằm trong mạng

của một nhà cung cấp dịch vụ khác.

I-CSCF luôn luôn được đặt tại mạng chủ, trong một số trường hợp

như THIG (Topology Hiding Inter-network Gateway), I-CSCF được

đặt tại mạng khách là tốt nhất.

• Serving-CSCF (S-CSCF) : là một nút trung tâm của hệ thống báo

hiệu IMS. S-CSCF vận hành giống như một máy chủ SIP nhưng nó

cũng bao hàm cả chức năng quản lý phiên dịch vụ. Thêm vào việc

thực hiện chức năng là một máy chủ SIP thì nó cũng đóng vai trò

như một trung tâm đăng ký SIP (SIP registrar). Điều này có nghĩa là

nó duy trì mối liên hệ giữa vị trí của người dùng (nói cách khác là

địa chỉ IP của thiết bị đầu cuối mà người dùng đăng nhập) với địa

chỉ SIP của người dùng đó (cũng được biết đến như là định danh

chung của người dùng – Public User Identity).

Cũng giống như I-CSCF, S-CSCF cũng thực thi một giao diện

diameter với HSS. Lý do chính của việc sử dụng giao diện với HSS

là:

o Để tải các vector nhận thực của người dùng đang cố gắng truy

cập mạng từ HSS. S-CSCF sử dụng vector này để nhận thực

người dùng.

22



Giang Kỳ Nam

o Để tải hồ sơ người dùng từ HSS. Hồ sơ người dùng bao gồm

các triggers có thể làm cho bản tin SIP được định tuyến qua

một hoặc vài máy chủ ứng dụng.

o Để khai báo với HSS về S-CSCF được cấp cho người dùng

trong suốt quá trình đăng ký.

Tất cả các bản tin báo hiệu SIP mà đầu cuối IMS gửi và nhận đều đi

quá S-CSCF. S-CSCF sẽ kiểm tra mỗi bản tin SIP và quyết định xem

liệu bản tin báo hiệu này nên đi qua một hay nhiều máy chủ ứng

dụng trên đường đi tới đích cuối cùng của nó. Các máy chủ ứng

dụng này sẽ cung cấp các khả năng về một dịch vụ tới người dùng.

Một chức năng chính của S-CSCF là cung cấp dịch vụ định tuyến

bản tin SIP. Nếu người dùng quay số điện thoại thay vì sử dụng SIP

URI (Uniform Resource Identifier) thì S-CSCF cung cấp một dịch

vụ chuyển đổi, thường dựa trên chuẩn DNS E.164 Number

Translation (DNS/ENUM) (được mô tả trong RFC-2916 [100]).

S-CSCF cũng tác động vào chính sách mạng của nhà cung cấp. Ví

dụ, một người dùng có thể không có quyền thiết lập một phiên cụ thể

nào cả. S-CSCF tránh cho người dùng thực hiện các chức năng

không được cho phép.

Một mạng thường bao gồm một số các S-CSCF cho mục đích mở

rộng và dự phòng. Mỗi S-CSCF phục vụ một số lượng đầu cuối tùy

thuộc vào dung lượng của nó.

S-CSCF luôn luôn được đặt tại mạng chủ.

2.1.2.3 Máy chủ xử lý media

Máy chủ xử lý media (MRF) cung cấp tài nguyên media trong mạng chủ.

MRF (Media Resource Function) cung cấp cho mạng chủ khả năng đưa ra

23



Giang Kỳ Nam

các thông báo trong luồng media (ví dụ trong cầu hội thảo tập trung),

chuyển đổi giữa các loại mã hóa, thu nhận số liệu thống kê và thực hiện bất

cứ loại phân tích media nào.

MRF còn được chia thành một nút nhỏ hơn trong miền báo hiệu gọi là

MRFC (Media Resource Function Controller) và một nút trong miền media

là MRFP (Media Resource Function Processor). MRFC hoạt động như là

một SIP User Agent và chứa các giao diện SIP với S-SCSF. MRFC điều

khiển tài nguyên trong MRFP thông qua giao diện H.248.

MRFP triển khai tất cả các hàm liên quan đến media như là chơi và trộn

media.

MRF luôn đặt ở mạng chủ.

2.1.2.4 Chức năng điều khiển cổng chuyển mạng

Chức năng điều khiển cổng chuyển mạng (BGCF) thực hiện chủ yếu là

chức năng của máy chủ SIP bao gồm chức năng định tuyến dựa trên số điện

thoại. BGCF (Breakout Gateway Control Function) chỉ dùng trong các

phiên được khởi tạo bởi đầu cuối IMS và hướng tới một người dùng trong

mạng chuyển mạch kênh như là PSTN hay PLMN. Chức năng chính của

BGCF là:

• Lựa chọn mạng thích hợp nơi mà tương tác với miền chuyển mạch

kênh xảy ra.

• Hoặc lựa chọn cổng PSTN/CS phù hợp, nếu tương tác xảy ra trong

cùng một mạng mà BGCF được đặt.

2.1.2.5 PSTN/CS Gateway

24



Giang Kỳ Nam

PSTN gateway cung cấp một giao diện hướng tới một mạng chuyển mạch

kênh, cho phép các thiết bị đầu cuối IMS gọi và nhận cuộc gọi tới PSTN và

từ PSTN.

Hình 2-2 : Giao tiếp giữa PSTN/CS gateway và mạng CS

Hình 2-2 mô tả một BGCF và một PSTN gateway riêng biệt có giao tiếp

mạng với PSTN. PSTN gateway được phân tích thành các chức năng sau:

• SGW (Signalling Gateway) : Signalling gateway giao tiếp với mặt

phẳng báo hiệu của mạng chuyển mạch kênh. SGW thực hiện biến

đổi giao thức ở lớp thấp hơn. Ví dụ: SGW có nhiệm vụ thay thế các

giao thức MTP (ITU-T khuyến nghị Q.701 [133]) ở mức thấp hơn

vận chuyển cùng với SCTP (Stream Control Transmission Protocol,

được định nghĩa tại RFC 2960 [230]) trên địa chỉ IP. Vì thế, SGW

chuyển đổi ISUP (ITU-T khuyến nghị Q.761 [139]) hoặc BICC

25



Giang Kỳ Nam

[ITU-T khuyến nghị tại Q.1901 [140]) trên MTP thành ISUP hoặc

BICC trên SCTP/IP.

• MGCF (Media Gateway Control Function) : MGCF là nút trung tâm

của PSTN/CS gateway. MGCF triển khai một cơ chế thực hiện

chuyển đổi giao thức và ánh xạ SIP sang hoặc là ISUP trên IP hoặc

là BICC trên IP (cả BICC và ISUP đều là các giao thức điều khiển

cuộc gọi trong mạng chuyển mạch kênh). Hơn nữa, để biến đổi giao

thức điều khiển cuộc gọi thì MGCF điều khiển nguồn tài nguyên

trong MGW (Media Gateway). Giao thức được sử dụng giữa MGCF

và MGW là H.248 (ITU-T khuyến nghị H.248 [143]).

• MGW (Media Gateway) : Media Gateway giao tiếp với mặt phẳng

media của mạng PSTN hoặc mạng CS. Một mặt MGW có thể gửi

hoặc nhận media của IMS thông qua giao thức RTP (RFC 3550

[225]). Mặt khác, MGW sử dụng một hoặc nhiều khe thời gian PCM

(Pulse Code Modulation) để kết nối tới mạng CS. Thêm vào đó,

MGW thực hiện chuyển đổi mã khi đầu cuối IMS không hỗ trợ

codec được sử dụng bởi mạng chuyển mạch kênh. Một tình huống

phổ biến thường xảy là khi thiết bị đầu cuối IMS sử dụng bộ giải mã

AMR trong khi đó thiết bị đầu cuối của mạng PSTN lại sử dụng bộ

giải mã G.711 (ITU-T khuyến nghị G.711 [131]).

2.1.2.6 Mạng chủ và mạng khách

IMS mượn một vài khái niệm từ GSM và GPRS như mạng chủ và mạng

khách. Trong mô hình tế bào, khi chúng ta sử dụng điện thoại di động trong

khu vực nơi chúng ta cư trú, khi đó là chúng ta đang sử dụng cơ sở hạ tầng

do các nhà điều hành mạng cung cấp. Cở sở hạ tầng này hình thành mạng

chủ (home network). Mặt khác, khi chúng ta chuyển ra ngoài khu vực che

26



Giang Kỳ Nam

phủ của mạng chủ, chúng ta sử dụng cơ sở hạ tầng được cung cấp bởi một

nhà điều hành mạng khác. Cơ sở hạ tầng này được gọi là mạng khách

(visited network).

Để sử dụng mạng khách thì các nhà điều hành mạng khách và mạng chủ

phải có một thỏa thuận với nhau. Các thỏa thuận này có thể là giá cước

cuộc gọi, chất lượng dịch vụ hoặc là phương thức quy đổi bảng tính cước.

Hầu hết các nút IMS được đặt tại mạng chủ nhưng có nút cũng được đặt

trong mạng khách hoặc mạng chủ, nút đó là P-CSCF. Kiến trúc IMS cho

phép hai cấu hình khác nhau cho P-CSCF, tùy thuộc vào vị trí của P-CSCF

ở mạng khách hay mạng chủ.

Thêm vào đó, khi IP-CAN (IP Connectivity Access Network) là GPRS thì

vị trí của P-CSCF phụ thuộc vào vị trí của GGSN. Trong tình huống

chuyển vùng, GPRS cho phép vị trí của GGSN hoặc ở trong mạng chủ

hoặc ở trong mạng khách (bình thường SGSN luôn được đặt ở mạng

khách).

Trong IMS cả GGSN và P-CSCF phải nằm trong cùng một mạng. Điều này

cho phép P-CSCF điều khiển GGSN qua giao diện Go. Vì cả P-CSCF và

GGSN đều nằm trong cùng một mạng nên giao diện Go luôn luôn là giao

diện hoạt động bên trong và làm cho việc hoạt động của mạng đơn giản

hơn.

Hình 2-3, cho chúng ta thấy cấu hình P-CSCF (và GGSN) đặt tại mạng

khách. Cấu hình này thể hiện tầm nhìn lâu dài về IMS vì nó yêu cầu IMS

hỗ trợ thực hiện từ mạng khách.

27



Giang Kỳ Nam

Hình 2-3 : P-CSCF đặt tại mạng khách

Không thể mong đợi tất cả các mạng trên thế giới đều triển khai IMS đồng

thời. Do đó cũng không thể mong chờ tất cả các mạng thành phần sẽ cập

nhật các GGSN theo cùng một chuẩn tại cùng một thời điểm và cùng bắt

đầu cung cấp dịch vụ IMS. Vì vậy chúng ta chỉ có thể mong chờ việc sớm

có sự triển khai IMS mà P-CSCF ở trong mạng chủ như hình 2-4 dưới đây.

Hình 2-4 : P-CSCF đặt tại mạng chủ

Hình 2-4 chỉ ra cấu hình hiện tại khi cả P-CSCF và GGSN đều đặt tại mạng

chủ. Cấu hình này không yêu cầu sự hỗ trợ IMS từ mạng khách. Mạng

khách không cần phải có GGSN tuân theo phiên bản 3GPP Release 5.

Mạng khách chỉ cần cung cấp liên lạc vô tuyến và SGSN. Vì thế, cấu hình

28



Giang Kỳ Nam

này được triển khai từ những ngày đầu của IMS. Như một hệ quả, người ta

mong muốn rằng nó sẽ là cấu hình phổ biến trong những năm đầu triển khai

IMS.

2.1.3 Tầng dịch vụ

Phần này bao gồm các máy chủ ứng dụng có nhiệm vụ cung cấp các dịch vụ

tới người dùng cuối. Các máy chủ ứng dụng là các thực thể SIP thực hiện

dịch vụ và giao tiếp với S-CSCF sử dụng SIP. Phụ thuộc vào các dịch vụ

thực tế mà máy chủ ứng dụng có thể hoạt động ở các chế độ: SIP proxy, chế

độ SIP UA (User Agent) hay chế độ SIP B2BUA (Back-to-Back User

Agent). Máy chủ ứng dụng có thể nằm trong mạng chủ hoặc trong một mạng

thứ ba bên ngoài. Nếu nằm trong mạng chủ, nó có thể truy vấn HSS qua giao

diện diameter Sh (cho máy chủ ứng dụng), hay giao diện MAP (Mobile

Application Part) cho loại máy chủ IM-SSF (IP Multimedia Service

Switching Function).

Như đã nói ở trên, ưu điểm lớn nhất của IMS là khả năng phát triển các dịch

vụ mới một cách dễ dàng. Kiến trúc IMS được thiết kế để cho phép các nhà

điều hành cung cấp dải rộng các dịch vụ dựa trên chuyển mạch gói và thời

gian thực. IMS cũng cho phép lưu lại các thông tin của dịch vụ để có thể tính

cước dựa theo thời gian cũng như dựa trên dịch vụ và băng thông. Từ đặc

điểm thiết kế của mình, IMS kế thừa tất cả các dịch vụ ưu việt nhất của mạng

viễn thông và mạng internet đặc biệt là các dịch vụ đa phương tiện bao gồm

các dịch vụ gọi thông thường và các dịch vụ nâng cao như:

• Nhấn tin đa phương tiện

• Hội thảo đa phương tiện

• IPTV

• Dịch vụ kiểm tra trạng thái người dùng (Presence)

29



Giang Kỳ Nam

• Dịch vụ instant message

Tầng dịch vụ được thiết kế tách rời với mạng lõi và mạng truy nhập đã được

chuẩn hóa.

2.2 Định danh trong IMSTrong bất kỳ một mạng nào cũng đều phải dịnh danh được người dùng một

cách duy nhất. Đây là thuộc tính cho phép một điện thoại nhất định đổ chuông

mà không phải là một điện thoại khác khi chúng ta quay số trong mạng PSTN.

Vấn đề trung tâm của bất kỳ một mạng nào là khả năng của nhà cung cấp định

danh người dùng để cho cuộc gọi có thể đến được đúng người dùng. Trong

mạng điện thoại công cộng, người dùng được định danh bởi số điện thoại (là

một tập hợp các chữ số theo thứ tự định danh thuê bao điện thoại). Số điện

thoại xác định chủ thuê bao có thể được biểu diễn dưới nhiều dạng khác nhau:

dạng số nội hạt, số ngoại hạt hay số dạng quốc tế. Thực chất chúng chỉ là các

cách biểu diễn khác nhau của cùng một thuê bao. Độ dài của chuỗi số phụ

thuộc vào đích đến của cuộc gọi (ví dụ như cùng một khu vực, khác vùng hay

quốc gia khác).

Thêm vào đó, khi một dịch vụ được cung cấp, đôi khi nó cũng yêu cầu định

danh dịch vụ. Trong mạng PSTN, dịch vụ được định danh bởi những số đặc

biệt, thường có phần tiếp đầu đặc biệt, ví dụ như 800. IMS cũng cung cấp cơ

chế để định danh dịch vụ.

2.2.1 Định danh người dùng công cộng

Trong IMS cungc có một cách tiền định để xác định người dùng. Một người

dùng IMS cũng được cấp phát một hay nhiều định danh người dùng công

cộng. Nhà cung cấp dịch vụ nội hạt có trách nhiệm cấp phát các định danh

này cho mỗi thuê bao IMS. Một danh người dùng công cộng có thể là một

SIP URI (như định nghĩa trong RFC 3261 [215]) hay một TEL URI (như

30



Giang Kỳ Nam

định nghĩa trong RFC 3966 [220]). Định danh người dùng công cộng được

sử dụng như thông tin liên lạc trong thẻ thương mại. Trong IMS, định danh

người dùng công cộng được sử dụng để định tuyến các bản tin báo hiệu SIP.

Nếu chúng ta so sánh giữa IMS và GSM, một dịnh danh người dùng công

cộng đối với IMS cũng giống như một định danh MSISDN (Mobile

Subscriber ISDN Number) trong mạng GSM.

Khi định danh người dùng công cộng chứa SIP URI, nó thường có dạng là

sip:[email protected], mặc dù nhà cung cấp IMS có thể chuyển đổi

dạng thức này và thỏa mãn theo nhu cầu của họ. Thêm vào đó, cũng có khả

năng bao hàm số điện thoại trong SIP URI sử dụng định dạng sau:

sip:[email protected];user=phone

Định dạng này là cần thiết bởi SIP yêu cầu URI được đăng ký dưới là SIP

URI. Do đó, nó không thể đăng ký TEL URI trong SIP, mặc dù hoàn toàn có

thể đăng ký một SIP URI có chứa một số điện thoại.

TEL URI là một dạng khác mà định danh người dùng công cộng có thể sử

dụng được. Dưới đây là một TEL URI được trình bày dưới dạng số điện

thoại quốc tế:

tel:+1-212-555-0293

TEL URI là cần thiết để thực hiện một cuộc gọi từ đầu cuối IMS sang mạng

điện thoại công cộng PSTN, bởi vì số điện thoại PSTN được biểu diễn dưới

dạng số. Mặt khác, TEL URI cũng cần thiết nếu một thuê bao PSTN muốn

thực hiện một cuộc gọi đến một người dùng IMS, bởi vì người dùng PSTN

chỉ có thể quay số.

Chúng ta hình dung các nhà cung cấp dịch vụ sẽ cấp ít nhất một SIP URI và

một TEL URI cho mỗi một người dùng. Có rất nhiều lý do cho việc cấp

nhiều hơn một định danh người dùng công cộng cho một người dùng, như là

khả năng phân biệt các định danh cá nhân mà bạn bè và người thân đã biết 31



Giang Kỳ Nam

với định danh công cộng dùng trong công việc kinh doanh được biết đến bởi

các đồng nghiệp, hoặc là để kích hoạt một nhóm các dịch vụ.

IMS mang đến một khái niệm thú vị: một tập hợp định danh người dùng

công cộng được đăng ký. Trong hoạt động thông thường của SIP, mỗi định

danh cần đăng ký yêu cầu một bản tin SIP REGISTER. Trong IMS, ta có thể

đăng ký một vài định danh người dùng công cộng trong một bản tin, điều này

nhằm tiết kiệm thời gian và băng thông.

2.2.2 Định danh người dùng riêng

Mỗi thuê bao IMS được cấp một định danh người dùng riêng. Không giống

như định danh người dùng công cộng, định danh người dùng riêng không

phải là một SIP URI hay TEL URI, mà thay vào đó chúng thường có định

dạng của định danh người dùng truy nhập NAI (Network Access Identifier,

theo quy ước của RFC 2486 [451]). Định dạng của NAI là:

[email protected].

Không như định danh người dùng công cộng, định danh người dùng riêng

không được sử dụng để định tuyến bản tin yêu cầu SIP, thay vào đó chúng

được dành riêng cho việc định danh thuê bao và cho mục đích nhận thực.

Một định danh người dùng riêng thực hiện chức năng trong IMS tương tự

như IMSI (International Mobile Subscriber Identifier) trong mạng GSM.

Định danh người dùng riêng không cần người dùng biết đến, bởi vì nó có thể

được lưu trong một thẻ thông minh cũng giống như IMSI được lưu trong

SIM (Subscriber Identity Module).

2.2.3 Mối quan hệ giữa định danh công cộng và định danh riêng

Nhà cung cấp dịch vụ cấp một hoặc nhiều định danh người dùng công cộng

cho mỗi một người dùng. Trong trường hợp GSM/UMTS (Universal Mobile

32



Giang Kỳ Nam

Telecommunication System), thẻ thông minh lưu định danh người dùng riêng

và có ít nhất một định danh người dùng công cộng. HSS là một cơ sở dữ liệu

chung cho mọi dữ liệu liên quan đến thuê bao, chứa định danh người dùng

riêng và một tập hợp các định danh người dùng công cộng được gán cho

người dùng. HSS và S-CSCF cũng có tương quan với định danh người dùng

cộng và định danh người dùng riêng. Mối quan hệ giữa một thuê bao, định

danh người dùng riêng và một số định danh người dùng công cộng được thể

hiện như trong hình 2-5. Đây là trường hợp của IMS như chuẩn hóa trong

3GPP Release 5.

Hình 2-5 : Quan hệ giữa định danh người dùng riêng và định danh

người dùng công cộng theo 3GPP R5

3GPP Release 6 mở rộng mối quan hệ giữa định danh người dùng riêng và

định danh người dùng chung như ở hình 2-6 dưới đây. Một thuê bao IMS

được cấp không chỉ một mà là một số định danh người dùng riêng. Trong

trường hợp UMTS, chỉ một định danh người dùng riêng được lưu trữ trong

thẻ thông minh, nhưng người dùng có thể có nhiều thẻ thông minh khác nhau

mà họ có thể cho vào đầu cuối IMS. Có thể các định danh người dùng công

cộng này được sử dụng kết hợp với nhiều hơn một dịnh danh người dùng

riêng. Đó là trường hợp của định danh người dùng công cộng số 2 trong hình

33



Giang Kỳ Nam

2-6, bởi vì nó được gán cho cả định danh người dùng riêng số 1 và số 2. Điều

này cho phép định danh người dùng công cộng số 2 có thể sử dụng đồng thời

từ hai đầu cuối IMS, mỗi một thiết bị được gán một định danh người dùng

riêng khác nhau (ví dụ như các thẻ thông minh khác nhau được gắn vào các

đầu cuối khác nhau).

Hình 2-6 : Quan hệ giữa định danh người dùng riêng và định danh

người dùng công cộng theo 3GPP R6

2.2.4 Định danh dịch vụ công cộng

2.2.4.1 Định nghĩa PSI

Khái niệm của định danh dịch vụ công cộng (PSI – Public Service

Identities) được giới thiệu trong 3GPP Release 6. Không giống như định

danh người dùng công cộng, một PSI là một định danh được cấp phát cho

dịch vụ trên máy chủ ứng dụng (AS – Application Server). Ví dụ, một máy

chủ ứng dụng phục vụ một chatroom được định danh bởi PSI. Giống như

định danh người dùng công cộng, PSI có thể có dạng SIP URI hoặc TEL

URI.

34



Giang Kỳ Nam

Không giống định danh người dùng công cộng, PSI không liên quan đến

định danh người dùng riêng. Sở dĩ như vậy là do định danh người dùng

riêng chỉ sử dụng dành cho mục đích nhận thực. PSI không được áp dụng

cho người dùng.

2.2.4.2 Phân loại PSI

PSI được chứa trong HSS dưới dạng hoặc là PSI đặc trưng hoặc là

Wildcarded PSI. Một PSI đặc trưng (Distinct PSI) có chứa PSI được sử

dụng trong quá trình định tuyến. Trong khi Wildcarded PSI là một tập hợp

các PSI. Wildcarded PSI cho phép người dùng tối ưu hoạt động và duy trì

các nút. Một Wildcarded PSI có chứa hơn hai dấu chấm than sẽ được xem

như một cặp dấu ngăn cách.

Khi được chứa trong HSS, Wildcarded PSI sẽ bao gồm các ký tự ngăn cách

để xác định phần mở rộng của PSI.

Ví dụ: PSI sau có thể chứa trong HSS “sip:chatlist!.*[email protected]”.

Ví dụ các PSI sau giao tiếp trên giao diện bản tin với HSS sẽ được đổi

thành “sip:chatlist!.*[email protected]”. Khi chứa trong HSS:

sip:[email protected]





2.3 SIM, USIM và ISIM trong 3GPPUICC (Universal Integrated Circuit Card) là trung tâm trong thiết kế thiết bị

đầu cuối 3GPP. UICC là một thẻ thông minh có thể tháo lắp và mang theo

người một cách rất đơn giản, UICC lưu trữ một số dữ liệu như thông tin đăng

35



Giang Kỳ Nam

ký thuê bao, mã nhận thực, sổ địa chỉ và các tin nhắn. Nếu không có UICC thì

thiết bị đầu cuối chỉ có thể gọi các số khẩn cấp.

UICC cho phép người dùng di chuyển dễ dàng thông tin thuê bao của họ sang

thiết bị mới bằng cách lắp thẻ thông minh sang thiết bị đó. UICC là một khái

niệm chung định nghĩa các đặc tính của thẻ thông minh.

UICC có thể bao gồm một vài ứng dụng logic như SIM (Subscriber Identity

Module), USIM (Universal Subscriber Identity Module) và ISIM (IP

multimedia Services Identity Module). Thêm vào đó, UICC còn có thể chứa

các ứng dụng khác như danh bạ điện thoại.

2.3.1 SIM

SIM lưu trữ một tập hợp các tham số như thông tin đăng ký người dùng, mã

nhận thực và các tin nhắn. SIM là thành phần cơ bản nhất trong các thiết bị

đầu cuối để người dùng có thể hòa mạng. Mặc dù khái niệm UICC và SIM là

có thể thay đổi cho nhau, UICC được xem như một thẻ vật lý, trong khi đó

SIM được xem như một ứng dụng đơn lẻ nằm trong UICC. SIM được sử

dụng rộng rãi trong các mạng di động thế hệ thứ hai, như mạng GSM.

2.3.2 USIM

USIM là một ứng dụng khác nằm trong UICC. USIM cung cấp một tập hợp

các tham số bao gồm thông tin đăng ký thuê bao, thông tin nhận thực,

phương pháp thanh toán và lưu trữ tin nhắn. USIM được sử dụng để truy

nhập mạng UMTS.

Các thiết bị đầu cuối trong mạng chuyển mạch gói và chuyển mạch kênh cần

phải có USIM để hoạt động được trong mạng di động thế hệ thứ ba. Rõ ràng,

cả SIM và USIM có thể cùng tồn tại đồng thời trong UICC để thiết bị đầu

cuối có thể sử dụng đồng thời mạng GSM và UMTS.

2.3.3 ISIM

36



Giang Kỳ Nam

Một ứng dụng thứ ba có thể hiện diện trong UICC là ISIM. ISIM có vai trò

đặc biệt quan trọng trong IMS, bởi vì ISIM có chứa một tập hợp các thông số

được sử dụng làm chứng thực người dùng, nhận dạng người dùng, cấu hình

thiết bị đầu cuối hoạt động trong mạng IMS. ISIM có thể tồn tại cùng SIM,

USIM hoặc tất cả các ứng dụng trong cùng UICC.

2.4 Tiêu chuẩn lọcTiêu chuẩn lọc là một trong những thành phần quan trọng nhất của thông tin

người dùng được lưu trữ trên mạng vì chúng xác định loại dịch vụ nào sẽ cung

cấp cho người sử dụng. Tiêu chuẩn lọc bao gồm một tập hợp thông tin liên

quan đến người dùng giúp cho S-CSCF quyết định khi nào gọi máy chủ ứng

dụng cung cấp dịch vụ.

Theo tiêu chuẩn 3GPP TS 23.218 [20] có hai tiêu chuẩn lọc là: tiêu chuẩn lọc

khởi tạo (IFC – Initial Filter Criteria) và tiêu chuẩn lọc kế tiếp (SFC –

Subsequent Filter Criteria). Tuy nhiên chỉ có tiêu chuẩn lọc khởi tạo IFC là

được sử dụng. Tiêu chuẩn lọc kế tiếp SFC vẫn còn nằm trên lý thuyết, do nếu

áp dụng tiêu chuẩn lọc kế tiếp SFC tại S-CSCF có thể sẽ gây ra xung đột với

quy tắc định tuyến bản tin SIP cho các proxy.

Tiêu chuẩn lọc khởi tạo IFC có nhiệm vụ đánh giá các yêu cầu khởi tạo SIP và

tạo ra các yêu cầu đơn. Ví dụ, S-CSCF đánh giá tiêu chuẩn lọc khởi tạo khi

nhạn được yêu cầu SUBSCRIBE đầu tiên, INVITE, OPTIONS, hoặc bất cứ

yêu cầu nào tạo ra cuộc hội thoại hoặc được gửi ngoài các hộp thoại. S-CSCF

không đánh giá tiêu chuẩn lọc khởi tạo khi nhận được yêu cầu PRACK,

NOTIFY, UPDATE, hoặc BYE do chúng luôn luôn được gửi như một phần

của một hội thoại SIP đang tồn tại.

Khái niệm tiêu chuẩn lọc kế tiếp là S-CSCF sẽ đánh giá tiêu chuẩn lọc kế tiếp

khi nó nhận được yêu cầu kế tiếp trong hộp thoại SIP. Tuy nhiên, kết quả của

việc đánh giá tiêu chuẩn lọc kế tiếp có thể dẫn đến việc S-CSCF chuyển tiếp

37



Giang Kỳ Nam

yêu cầu SIP kế tiếp đến một máy chủ ứng dụng, điều này trái ngược với thủ

tục định tuyến cho yêu cầu kế tiếp ở trong một SIP proxy. Hơn nữa, trong sự

kiện một máy chủ ứng dụng nhận được yêu cầu kế tiếp này, khi đó máy chủ

ứng dụng vẫn chưa nhận được yêu cầu khởi tạo SIP để tạo hộp thoại SIP. Do

đó, máy chủ ứng dụng sẽ hủy yêu cầu và bỏ qua yêu cầu kế tiếp đó. Từ đó dẫn

đến việc không sử dụng tiêu chuẩn lọc kế tiếp.

Tiêu chuẩn lọc duy nhất được triển khai là tiêu chuẩn lọc khởi tạo. Do tiêu

chuẩn lọc kế tiếp không tồn tại nên thuật ngữ tiêu chuẩn lọc khởi tạo và tiêu

chuẩn lọc là như nhau.

HSS lưu giữ tất cả dữ liệu liên quan tới người dùng trong một cấu trúc dữ liệu

tên là User Profile. Hình 2-7 mô tả cấu trúc đơn giản cấp cao của user profile.

User Profile chứa định danh riêng thuê bao mà user profile đó thuộc về và một

hay nhiều service profile. Mỗi một service profile chứa một hay nhiều định

danh công cộng thuê bao mà service profile đó thuộc về và không có hoặc

nhiều tiêu chuẩn lọc.

38



Giang Kỳ Nam

Hình 2-7 : Cấu trúc của User Profile

Khi người dùng đăng ký với S-CSCF, S-CSCF liên lạc với HSS và tải user

profile có chứa tiêu chuẩn lọc. Vậy tiêu chuẩn lọc vẫn tồn tại trong S-SCSF tại

thời điểm người dùng đăng ký.

39



Giang Kỳ Nam

Tiêu chuẩn lọc xác định các dịch vụ mà nó có thể áp dụng được để thu thập

định danh công cộng thuê bao liệt kê trong “Service profile”. Cấu trúc dữ liệu

của tiêu chuẩn lọc được thể hiện ở hình 2-8.

Hình 2-8 : Cấu trúc tiêu chuẩn lọc khởi tạo

40



Giang Kỳ Nam

Trường đầu tiên trong cấu trúc tiêu chuẩn lọc là Priority. Trường Priority xác

định thứ tự của tiêu chuẩn lọc sẽ được đánh giá so với các tiêu chuẩn lọc còn

lại trong cùng một “service profile”. S-SCSF trước tiên sẽ chọn tiêu chuẩn lọc

có độ ưu tiên cao, ví dụ độ ưu tiên 1 là độ ưu tiên cao nhất. Sau khi thực thi

nó, S-SCSF tiếp tục với tiêu chuẩn lọc tiếp theo có độ ưu tiên nhỏ hơn.

Trường Priority của tiêu chuẩn lọc là số duy nhất đối với các tiêu chuẩn lọc

trong cùng một “service profile”. Trong một số trường hợp, số ưu tiên không

cần thiết phải liền nhau.

Sau trường Priority, có thể không có hoặc có một Trigger Point (điểm kích

hoạt). Một Trigger Point là một biểu thức cần được đánh giá để xác định xem

yêu cầu SIP có được chuyển tiếp đến máy chủ ứng dụng hay không. Một điểm

kích hoạt là tập hợp các bộ lọc riêng biệt được gọi là “Service Point Triggers”.

Ví dụ, một Trigger Point có thể như sau:

(Method = INVITE) AND (Request-URI = sip:[email protected])

Trong ví dụ này có hai Service Point Trigger là Method = INVITE và

Request-URI = sip:[email protected].

Sevice Point Trigger cho phép ta truy nhập thông tin được lưu trữ chứa trong

các trường khác nhau của yêu cầu SIP.

• Giá trị của Request-URI.

• Phương thức của yêu cầu SIP (ví dụ: INVITE, OPTIONS,

SUBSCRIBE,…).

• Sự có mặt hay vắng mặt của bất cứ trường điều khiển SIP (SIP header)

nào.

• Trùng một phần hay toàn bộ nội dung của bất kỳ trường điều khiển SIP

nào.

41



Giang Kỳ Nam

• Trường hợp phiên (ví dụ, yêu cầu SIP có nguồn là một thuê bao được

phục vụ gửi đến thuê bao đã đăng ký, hoặc gửi đến thuê bao chưa đăng

ký).

• Mô tả phiên (ví dụ, trùng một phần hay toàn bộ bất kể một dòng SDP

nào).

Nếu không có Trigger Point thì các yêu cầu SIP được chuyển tiếp đến máy

chủ ứng dụng vô điều kiện.

Sau Trigger Points chứa một hay nhiều Service Point Triggers, tiêu chuẩn lọc

khởi tạo chứa AS SIP URI. Đây là địa chỉ của máy chủ ứng dụng sẽ nhận yêu

cầu SIP nếu các điều kiện được mô tả trong các Trigger Point được thỏa mãn.

Trường Default Handling chỉ hành động sẽ xảy ra nếu S-CSCF với lý do nào

đó không thể liên lạc được với máy chủ ứng dụng. Các hành động có thể tiếp

tục xử lý yêu cầu SIP hoặc ngừng xử lý.

Trường Service Information chứa dữ liệu trong suốt (ví dụ, trong suốt với HSS

và S-CSCF) mà máy chủ ứng dụng có thể cần để xử lý yêu cầu. Cách sử dụng

trường này được giới hạn với các yêu cầu SIP REGISTER hoặc bất kỳ yêu cầu

nào khác khi mà S-CSCF hoạt động như là một SIP User Agent Client.

Nguyên nhân là do các dữ liệu được thêm vào phần thân của yêu cầu SIP.

Hành động này không được chấp nhận trong các SIP Proxy. Vì vậy, trường

hợp duy nhất sử dụng thông tin này là khi S-CSCF, tùy theo tiêu chuẩn lọc

khởi tạo, hoạt động như một “SIP User Agent Client” tạo ra yêu cầu SIP

REGISTER ở bên thứ ba tới máy chủ ứng dụng. Yêu cầu REGISTER đó có

thể chứa Service Information (trong trường hợp máy chủ ứng dụng cần nó),

với mục đích là truyền IMSI tới IM-SSF của thuê bao, vì IMSI có thể được sử

dụng bởi IM-SSF.

Cuối cùng, user profile được mã hóa sử dụng ngôn ngữ đánh dấu mở rộng

XML (Extensible Markup Language). Mẫu XML định nghĩa tiêu chuẩn lọc

42



Giang Kỳ Nam

khởi tạo được mô tả trong 3GPP TS 29.228 [21]. Tiêu chuẩn lọc khởi tạo được

truyền từ HSS đến S-SCSF thông qua bản tin Diameter.

2.5 Triển khai kiến trúc IMSKiến trúc IMS được triển khai trong đề tài:

Hình 2-9 : Sơ đồ các khối chức năng trong kiến trúc IMS

Bao gồm các khối chức năng:

• Máy chủ ứng dụng:

o Cung cấp giao diện web cho người dùng thực hiện các dịch vụ

trên nền IMS.

o Giao tiếp với các module AD/DB để xác thực dịch vụ.

43



Giang Kỳ Nam

o Phát triển các dịch vụ Iptv, conferencing, presence,… dựa trên

SIP Servlet.

• Media server:

o Thực hiện các chức năng xử lý dữ liệu đa phương tiện (MSF và

MRF tương ứng trong kiến trúc IMS).

o IS-ME sẽ thực hiện những công việc sau:

Playing các file thông báo (audio/video).

Hội thoại đa phương tiện.

Chuyển mã (transcoding) các loại dữ liệu đa phương tiện.

Tương lai sẽ thực hiện Text to Speak.

Thực hiện các dịch vụ điều khiển cuộc gọi (từ IS-CC).

• User client:

o Cung cấp một phương tiện liên lạc đa phương tiện bằng giao

thức SIP trên nền IP.

o Hỗ trợ kiểu dữ liệu đa phương tiện.

o Chạy trên PC, tương lai là trên điện thoại di động và các thiết bị

cầm tay (sử dụng hệ điều hành linux hoặc symbian).

o Cung cấp các dịch vụ chính: gọi điện, xem video (dạng

streaming),…

o Instant messaging,…

• AD/DB:

44



Giang Kỳ Nam

o Thực hiện các tác vụ quản lý các thành phần của hệ thống và

quan trọng hơn là thực hiện các chức năng tính cước và xác thực

dịch vụ.

o Thông tin về người dùng được chứa trong cơ sở dữ liệu mySQL

giúp xác thực dịch vụ và xác thực người dùng.

o Giao tiếp với module AS cung cấp các thông tin xử lý dịch vụ.

45



Giang Kỳ Nam

3 CHƯƠNG III : CÁC GIAO THỨC QUAN

TRỌNG

Trong chương này, chúng ta sẽ đề cập đến 3 giao thức quan trọng sử dụng

chủ yếu trong đồ án, đó là giao thức mô tả phiên – SDP, giao thức khởi tạo

phiên – SIP và giao thức nhận thực cấp quyền tính toán – Diameter.

3.1 Giao thức SDP

3.1.1 Mô tả phiên

Một mô tả phiên là một mô tả bao gồm những thông tin cần thiết cho các

người dùng ở xa có thể tham gia vào phiên đó. Trong các phiên đa phương

tiện trên internet, những thông tin này bao gồm địa chỉ IP và tên cổng để gửi

đi và các bộ mã hóa – giải mã dùng để mã hóa voice và hình ảnh cần gửi của

người tham gia. Những mô tả về phiên có những định dạng riêng. Định dạng

hay dùng nhất là giao thức mô tả phiên SDP (Session Description Protocol),

được định nghĩa trong RFC 2327 [115]. SDP đơn giản là một định dạng văn

bản miêu tả các phiên multimedia. Hình 3-1 là một ví dụ minh họa mô tả

phiên giữa Alice và Bob. SDP chứa thông tin về địa chỉ IP, số cổng mà Alice

muốn nhận audio (20000) và nhận video (20002), các bộ mã hóa giải mã

audio và video mà Alice hỗ trợ (0 tương ứng với luật mã hóa audio μ G.711

và 31 tương ứng với bộ mã hóa H.261) và thông tin về chủ đề của cuộc hội

thoại.

46



Giang Kỳ Nam

Hình 3-10 : Một ví dụ về mô tả phiên SDP

Như ta đã thấy ở hình trên, một mô tả SDP bao gồm hai phần thông tin về

phiên và thông tin về media. Thông tin về phiên trải toàn bộ phiên và xuất

hiện trước dòng “m=”. Năm dòng đầu tiên tương ứng với thông tin về phiên.

Chúng cung cấp những thông tin về nhận dạng người dùng (v= và o=), chủ

đề của phiên (s=), địa chỉ của Alice (c=) và thời gian của phiên (t=).

Thông tin về media là luồng media cụ thể bao gồm dòng “m=” và một số lựa

chọn “a=” cung cấp thông tin về luồng media. Trong ví dụ hình 3-1 có hai

dòng media và vì vậy có hai dòng “m=”. Dòng “a=” chỉ ra luồng media ở

đây là hai chiều (các user gửi và nhận media).

Như minh họa trên hình 3-1, định dạng của tất cả các dòng SDP bao gồm

dạng “kiểu = giá trị”, “kiểu” là một chữ cái. Hình 3-2 chỉ ra các “kiểu” trong

SDP. Mặc dù SDP là một định dạng phổ biến miêu tả các phiên đa phương

tiện nhưng SIP không phụ thuộc vào SDP. SIP là một dạng độc lập với việc

mô tả phiên tức là SIP có thể đưa ra một mô tả phiên dùng SDP hay là bất kỳ

một dạng khác.

47



Giang Kỳ Nam

Hình 3-11 : Các kiểu trong SDP

3.1.2 Mô hình Offer/Answer

Trong ví dụ về SDP ở hình 3-1, Alice gửi một mô tả phiên đến Bob có chứa

địa chỉ của Alice (bao gồm địa chỉ IP và số hiệu cổng). Tất nhiên như thế là

chưa đủ để thiết lập một phiên giữa hai người. Alice cũng cần phải biết địa

chỉ tương ứng của Bob. SIP cung cấp phương thức trao đổi mô tả phiên giữa

hai người gọi là mô hình offer/answer (được mô tả trong RFC 3264 [212]).

Một trong hai người dùng (offerer) tạo ra một mô tả phiên (offer) và gửi nó

tới một người dùng khác (answerer) tạo ra một mô tả phiên mới (answer) để

gửi tới offerer. RFC 3264 [212] đưa ra những quy định về phương cách tạo

ra offer và anser. Sau khi trao đổi offer/answer cả hai người sẽ có những

thông tin về phiên được thiết lập. Họ sẽ biết định dạng cần sử dụng và địa chỉ

để truyền tải cho phiên đó. Trao đổi offer/answer cũng có thể cung cấp

những thông tin khác như mã và giải mã…

48



Giang Kỳ Nam

Hình 3-3 minh họa việc Bob gửi lại cho Alice sau khi nhận được một offer

của Alice.

Hình 3-12 : Mô tả phiên SDP của Bob

Địa chỉ của Bob là 192.0.0.2, số cổng nơi Bob nhận audio là 30000, số cổng

nơi Bob nhận video là 30002 và Bob cũng dùng bộ mã hóa – giải mã giống

Alice (G.711 μ-law và H.261). Sau khi trao đổi offer/answer cả hai có thể

trao đổi về audio và video cho nhau.

3.1.3 SIP và SIPS URIs

SIP nhận dạng người dùng bằng SIP URI tương tự như địa chỉ của một

email, SIP URI bao gồm tên và một tên miền. Thêm vào đó, SIP URI có thể

chứa một số các thông số được phân cách bởi các dấu chấm phẩy.

Ví dụ về SIP URIs:



sip:[email protected];transport=tcp

Thêm vào đó, người dùng có thể được nhận ra bằng SIP URI. Các thực thể

giao tiếp với SIPS RIs dùng TLS (Transport Layer Security) để bảo mật các

bản tin của người dùng.

Ví dụ về SIPS URIs:

49



Giang Kỳ Nam

sips:[email protected]

sips:[email protected]

3.1.4 Định vị người dùng

Mục đính chính của SIP là đưa ra một mô tả phiên tới người dùng ở vị trí

hiện tại của họ, và chúng ta đã thấy định dạng của một mô tả phiên. Bây giờ

chúng ta xem xét SIP nhận ra vị trí của người dùng như thế nào.

SIP cung cấp tính linh động cá nhân tức là một người dùng sẽ có nhận dạng

như nhau bất kể người đó đang ở đâu. Ví dụ, Alice được nhận dạng bởi SIP

URI tại


bất kể Alice đang ở đâu, đây là URI công cộng của Alice hay còn được gọi là

AoR (Address of Record).

Tuy nhiên, khi Alice đăng nhập tại nơi làm việc, địa chỉ SIP URI của cô ấy là


và khi Alice làm việc tại trường đại học thì địa chỉ SIP URI là


Bởi vậy, chúng ta cần phải có phương pháp ánh xạ tới địa chỉ công cộng của

Alice


tới các địa chỉ URI hiện thời của cô ấy (tại nơi làm việc hoặc tại trường đại

học).

Để làm được điều này, SIP đưa ra một thành phần mạng gọi là registrar của

một domain. Registrar quản lý các yêu cầu được gửi tới một domain. Vì vậy

yêu cầu gửi tới sip:[email protected] sẽ được quản lý bởi SIP

registrar tại domain.com.50



Giang Kỳ Nam

Bất cứ lúc nào Alice đăng nhập tại một khu vực mới, Alice sẽ đăng ký vị trí

mới đó tại domain.com như được chỉ ra trên hình 3-4.

Hình 3-13 : Alice đăng ký vị trí người dùng với tên miền domain.com registrar

Khi tiếp nhận đăng ký registrar tại domain.com sẽ lưu trữ cơ chế ánh xạ giữa

URI công cộng của Alice và vị trí hiện tại của cô ấy theo hai cách: nó có thể

dùng cơ sở dữ liệu hoặc có thể tải lên cơ chế ánh xạ này tới máy chủ vị trí.

Nếu registrar dùng máy chủ vị trí thì nó cần tra cứu khi nó nhận được yêu

cầu của Alice. Chú ý rằng giao diện giữa registrar và máy chủ vị trí không

dùng SIP mà dùng các giao thức khác.

3.2 Giao thức DiameterDiameter là 1 giao thức dùng cho mục đích xác thực người dùng, cấp quyền

và tính toán (AAA). Diameter là giao thức tiếp sau của RADIUS

Giao thức Diameter cơ bản được định nghĩa trong RFC 3588, định nghĩa

những yêu cầu tối thiểu dùng cho mục đích AAA. Các ứng dụng Diameter có

thể mở rộng giao thức diameter cơ bản bằng cách thêm vào nhiều thuộc tính

cũng như các lệnh. Diameter được truyền bảo mật bằng ipsec hoặc tls, tổ

chức IANA gán cho Diameter/TCP hay SCTP cổng 3868.

51



Giang Kỳ Nam

3.2.1 Gói tin Diameter

Cấu trúc:

HÌnh 3-14: Cấu trúc gói tin Diameter

Các command được quan tâm trong đề tài:

Bảng 3-1: Diameter commands

Command-Name Abbr. Code Capabilities-Exchange-Request CER 257Capabilities-Exchange-Answer CEA 257Device-Watchdog-Request DWR 280Device-Watchdog-Answer DWA 280Disconnect-Peer-Request DPR 282Disconnect-Peer-Answer DPA 282User-Data-Request UDR 306User-Data-Answer UDA 306Profile-Update-Request PUR 307Profile-Update-Answer PUA 307

Attribute-Value Pairs (AVPs)

52



Giang Kỳ Nam

HÌnh 3-15: Cấu trúc AVP trong gói tin Diameter

Bit ‘V’ chỉ định sự có mặt của trường Vendor-ID trong AVP header. Bit ‘M’ chỉ định AVP này là bắt buộc phải có.Bit ‘P’ chỉ ra AVP này có được mã hóa đảm bảo cho bảo mật thông tin giữa các đầu cuối hay ko.

Các AVP được quan tâm đến trong đề tài:

Bảng 3-2: Diameter AVPs

Attribute-Name Code Data TypeDestination-Host 293 DiamIdentDestination-Realm 283 DiamIdentExperimental-Result 297 GroupedExperimental-Result-Code 298 Unsigned32Host-IP-Address 257 AddressOrigin-Host 264 DiamIdentOrigin-Realm 296 DiamIdentHost-IP-Address 257 AddressUser-Name 1 UTF8StringVendor-Id 266 Unsigned32Vendor-Specific-Application-Id 260 GroupedSupported-Vendor-Id 265 Unsigned32

3.2.2 Phiên giao dịchLuồng bản tin:

53



Giang Kỳ Nam

HÌnh 3-16: Diameter transaction

Giao tiếp giữa 2 đầu cuối diameter bắt đầu bằng bản tin capabilities-

Exchange-Request (CER) từ 1 peer này sang 1 peer khác, bản tin này được

trả lời bằng 1 bản tin diameter Capabilities-Exchange-Answer (CEA). Mục

đích của 2 bản tin này là để 2 diameter peer biết được các thông số của nhau

thuận tiện cho việc trao đổi thông tin 2 chiều.

Sau khi nhận được CEA, 2 diameter peer đã có thể giao tiếp với nhau.

Nếu không có bản tin nào được chuyển qua lại giữa 2 peer thì chúng sẽ gửi

các bản tin Device-Watchdog-Request (DWR) và peer kia trả lời bằng 1 bản

tin Device-Watchdog-Answer (DWA) để 2 peer biết được sự tồn tại của

nhau.

54



Giang Kỳ Nam

1 trong 2 peer có thể kết thúc phiên giao tiếp bởi bản tin Disconnect-Peer-

Request (DPR) và được trả lại bằng 1 bản tin Disconnect-Peer-Answer

(DPA). Sau thủ tục này 2 peers coi như chấm dứt giao dịch và sẽ bắt đầu lại

(nếu cần) bằng bản tin CER

3.2.3 Triển khai giao thức trong đề tài

Application server cung cấp logic dịch vụ sử dụng thư viện JDiameter để xử

lý các bản tin Diameter. Trong đề tài sử dụng 1 implementation của giao

thức Diameter (1 ứng dụng diameter) trên giao diện Sh giữa AS và HSS.

Dịch vụ IPTV – Parental control sử dụng 3 thông tin của user có trong cơ sở

dữ liệu của HSS:

• Thông tin về trạng thái người dùng (Registered, un-registered, not-

registered, authentication pending) – dùng trong trường hợp cần gửi tin

nhắn cho reference user, phải xác định được user đó có đang online hay

không.

• Thông tin về dịch vụ mà 1 user đã đăng ký – để biết được user có đăng

ký dịch vụ IPTv hay không hoặc đăng ký IPTv hay là Parental Control

• Thông tin thêm chi tiết về dịch vụ đó, các ràng buộc, yêu cầu của dịch vụ

- ví dụ như khoảng thời gian 1 user được phép xem 1 phân loại kênh nhất

định.

Các thông tin này được AS download về từ HSS thông qua giao diện Sh

bằng cách gửi bản tin User-Data-Request (UDR) và nhận về bản tin User-

Data-Answer (UDA)với các AVPs: User-Identity, Data-Refenrence, User-

Data, Vendor-Specific-Application-Id, Supported-Vendor-Id.

Để có thể thiết lập logic dịch vụ cho 1 user, AS sử dụng bản tin Profile-

Update-Request (PUR) để update repository data của user trên HSS vd như

55



Giang Kỳ Nam

đối với dịch vụ Parental Control thì là thông tin về reference user, về giới

hạn thời gian và loại kênh được phép truy cập.

Bản tin thứ nhất được đề cập đến là bản tin UDR – User Data

Request: hay còn gọi là Sh Pull, là bản tin do Application server gửi

đến HSS để truy vấn thông tin người dùng. Trong bản tin này có các

AVP:

o USER_IDENTITY code = 700 bao gồm

o PUBLIC_IDENTITY code = 601 value = “sip:[email protected]”

o SERVER_NAME code = 602 value =

“sip:IPTV_SERVER_IP:PORT”

o DATA_REFERENCE code = 703 value = 13 IFC hoặc value = 0

REPOSITORY_DATA hoặc value = 11 IMS_USER_STATE

o SERVICE_INDICATION code = 704 value = “iptv” nếu data

reference là repository data.

Bản tin UDR đầu tiên được gửi truy vấn iFC của người dùng, sẽ lấy được các

thông tin cơ bản của người dùng trong mạng IMS.

Bản tin UDR thứ 2 được gửi truy vấn Repository data của người dùng, đây là

dữ liệu lưu trên HSS cho từng dịch vụ riêng biệt, là dữ liệu của máy chủ ứng

dụng áp dụng cho từng người dùng trong mạng IMS.

Ví dụ về 1 IFC của người dùng:

56



Giang Kỳ Nam

HÌnh 3-17: IFC của người dùng tải về từ HSS

Ví dụ về Repository data của người dùng:

57



Giang Kỳ Nam

HÌnh 3-18: Repository data của 1 người dùng IPTV

Bản tin thứ 2 được đề cập đến là bản tin PUR: Profile Update

Request: hay còn gọi là Sh – push, là bản tin do Application server

gửi đến HSS nhằm cập nhật thông tin người dùng lưu giữ trong HSS.

Trong đề tài sử dụng bản tin PUR để cập nhật Repository data của

dịch vụ IPTV cho từng user. Trong bản tin này có các AVP:

o USER_IDENTITY, PUBLIC_IDENTITY,

DATA_REFERENCE như trên

58



Giang Kỳ Nam

o USER_DATA code = 702.

3.3 Giao thức SIPSIP 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.

59



Giang Kỳ Nam

Hình 3-19 : Các bước thiết lập một cuộc gọi

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 (3rd

Generation Partnership Project) và như là một thành phần không thể thiếu

trong kiến trúc IMS.

3.3.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 với HTTP, điều

đó có nghĩa là nó hoạt động ở tầng ứng dụng và sử dụng các giao thức TCP,

60



Giang Kỳ Nam

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.

• OPTIONS: sử dụng để truy vấn máy chủ về khả năng của nó.

61



Giang Kỳ Nam

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).

3.3.2 Bản tin SIP

Cấu trúc của bản tin SIP:

62



Giang Kỳ Nam

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.

3.3.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.

63



Giang Kỳ Nam

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 200

OK 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)

trong bản tin đó và so sánh với tất cả các identifier trong transaction mà nó

lưu trữ. Nếu như một transaction tồn tại thì trạng thái của nó sẽ được cập

nhật từ bản tin đó.

64



Giang Kỳ Nam

Hình 3-21 : Transaction

3.3.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. Chỉ số Cseq

phải được tăng tuần tự từng đơn vị cho mỗi bản tin trong một dialog, nếu

65

http://www.iptel.org/sip_transaction



Giang Kỳ Nam

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.

66

http://www.iptel.org/sip_dialog



Giang Kỳ Nam

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 đó.

3.3.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.

67



Giang Kỳ Nam

Hình 3-23 : Cách sử dụng Record-Route, Route và Contact

68



Giang Kỳ Nam

4 CHƯƠNG IV : 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.

4.1 Tổng quan về máy chủ ứng dụngTrong 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.

4.2 Chức năng của máy chủ ứng dụng trong mô hình IMSCầ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

túy, mà hơn thế nó hoạt động ở lớp trên cùng trong kiến trúc phân tầng IMS.

69



Giang Kỳ Nam

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ủ ứng dụng có thể

70



Giang Kỳ Nam

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.

4.3 Các chế độ hoạt động của máy chủ ứng dụngA 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.

4.3.1 AS hoạt động như SIP User Agent

Thiết bị đầu cuối gửi một bản Request INVITE tới Originating P-CSCF và

originating S-CSCF. S-CSCF quyết định chuyển tiếp bản tin tới một AS. AS

71



Giang Kỳ Nam

này hoạt động như một SIP User Agent (SIP UA) và trả lời bằng bản tin 200

OK đượ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.

1.INVITE 2.INVITE

3.IN

VIT

E

4. 2

00 O

K

5. 200 OK6. 200 OK

IMSHome

Network

AS

P-CSCF S-CSCF

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).

4.3.2 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.

72



Giang Kỳ Nam

Service-specific logic

Request A

Response B

Request B

Response B

SIP UserAgent

SIP UserAgent

Hình 4-26 : Kiến trúc logic của SIP 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.

4.3.3 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.

73



Giang Kỳ Nam

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.

Hình 4-28 : AS đóng vai trò SIP Proxy AS

4.3.4 AS đóng vai trò như là SIP Redirect Server

Hình 4-29 : AS đóng vai trò SIP Redirect Server74



Giang Kỳ Nam

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.

4.4 Giao diện AS với các thành phần khác trong mạng

4.4.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.

Các thủ tục của giao diện ISC có thể chia làm hai phần:

75



Giang Kỳ Nam

• 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.

4.4.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. 76



Giang Kỳ Nam

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.

77



Giang Kỳ Nam

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.

78



Giang Kỳ Nam

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ụ

79



Giang Kỳ Nam

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).

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 máy chủ

ứng dụng, sử dụng cho HSS

kiểm tra lại trong danh sách

cho phép của nó (AS

permision 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

80



Giang Kỳ Nam

4.5 Quá trình cung cấp dịch vụ

4.5.1 Giới thiệu

Quá trình cung cấp dịch vụ của kiến trúc IMS bao gồm ba bước cơ bản:

• Định nghĩa các dịch vụ hoặc tập dịch vụ có thể.

• Tạo ra các dữ liệu dịch vụ của người dùng dưới dạng tiêu chuẩn lọc

khởi tạo để người dùng có thể sắp xếp hay thay đổi các đăng ký.

• Chuyển tiếp các yêu cầu khởi tạo đến máy chủ ứng dụng.

4.5.2 Sự hình thành tiêu chuẩn lọc khởi tạo

Trong trường hợp thuê bao đăng ký sử dụng IMS, bản tin đăng ký của họ có

thể có các nội dung liên quan đến dịch vụ gia tăng cũng như trường hợp nhà

cung cấp muốn có máy chủ ứng dụng ở trong kiến trúc IMS của mình, thì họ

cần tạo ra các dữ liệu về dịch vụ của thuê bao. Cụ thể hơn là dữ liệu tiêu

chuẩn lọc khởi tạo đã được đề cập đến ở mục 2.6. Khi xây dựng tiêu chuẩn

lọc khởi tạo nhà cung cấp cần phải trả lời các câu hỏi:

• Điểm kích hoạt là gì?

• Máy chủ ứng dụng được chọn khi gặp điểm kích hoạt là?

• Thứ tự ưu tiên của các tiêu chuẩn lọc khởi tạo?

• Phải xử lý như thế nào nếu máy chủ ứng dụng không trả lời?

Điểm kích hoạt là lúc máy chủ ứng dụng được gọi. Điểm kích hoạt có thể

chứa nhiều các thực thể “service point trigger”. Service point trigger (SPT)

bao gồm các thành phần như sau:

81



Giang Kỳ Nam

SIP Header

Header: string Content: string

Service Point Trigger

ConditionNegated: boolean Group: list of integer RegistrationType: list of enumerated

SIP Method

Method: string

Session Description

Line: string Content: string

Session Case

SessionCase: enumerated

Request-URI

RequestURI: string

Hình 4-31 : Thành phần của Service Point Trigger

Như trên hình 4-8, các thành phần SPT có chức năng cụ thể như sau:

• Request-URI: xác định tài nguyên mà yêu cầu được hướng đến (ví dụ:

[email protected]). Request-URI chứa thuộc tính RequestURI của

bản tin SIP cần xác nhận.

• SIP Method: dùng để kiểm tra phương thức yêu cầu nào của bản tin

SIP (có thể là REGISTER, INVITE, PUBLISH, SUBSCRIBE,

MESSAGE,…).

• SIP Header: chứa thông tin liên quan đến yêu cầu. SPT có thể dựa

trên sự có mặt hay vắng mặt của một SIP Header nào đó với giá trị

Header là tên của Header cần xét và giá trị Content là nội dung của

header đó. Giá trị của Content được sử dụng như một mẫu để kiểm

tra.

• Session Case: dùng để xác định chiều của bản tin là khởi tạo

(originating) hay kết thúc (terminating) trong trường hợp người dùng

có đăng ký (registered) hoặc chưa đăng ký (unregistered). Nói cách

khác, trường này được sử dụng bởi S-CSCF để xử lý dịch vụ cho phía 82



Giang Kỳ Nam

nguồn, dịch vụ cho phía đích hay dịch vụ cho phía đích chưa đăng ký.

Trường hợp nguồn là khi S-CSCF phục vụ cho phía khởi tạo phiên

(người gọi), trường hợp đích là khi S-CSCF phục vụ cho phía cuối

của phiên (người bị gọi).

• Session Description: xác định SPT cho nội dung của trường SDP

trong phần thân (body) của phương thức SIP. Mẫu kiểm tra có thể sử

dụng ở đây.

Về mặt dữ liệu thì cấu trúc của tiêu chuẩn lọc khởi tạo được mã hóa dựa trên

xml. Dưới đây là một ví dụ tiêu chuẩn lọc khởi tạo cho dịch vụ hộp thư thoại

tại máy chủ ứng dụng (sip:[email protected]) dành cho thuê bao

chưa đăng ký. Để làm được điều này thì nhà cung cấp phải làm cho SIP

Method có giá trị là INVITE và Session Case có giá trị là terminating –

unregistered. Nếu như không kết nối đến được máy chủ ứng dụng thì xử lý

mặc định là dừng phiên lại.

83



Giang Kỳ Nam

Hình 4-32 : Ví dụ về User Profile

4.5.3 Lựa chọn máy chủ ứng dụng

Tiêu chuẩn lọc khởi tạo được tải về S-CSCF trong quá trình đăng ký của thuê

bao hoặc khi nhận được yêu cầu khởi tạo đích cho thuê bao chưa đăng ký.

Sau khi tải hồ sơ thuê bao từ HSS, S-CSCF sẽ quyết định tiêu chuẩn lọc cho

từng yêu cầu khởi tạo theo các bước sau:

84



Giang Kỳ Nam

• Kiểm tra xem dịnh danh người dùng công cộng có bị chặn hay không?

Nếu không thì tiếp tục.

• Kiểm tra xem yêu cầu là yêu cầu đích (terminating) hay yêu cầu

nguồn (originating).

• Chọn tiêu chuẩn lọc khởi tạo cho các trường hợp phiên cụ thể (nguồn,

đích, đích cho người dùng chưa đăng ký).

• Kiểm tra xem yêu cầu có khớp với tiêu chuẩn lọc khởi tạo có độ ưu

tiên cao nhất bằng cách so sánh hồ sơ dịch vụ với định danh người

dùng công cộng trong yêu cầu:

o Nếu yêu cầu khớp với tiêu chuẩn lọc khởi tạo, S-CSCF sẽ

chuyển tiếp yêu cầu này đến máy chủ ứng dụng, sau đó kiểm

tra xem nó có khớp với tiêu chuẩn lọc khởi tạo có độ ưu tiên

thấp hơn hay không? Nếu có áp dụng vào SIP Method nhận

được từ liên lạc trước đó đến máy chủ ứng dụng.

o Nếu yêu cầu không khớp với tiêu chuẩn lọc khởi tạo có độ ưu

tiên cao nhất thì tiếp tục kiểm tra cho đến khi nó khớp.

o Nếu không còn (hoặc không có) tiêu chuẩn lọc khởi tạo nào

khớp, thì S-CSCF sẽ chuyển yêu cầu theo các quyết định định

tuyến.

Ở đây tồn tại sự khác biệt rõ ràng giữa cách xử lý của S-CSCF với tiêu chuẩn

lọc khởi tạo cho yêu cầu nguồn và đích. Khi S-CSCF nhận ra rằng máy chủ

ứng dụng đã thay đổi Request-URI trong trường hợp tiêu chuẩn lọc khởi tạo

đích, nó sẽ dừng kiểm tra và định tuyến yêu cầu theo giá trị của Request-

URI. Trong trường hợp nguồn, S-CSCF sẽ tiếp tục đánh giá các tiêu chuẩn

lọc khởi tạo cho đến khi hết.

85



Giang Kỳ Nam

Nếu máy chủ ứng dụng được liên lạc không phản hồi, S-CSCF sẽ gọi hành

động mặc định được nêu ra trong tiêu chuẩn lọc khởi tạo: hoặc là dừng phiên

hoặc là cho tiếp tục dựa trên các thông tin được cung cấp ở tiêu chuẩn lọc

khởi tạo. Nếu trong tiêu chuẩn lọc khởi tạo không đề cập đến hành động mặc

định, nếu không liên lạc được với máy chủ ứng dụng thì S-CSCF sẽ cho cuộc

gọi tiếp tục.

4.5.4 Hành vi của máy chủ ứng dụng

Sau khi nhận được yêu cầu, máy chủ ứng dụng sẽ bắt đầu khởi tạo các dịch

vụ cụ thể. Để đáp ứng dịch vụ máy chủ ứng dụng có thể hoạt động như một

trong các dịch vụ sau:

• Terminating User Agent.

• Redirect Server.

• SIP Proxy Server.

• Back-to-back User Agent

Ngoài các chế độ trên, máy chủ ứng dụng còn có thể hoạt động như một

Originating User Agent, nó có thể gửi yêu cầu đến thuê bao: ví dụ như máy

chủ ứng dụng tin tức có thể gửi trả kết quả bong đá cho thuê bao đăng ký

dịch vụ.

4.5.5 Máy chủ ứng dụng tương tác với HSS

Khi nhận được một yêu cầu từ phía người sử dụng, máy chủ ứng dụng sử

dụng giao diện Sh bằng giao thức diameter để truy vấn cơ sở dữ liệu HSS các

thông tin cần thiết để thực hiện dịch vụ:

• Khi nhận được yêu cầu sử dụng dịch vụ từ phía người dùng cuối

thông qua giao diện Web, máy chủ ứng dụng sử dụng giao thức Sh để

tải về hồ sơ người dùng. Sau đó, máy chủ ứng dụng sẽ tiến hành kiểm

86



Giang Kỳ Nam

tra tiêu chuẩn lọc khởi tạo trong hồ sơ người dùng: nếu người dùng

chưa đăng ký sử dụng dịch vụ thì máy chủ sẽ gửi trả lại thông báo cho

người dùng, ngược lại nếu người dùng đã đăng ký thì máy chủ ứng

dụng sẽ xử lý thông tin trong yêu cầu đó do người dùng đầu cuối gửi

lên để thực hiện dịch vụ.

• Thông tin về S-CSCF liên quan tới người gọi và người bị gọi, để máy

chủ ứng dụng có thể chuyển tiếp bản tin và thực hiện dịch vụ.

Chi tiết về giao diện Sh xem tại mục 4.4.2.

4.5.6 Máy chủ ứng dụng gửi yêu cầu về S-CSCF

Trong ứng dụng này, máy chủ đóng vai trò như một B2BUA, vì vậy khi nhận

được bản tin HTTP POST từ phía người dùng đầu cuối, nó kiểm tra trong

tiêu chuẩn lọc. Nếu thỏa mãn các điều kiện, máy chủ sẽ thực hiện dịch vụ

bằng cách tạo ra một bản tin INVITE dựa vào các thông tin S-CSCF phục vụ

người dùng tải được về thông qua giao diện Sh, nó sẽ chuyển tiếp bản tin

INVITE khởi tạo đến S-CSCF của người gọi để khởi tạo dịch vụ.

87



Giang Kỳ Nam

5 CHƯƠNG V : DỊCH VỤ IPTV TRÊN NỀN IMS

IPTV được định nghĩa là các dịch vụ đa phương tiện như truyền hình, video,

audio, hình ảnh được cung cấp trên nền tảng là mạng IP nhằm cung cấp các

mức cần thiết về chất lượng dịch vụ, chất lượng trải nghiệm, khả năng bảo mật,

tính tương tác và tính ổn định.

Trên nền tảng IMS, yếu tố di động và truy nhập không dây trở nên khả thi, càng

tạo điều kiện cho IPTV phát triển thành một trong những dạng dịch vụ Quad-

Play. Ngoài các dịch vụ truyền hình quảng bá thông thường, Video theo yêu cầu

(Video on Demand – VoD), IPTV còn hỗ trợ sự tương tác giữa người xem với

chương trình và đây cũng chính điểm đặc biệt và hấp dẫn nhất của IPTV.

Không đơn thuần là truyền hình như truyền hình cáp truyền thống, IPTV là một

tổng thể chuỗi các dịch vụ truyền hình có tính tương tác. Ngoài việc tự do lựa

chọn chương trình truyền hình hay phim muốn xem, người sử dụng có thể tham

gia các cuộc hội thảo từ xa, chơi game, mua hàng qua TV hoặc viết blog video

(vlog), nhắn tin qua TV...

5.1 Giới thiệu dịch vụ IPTV trên nền IMS

IPTV trên nền IMS cho phép người dùng truy cập và xem các kênh truyền hình

hoặc các kênh phát theo yêu cầu bằng cách thiết lập 1 cuộc gọi đến 1 địa chỉ

dạng email (sip uri) 1 cách dễ dàng và tiện lợi như cách người ta vẫn gọi điện

thoại cho bạn bè.

Khác với dịch vụ IPTV truyền thống, IPTV trên nền IMS cho phép người dùng

truy cập dịch vụ từ bất kỳ đâu, ở nhà cũng như đang đi xe bus. Tất cả những gì

cần chỉ là gọi điện thoại tới 1 địa chỉ URI hoặc tới 1 số điện thoại đã được định

88



Giang Kỳ Nam

sẵn, sau đó luồng media trực tiếp được truyền về máy người sử dụng mà không

cần phải cài đặt thêm bất cứ cái gì khác.

Ngoài ra IPTV trên nền IMS còn mở ra cho nhà cung cấp dịch vụ cách thức tốt

nhất và nhanh nhất để phát triển dịch vụ của mình. Dựa vào nền tảng rất mạnh

trong thiết kế dịch vụ của IMS, nhà cung cấp có thể thêm vào dịch vụ của mình

rất nhiều giá trị gia tăng làm tăng sự thoải mái của khách hang.

Trong đề tài này, dịch vụ IPTV được tích hợp khả năng quản lý quyền truy cập,

là chức năng rất cần thiết đối với những bậc phụ huynh không có thời gian quản

lý con em mình. Đối với những người dùng đăng ký chức năng Parental Control

– quản lý quyền truy cập đối với trẻ em, hệ thống tự động lọc những nội dung

được yêu cầu.

Trước hết hệ thống sẽ loại bỏ tất cả những kênh không phù hợp với lứa tuổi khi

được yêu cầu danh sách kênh hiện có. Sau đó đối với những kênh thuộc diện

quản lý của cha mẹ hoặc những kênh cấm truy cập theo giờ (vd như các kênh

phim hành động mỹ trong thời gian cha mẹ vắng nhà hoặc các kênh giải trí

trong thời gian làm bài tập hoặc tất cả các kênh khi đến giờ đi ngủ…) hệ thống

sẽ nhắn tin đến cha mẹ hoặc người lớn tuổi có liên quan để hỏi quyền truy cập

của người dùng này.

Nếu tin nhắn trả lời của cha mẹ là tin nhắn đồng ý, hệ thống sẽ phục vụ như

thường, còn nếu ngược lại, 1 tin nhắn thông báo sẽ được gửi về người dùng nói

rằng bạn không được người lớn cho phép.

89



Giang Kỳ Nam

5.2 Các luồng xử lý cuộc gọi trong IPTV nền IMS

5.2.1 Đăng ký vào mạng IMS

5.2.1.1 Thiết bị đầu cuối người dùng thực hiện đăng ký tới S-CSCF

UE P-CSCF I-CSCF HSSS-CSCF

F1. REGISTER

F2. REGISTER

F3. REGISTER

Chọn S-CSCF

Chứng thực dữ liệu

Ipsec sercurity

F4. 401 ( Unauthorized )



F7. REGISTER

F8. REGISTER

F9. REGISTER

HÌnh 5-33:Quá trình đăng ký của user vào mạng IMS (tiếp)

Các thủ tục đăng ký IMS:

• UE xác định địa chỉ của P-CSCF, P-CSCF sử dụng như một proxy

biên SIP trong suốt quá trình đăng ký và cho tất cả các báo hiệu SIP

khác trong khi nó đã được đăng ký.

• UE gửi bản tin REGISTER tới mạng chủ của alice để thực hiện đăng

ký SIP cho nhận dạng người dùng công cộng của alice.

• I-CSCF lựa chọn S-CSCF phục vụ người dùng khi nó đã đăng ký.

90



Giang Kỳ Nam

• S-CSCF tải các dữ liệu xác thực người dùng từ HSS.

• UE và mạng S-CSCF xác thực mỗi dữ liệu đó.

• Các chức năng bảo mật IP (IP sec) giữa UE và P-CSCF được thiết

lập.

• UE học đường đến S-CSCF.

• S-CSCF học đường đến UE.

UE P-CSCF I-CSCF HSSS-CSCF

Tải về hồ sơ người dùng

F13. SUBSCRIBE

F10. 200 OK

F11. 200 OK

F12. 200 OK

F14. SUBSCRIBE

F15. 200 OK

F16. 200 OK

F17. NOTIFY

F18. NOTIFY

F20. 200 OKF19. 200 OK

F21. SUBSCRIBE

F22. SUBSCRIBE

F23. 200 OK

F24. 200 OK

F25. NOTIFY

F26. 200 OK

HÌnh 5-34: Quá trình đăng ký của user vào mạng IMS (tiếp)

Quá trình đăng ký tiếp tục với các thủ tục:

91



Giang Kỳ Nam

• S-CSCF tải về hồ sơ người dùng từ HSS.

• S-CSCF đăng ký nhận dạng người dùng công cộng mặc định của

người dùng.

• S-CSCF có thể dựa trên hồ sơ người dùng để đăng ký nhận dạng

người dùng công cộng khác.

• UE biết về tất các nhận dạng người dùng công cộng đã được gán cho

alice và trạng thái đăng ký hiện tại của anh ta.

• P-CSCF biết tất cả các nhận dang công cộng được gán cho alice và

trạng thái đăng ký hiện tại của anh ta.

S-CSCF Application Server

REGISTER

200 OK

Đánh giá các tiêu chuẩn lọc

REGISTER

200 OK

HÌnh 5-35: Quá trình đăng ký của user vào mạng IMS (tiếp)

Sau khi người dùng đăng ký thành công, S-CSCF sẽ kiểm tra các tiêu chí

lọc đã tải về của người dùng.

92



Giang Kỳ Nam

5.2.2 Call flows của các chức năng chính trong dịch vụ IPTV

5.2.2.1 Chức năng “Danh sách chương trình nâng cao”

Danh sách chương trình là thành phần không thể thiếu đối với dịch vụ

truyền hình. Danh sách chương trình cho người xem biết hiện tại có tổng

cộng bao nhiêu kênh đang được chiếu, có những nội dung nào đáng quan

tâm.

Chức năng “danh sách chương trình nâng cao” của dịch vụ IPTV nền IMS

cho phép lọc danh sách kênh phù hợp với lứa tuổi. Trong danh sách chương

trình của những người sử dụng là trẻ nhỏ sẽ không có các kênh dành cho

người lớn và danh sách kênh của những người dùng thông thường sẽ không

giống với của những người dùng cao cấp (trả thêm tiền, quan chức, lãnh

đạo v.v…)

93



Giang Kỳ Nam

HÌnh 5-36: Người dùng thông thường

UE gửi bản tin SUBSCRIBE tới các CSCF với event = “iptv”, các CSCF sẽ

chuyển tiếp bản tin SUBSCRIBE này lên Application Server. AS sẽ kiểm

tra ở HSS xem UE có được quyền xem IPTV hay không, và nếu có thì user

có đăng ký dịch vụ parental control hay ko.

Nếu user đã đăng ký với nhà cung cấp dịch vụ IPTV và không dùng gói

parental control thì AS sẽ trả về bản tin 200 OK, trong phần content của

200 OK chứa file xml có thông tin về các kênh. Bản tin 200 OK được các

CSCF chuyển tiếp tới UE.

94



Giang Kỳ Nam

Tại UE, IMS – Communicator có trách nhiệm tách bản tin 200 OK lấy file

xml về thông tin các kênh, hiển thị ra một Frame cho người sử dụng thấy

dưới dạng cây thư mục. Nếu muốn xem một kênh nào đó người sử dụng sẽ

nhấn vào kênh đó, từ đó kết nối với kênh được thiết lập.

Với những user sử dụng gói dịch vụ parental control thì AS sẽ lọc nội dung

các kênh hiện có và chỉ trả về các kênh phù hợp với lứa tuổi của user đã

đăng ký.

HÌnh 5-37: Đăng nhập với dịch vụ IPTV trường hợp có Access control

95



Giang Kỳ Nam

5.2.2.2 Chức năng “Truyền hình cơ bản”

Đây là chức năng cơ bản nhất của ngành truyền hình, đối với bất cứ công

nghệ nào, truyền hình qua vệ tinh, qua dây cáp hay qua sóng vô tuyến hay

nền IP, những nội dung truyền hình cơ bản như các kênh thông tin chính

thức của nhà nước đều nhất thiết phải có. Những kênh này có 2 dạng, 1 là

truyền hình trực tiếp, 2 là truyền phát lại từ thiết bị lưu trữ. Phần lớn những

nội dung này đều được chiếu phát miễn phí cho tất cả đối tượng khách

hang.

HÌnh 5-38: Dịch vụ truyền hình cơ bản

96



Giang Kỳ Nam

Người sử dụng gửi bản tin INVITE với trường “To” là ID của kênh cần

xem ( nhận được từ file xml) . Ví dụ là : [email protected]. Bản tin này

được các CSCF chuyển tới AS. AS tiếp nhận bản tin này. Nếu đồng ý nó sẽ

tìm kiếm trong cơ sở dũ liệu của nó xem kênh được yêu cầu là do đài truyền

hình nào phát, kết quả tìm kiếm là 1 “Media Resource Location - MRL”

giống như địa chỉ URL như chúng ta thường duyệt web.

Địa chỉ này thường có dạng “rtsp://domain/channel.sdp” , sau đó được

đính kèm vào bản tin 200 OK gửi lại cho người sử dụng.

Từ đó người sử dụng sẽ mở 1 phiên media kết nối trực tiếp với đài truyền

hình – đơn vị cung cấp nội dung truyền hình và xem các kênh ở đây.

5.2.2.3 Chức năng “Video theo yêu cầu”

Bên cạnh truyền hình truyền thống, dịch vụ IPTV được phát triển trong đồ

án có kèm theo chức năng Video on Demand tạm dịch là Video theo yêu

cầu. Để sử dụng dịch vụ này, người sử dụng sẽ đăng ký với nhà cung cấp

dịch vụ các gói tương ứng là Standard VoD hay là Advanced VoD – VoD

tiêu chuẩn hoặc VoD cao cấp.

Dịch vụ VoD tiêu chuẩn phục vụ khách hàng như dịch vụ truyền hình theo

yêu cầu thông thường, khách hàng gửi yêu cầu vào nhận lại danh sách nội

dung số, danh sách này được cập nhật thường xuyên. Để xem 1 nội dung

nào đó người sử dụng sẽ gửi bản tin INVITE và nội dung số sẽ truyền tới

người sử dụng.

Dịch vụ VoD cao cấp cho phép người dùng chặn quyền truy cập đối với trẻ

nhỏ theo phân loại nội dung và thời gian truy cập. Ngoài ra còn có chức

năng nhắn tin tới người lớn khi có yêu cầu từ trẻ nhỏ tới những nội dung

không phù hợp hoặc vi phạm thời gian được phép sử dụng. Dịch vụ này còn

có khả năng cung cấp video hiện trường, cho phép người sử dụng có thể

97




Giang Kỳ Nam

xem trực tiếp cận cảnh ở 1 nơi nào đó – vd như tình hình giao thông ở 1 số

tuyến đường có lắp hệ thống camera.

Đầu tiên, UE gửi bản tin INVITE với trường “To” là ID của kênh cần xem (

nhận được từ file xml) . Ví dụ là : [email protected]. Bản tin này

được các CSCF chuyển tới AS. AS tiếp nhận bản tin này. Nếu đồng ý nó

chuyển tiếp bản tin này sang cho máy chủ phục vụ nội dung số MRF, MRF

chỉ có nhiệm vụ phục vụ nội dung cho người sử dụng, nó sẽ gửi về bản tin

183 Session Progress và bản tin 200 OK xác nhân là yêu cầu của quý khách

đã được chấp nhận.

Sau đó MRF sẽ mở 1 luồng media streaming truyền tải nội dung số tới ip

của máy tính của người dùng như đã đăng ký trong bản tin SIP/SDP

98




Giang Kỳ Nam

HÌnh 5-39: Dịch vụ VoD tiêu chuẩn

Nếu UE muốn kết thúc xem, UE gửi bản tin BYE tới AS với trường “To” là

[email protected], Call-ID là Call-ID của phiên hiện thời, chính là

Call-ID của bản tin INVITE. AS nhận được bản tin BYE sẽ gửi về bản tin

200 OK cho UE biết AS đã nhận được bản tin BYE của UE

99




Giang Kỳ Nam

HÌnh 5-40: Dịch vụ VoD nâng cao

Đối với những kênh thuộc diện quản lý hướng dẫn của cha mẹ (Rating PG

– parental guidance) thì AS sẽ gửi cho reference user của người dùng 1

thông điệp có nội dung xin phép truy cập. Nếu nhận được sự đồng ý thì

phiên dịch vụ diễn ra bình thường, còn ko thì 1 bản tin unauthorize sẽ được

trả về cho người yêu cầu kèm với lý do của cha mẹ.

100



Giang Kỳ Nam

5.2.3 Các tình huống khi đăng nhập và sử dụng dịch vụ IPTv

5.2.3.1 Các trường hợp từ chối dịch vụ

Máy chủ IPTV từ chối không phục vụ người dùng trong các trường hợp

sau:

Từ chối đăng ký dịch vụ: khi IPTv server tải xuống profile người dùng từ

HSS mà không thấy dịch vụ Iptv được đăng ký thì server sẽ trả về bản tin

401 unauthorized với lý do là xin mời đăng ký với nhà cũng cấp dịch vụ

IPTV trước.

Từ chối phục vụ dịch vụ:

o khi người dùng gửi bản tin INVITE yêu cầu 1 kênh bất kỳ mà chưa

Login vào dịch vụ bằng bản tin SUBSCRIBE thì hệ thống sẽ trả về

bản tin 401 Unauthorized với lý do là xin hay đăng nhập vào dịch

vụ trước.

o khi người dùng gửi bản tin INVITE yêu cầu 1 kênh không có trong

cơ sở dũ liệu của máy chủ IPTV thì hệ thống sẽ trả về bản tin 604

kèm lý do là kênh được yêu cầu không tồn tại hoặc đã bị xóa khỏi

hệ thống.

o khi người dùng gửi bản tin INVITE yêu cầu 1 kênh mà phải có sự

chấp thuận của người khác mà máy chủ IPTV kiểm tra thấy người

đó hiện không lien lạc được hoặc đang trả lời 1 yêu cầu truy cập

khác thì hệ thống sẽ trả về bản tin 603 với lý do là không thể liên

lạc được với cha mẹ bạn hoặc họ đang bận.

5.2.3.2 Thiết bị đầu cuối bị ngắt đột ngột

Về nguyên tắc, trước khi có thể thực hiện bất kỳ 1 yêu cầu dịch vụ nào,

người dùng đều phải đăng ký vào phiên IPTv bằng bản tin SUBSCRIBE.

Tuy nhiên trong quá trình sử dụng sẽ gặp phải trường hợp là thiết bị đầu

101



Giang Kỳ Nam

cuối bị ngắt đột ngột, có thể là do mất điện, khi đó sau khi bật lên thiết bị

sẽ lại đăng nhập lại 1 lần nữa. Trong trường hợp này phía server sẽ tự

nhận biết được và sẽ xóa phiên làm việc trước của user sau đó tự dộng

đăng nhập lại, mọi thay đổi trên hệ thống đều được cập nhật mới.

102



Giang Kỳ Nam

6 CHƯƠNG VI : THIẾT KẾ DỊCH VỤ IPTV

Nội dung chương này sẽ tập trung vào quá trình thiết kế dịch vụ, các công nghệ

được áp dụng, các yêu cầu thực tế, sơ đồ lớp và các sơ đồ thuật giải để thực

hiện dịch vụ.

6.1 Tổng quan về công nghệ SIP Servlet

6.1.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 đó lắng nghe các luồng lưu lượng 103



Giang Kỳ Nam

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ụ.

6.1.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.

6.1.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.

104



Giang Kỳ Nam

• 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.

6.1.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 105



Giang Kỳ Nam

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 phương thức thích hợp với yêu cầu đẻ xử lý yêu cầu đo. Người

phát triển servlet phải cung cấp việc triển khai cho các phương thức

này. Nếu một yêu cầu cho phương thức mà không được triển khai

bởi servlet, phương thức của lớp cha sẽ được gọi, thường là kết quả

của một lỗi được trả lại từ người yêu cầu.

• Cuối cùng, bộ chứa gọi phương thức destroy() để cho container làm

cho servlet không thực hiện phục vụ. Phương thức destroy() tương tự

như phương thức init() chỉ được gọi một lần trong vòng đời của

servlet.

Hình 6-41 : Vòng đời của Servlet

Có thể hiểu vòng đời của một servlet thông qua các phương thức sau: đoạn

mã (code) được nạp vào server; sau đó các lớp servlet được thực hiện và

khởi tạo; servlet được gọi nhiều lần để xử lý các bản tin đến; cuối cùng

servlet được phá hủy.

6.1.2.3 Ngữ cảnh SIP Servlet

Ngữ cảnh servlet được định nghĩa trong đặc tả servlet cũng được áp dụng

cho SIP servlet. Đặc tả servlet định nghĩa các thuộc tính ngữ cảnh cụ thể

106



Giang Kỳ Nam

được sử dụng để lưu trữ và truy nhập thông tin tới SIP servlet và các giao

diện từ ngữ cảnh. Ngữ cảnh servlet có thể dùng chung với HTTP servlet

trong cùng một ứng dụng.

6.1.2.3.1 SIP Factory

SIP Factory là một lớp xưởng (factory) để tạo các đối tượng chuẩn SIP

Servlet cần thiết cho việc thực thi ứng dụng. Giao diện của SIPFactory

được sử dụng bởi các servlet để tạo các thực thể của các giao diện khác

nhau:

Tên lớp Mô tảURI, Sip URI, Address có thể tạo ra thông tin địa chỉ bao gồm SIP URI từ một

chuỗi.SipApplicationSession tạo một phiên ứng dụng mới. Nó được gọi khi một SIP

Servlet bắt đầu xử lý một tín hiệu SIP mới. Điều đó có nghĩa là các phiên ứng dụng thường được sử dụng trong thời gian khởi động khi một ứng dụng được gọi để khởi chạy nó và nên được sử dụng tiết kiệm.

SipServletRequest sử dụng khi một SIP servlet hoạt động như một UAC tạo một yêu cầu. Thí dụ như các yêu cầu có thể không được gửi với Proxy.proxyTo. Chúng có thể được gửi với SipServletRequest.send. Nói cách khác: • Các phương thức creatRequest tạo các thực thể của

giao diện SipServletRequest và được sử dụng bởi các ứng dụng UAC khi khởi tạo các yêu cầu trong một hộp thoại mới.

• Khi khởi tạo một chuỗi con các yêu cầu trong hộp thoại đang tồn tại, SipSession.createRequest được sử dụng thay thế.

SIPFactory được đặt trong ngữ cảnh servlet dưới tên mặc định. Ta có thể

thực hiện nó với đoạn mã dưới đây:

ServletContext context = getServletContext();

SipFactory factory =

(SipFactory) context.getAttribute(“javax.servlet.sip.SipFactory”);

107



Giang Kỳ Nam

Tất cả các container servlet phải thực hiện một trường hợp của giao diện

javax.servlet.sip.SipFactory tồn tại với các servlet thông qua ngữ cảnh có

cùng tên, javax.servlet.sip.SipFactory.

6.1.2.3.2 Đường dẫn ngữ cảnh

Servlet API định nghĩa về khái niệm đường dẫn ngữ cảnh. Đây là một tiền

tố đường dẫn URL kết hợp với một ứng dụng web. Tất cả các yêu cầu

HTTP URL bắt đầu với đường dẫn ngữ cảnh của một ứng dụng web sẽ

được định tuyến tới ngữ cảnh servlet tương ứng. Trong khi SIP URIs

không có khái niệm về các đường dẫn, các phương thức ServletContext

dưới đây không có nghĩa cho các ứng dụng hoặc bộ chứa servlet SIP và

phải trở về giá trị rỗng:

ServletContext getContext(String uripath);String getRealPath(String path);RequestDispatcher getRequestDispatcher(String path);

Để việc nạp tài nguyên được đề cập tới, đường dẫn ngữ cảnh của SIP

servlet luôn luôn có “/”. Tổ hợp giữa thực thi ứng dụng HTTP và SIP

trong bộ chứa HTTP Servlet, đường dẫn ngữ cảnh được định nghĩa bởi

HTTP Servlet API và việc nạp tài nguyên xử lý theo chuẩn Java Servlet

[Servlet API].

6.1.2.3.3 Các tham số ngữ cảnh

Các bộ chứa với các chuẩn phải được thực hiện theo các thông số của

bảng tham khảo dưới đây với các ứng dụng có ngữ cảnh Servlet:

Thông số Mô tảjavax.servlet.sip.supported Một thực thể không đổi của giao diện

java.util.List chứa các tên xâu của phần mở rộng SIP hỗ trợ bởi bộ chứa.

javax.servlet.sip.supportedRfcs Một thực thể không đổi của giao diện java.util.List chứa các số RFC mô tả như xâu của SIP RFC hỗ trợ bởi bộ chứa

108



Giang Kỳ Nam

javax.servlet.sip.100rel Thông số mà giá trị đề xuất được bộ chứa hỗ trợ phần mở rộng 100rel. Thông số này không được tán thành trong chuẩn của tham số javax.sip.supported

javax.servlet.sip.SipSessionsUtil Bộ chứa lớp SipSessionUtil cho ID trên cơ sở tìm kiếm thực thể SipApplicationSession

javax.servlet.sip.SipFactory Thực thể của các ứng dụng SipFactoryjavax.servlet.sip.outboundInterfaces Một thực thể không đổi của giao diện

java.util.List chứa trong Sip URI mô tả bởi địa chỉ IP được sử dụng bởi bộ chứa để gửi đi các bản tin

javax.servlet.sip.TimeService Thực thể của lớp TimeService

6.1.2.4 SIPServletRequest và SIPServletResponse

Phương pháp luận yêu cầu–hồi đáp trong SIP cũng tương tự như trong

HTTP Servlet. Một yêu cầu được định nghĩa trong đối tượng

SipServletRequest và một hồi đáp được định nghĩa trong đối tượng

SipServlerResponse. Tuy nhiên, chỉ có một đối tượng ServletRequest hoặc

ServletReponse là có giá trị. Điều này là do một yêu cầu SIP không đưa ra

một hồi đáp đối xứng. Cũng có một giao diện chung gọi là

SipServletMessage cho cả đối tượng SipServletRequest và

SipServletResponse. Giao diện SipServletMessage định nghĩa các phương

thức chung cho các đối tượng SipServletRequest và SipServletResponse.

109



Giang Kỳ Nam

Hình 6-42 : Minh họa cấu trúc phân cấp của đối tượng SipServletRequest và

SipServletResponse

6.1.2.5 Đóng gói ứng dụng

Các ứng dụng SIP có thể được đóng gói với cùng cấu trúc của các ứng dụng

web. Chúng được đóng gói trong định dạng JAR cùng với phần mở rộng

là .sar (Sip archive) hoặc .war (web archive).

6.1.2.6 Mô tả triển khai (deployment descriptor)

Một bản mô tả triển khai trên nền XML thường được dùng để mô tả SIP

Servlet, các nguyên tắc để khởi tạo chúng cũng như các đặc tính về nguồn

tài nguyên và đặc tính môi trường được sử dụng trong ứng dụng. Bản mô tả

này nằm trong tập tin sip.xml và cũng giống như tập tin được sử dụng trong

HTTP servlet. Sip.xml được định nghĩa bởi một giản đồ XML.

110



Giang Kỳ Nam

6.1.2.7 Ngữ cảnh hội tụ và ứng dụng hội tụ (converged context –

converged application)

Một ứng dụng có thể sử dụng cả SIP Servlet và HTTP Servlet để tạo ra dịch

vụ. Để cho phép HTTP và SIP Servlet nằm trong cùng một gói ứng dụng,

đặc tả SIP servlet định nghĩa một đối tượng ConvergedContext. Đối tượng

này nắm giữ ngữ cảnh servlet chia sẻ bởi cả HTTP và SIP servlet và cung

cấp một tầm nhìn ứng dụng chung cho cả SIP và HTTP servlet trong các

khái niệm thuộc tính ngữ cảnh servlet, nguồn tài nguyên và JNDI

namespaces.

Khi một ứng dụng bao gồm cả SIP và HTTP servlet thì ứng dụng đó có thể

được hiểu là ứng dụng hội tụ. Điều này trái ngược với ứng dụng chỉ có SIP

được gọi là một ứng dụng SIP. Một ứng dụng hội tụ cũng tương tự như một

ứng dụng SIP về cấu trúc ngoại trừ nó có thêm tập tin web.xml như là một

bản mô tả triển khai thêm vào một tập tin sip.xml. Trong SIP Servlet API

1.1 (JSR289), khái niệm ứng dụng hội tụ có thể được mở rộng để bao hàm

cả các ứng dụng thương mại. Một ứng dụng thương mại có thể được gọi là

ứng dụng hội tụ.

6.1.2.8 Phiên SIP

Đặc tả SIP Servlet định nghĩa các đối tượng SipSession để thể hiện một

phiên thông qua SIP trong cùng một cách với HttpSession để thể hiện phiên

thông làm việc thông qua HTTP. Bởi vì một ứng dụng đơn như ứng dụng

hội tụ có thể thực hiện một phiên thông qua cả HTTP và SIP, đặc tả này có

thể định nghĩa SipApplicationSession là một đối tượng session ở mức ứng

dụng. Đối tượng SipApplicationSession có thể hoạt động như một lớp cha

với các phiên HTTP và SIP trong một ứng dụng. SipApplicationSession

phục vụ hai mục đích: cung cấp kho chứa dữ liệu cho ứng dụng và phối hợp

với một số protocol session.

111



Giang Kỳ Nam

6.2 Thiết kế dịch vụ

6.2.1 Yêu cầu

Thiết kế dịch vụ truyền hình nền ip sử dụng kiến trúc mạng IMS.

Dịch vụ cần có các chức năng:

o Phục vụ nội dung số tới người sử dụng trong mạng IMS sử dụng thiết

bị đầu cuối có cài đăt IMS client có chức năng IPTV.

o Có khả năng phân loại người dùng

o Phân loại nội dung số

o Danh sách chương trình nâng cao

o Quản lý quyền truy cập theo người dùng, thời gian và phân loại nội

dung.

o Có khả năng nhắn tin truy vấn quyền sử dụng.

Dịch vụ cần đáp ứng các yêu cầu:

o Có khả năng truyển tải các nội dung số đa dạng về mã hóa.

o Gửi các thông điệp thân thiện tới khách hang.

o Đảm bảo về bảo mật thông tin của kho nội dung số.

o Đảm bảo chất lượng nội dung số - thời gian phục vụ.

6.2.2 Kiến trúc hệ thống

Dịch vụ IMS based IPTV trong phạm vi đồ án được chia làm 2 modul lớn,

IPTV và Parental Control

Trong đó dịch vụ IPTV được xây dựng hướng đến người dùng phổ thông

có nhu cầu xem các chương trình truyền hình (Linear tv) và truyền hình

112



Giang Kỳ Nam

theo yêu cầu (Video on demand) cả trên di động lẫn trên tivi qua bộ thu

setop box.

Dịch vụ Parental Control hướng tới người dùng là vị thành niên hoặc trẻ

nhỏ chưa đủ 18 tuổi có nhu cầu tiếp cận với kho nội dung số, có chức năng

lọc nội dung truyền hình và Video on demand, phát theo giờ hoặc theo sự

chỉ định của cha mẹ (người dùng tham vấn – reference user)

Mô hình tổng quát:

HÌnh 6-43: Mô hình tổng quát dịch vụ IMS based IPTV

Chú thích:

Ims client, setopbox: là thiết bị đầu cuối truy cập dịch vụ

CSCFs: các thành phần thuộc mạng lõi IMS113



Giang Kỳ Nam

HSS: server lưu trữ hồ sơ người dùng

Media server: server lưu trữ, điều khiển và truyền tải nội dung số

Application server: server xử lý các logic dịch vụ IPTv – cung cấp dịch vụ

IPTv

Sip: giao thức báo hiệu trong mạng IMS

RTP/RTSP: giao thức báo hiệu – truyền nội dung số

Diameter: giao thức chứng thực, cấp quyền và tính toán trong mang IMS.

• Việc nhận thực người dùng trong mạng do CSCFs thực hiện và quản lý

dựa trên hồ sơ người dùng lưu trữ tại HSS.

• Việc cung cấp nội dung số cho người sử dụng sẽ được Application

Server quản lý dựa trên hồ sơ dịch vụ mà người dùng đã đăng ký lưu trữ

tại HSS.

• Media server đóng vai trò là nguồn nội dung số mà Application server

lấy ra cho người sử dụng.

Server cung cấp dịch vụ (AS) được chọn là Sailfin v2.0 dùng công nghệ

Java EE làm nền tảng. Bao gồm các module:

• Các sip servlets phục vụ điều khiển phiên làm việc

• Các class hỗ trợ 1 số logic dịch vụ

• Database lưu trữ thông tin về các kênh như phân loại, đánh giá, mô tả

nội dung 1 kênh và giới hạn độ tuổi cho phép truy cập vào kênh đó.

• Web interface để quản lý và thiết lập cấu hình dịch vụ cũng như thông

tin về dịch vụ tới người dùng cuối.

Diameter client để tương tác với HSS trên giao diện Sh truy vấn các thông

tin về người dùng.

114



Giang Kỳ Nam

Server cung cấp nội dung số (MRF) được chọn là Darwin Streaming Server

v5.5.5 truyền tải nội dung truyền hình cơ bản và HUT – Media Resource

Function truyền tải nội dung truyền hình theo yêu cầu dựa trên giao thức

RTP/RTSP. Bao gồm các module:

• Web interface để quản lý thiết lập các kênh linear tv

• Module stream manager

• Module báo hiệu điều khiển dựa trên giao thức SIP

User endpoint hay user agent hay terminal hay thiết bị đầu cuối có thể là di

động, setop box, hay máy tính để bàn, laptop…với điều kiện có IMS client

platform cài sẵn và hỗ trợ xem truyền hình dựa trên giao thức RTP/RTSP.

6.2.3 Thiết kế các lớp cho dịch vụ

6.2.3.1 Sơ đồ lớp

Dành cho gói user.profile

Đối với user profile, mỗi user có profile cho dịch vụ IPTV được định nghĩa

gồm có các kiểu dịch vụ đăng ký, các ràng buộc đối với 1 user trong đó có

reference user, các ràng buộc về thời gian và phân loại kênh. Lớp

RepDataHandler có nhiệm vụ lấy các thông tin trên của user từ profile

người dùng tải về từ HSS. Sau đó các user được đưa vào 1 danh sách phục

vụ là QueueLoggedUsers. Lớp TimeService dùng để thực hiện các thao tác

kiểm tra về thời gian

115



Giang Kỳ Nam

HÌnh 6-44: sơ đồ lớp cho gói user profile

Dành cho gói servlets

Gói này bao gồm các servlet thực hiện logic dịch vụ

116



Giang Kỳ Nam

HÌnh 6-45: Sơ đồ lớp gói servlets

Gồm có 5 servlet chính.

• Main servlet làm nhiệm vụ khởi tạo ban đầu các giá trị tham số cũng

như các dụng cụ sử dụng cho logic dịch vụ trong thời gian chạy ứng

dụng.

• IPTVdoSERVICE servlet làm nhiệm vụ nhận bản tin INVITE và xử

lý..

• IPTVdoLOGIN servlet làm nhiệm vụ nhận bản tin SUBSCRIBE và

xử lý

• MediaContentProvider servlet chuyên làm nhiệm vụ thực hiện những

yêu cầu INVITE đã qua xử lý và đã được chấp thuận.

117



Giang Kỳ Nam

• IPTVdoMESSAGE servlet làm nhiệm vụ gửi nhận bản tin trong quá

trình quản lý truy cập.

Dành cho gói tools

Gói này có các lớp công cụ để xử lý các thành phần logic hoặc các công cụ

xử lý dữ liệu trong quá trình thực thi dịch vụ

HÌnh 6-46: Các lớp trong gói tools

Lớp Database tạo ra kết nối tới máy chủ dữ liệu.

Lớp Xmlhandler xử lý các yêu cầu liên quan tới Xml document.

Lớp StringManipulate xử lý các yêu cầu liên quan tới xâu chuỗi.

Lớp QueueAuthRequests lưu giữ các yêu cầu cần sự cho phép của người

dùng tham vấn.

118



Giang Kỳ Nam

Lớp MediaContent đại diện cho 1 kênh, bao gồm thể loại, mô tả,

rating,...của kênh đó

Dành cho gói diameter

HÌnh 6-47: Sơ đồ lớp gói diameter

Lớp ShApp khởi tạo và duy trì kết nối tới máy chủ HSS

119



Giang Kỳ Nam

Lớp ClientShSession quản lý luồng bản tin và tạo ra các bản tin diameter.

Lớp ShSessionEventListenerImpl nghe các trả lời từ HSS

6.2.3.2 Các khâu xử lý trong quá trình chạy dịch vụ

6.2.3.2.1 Cơ sở dữ liệu các kênh

Các thông tin về kênh – nội dung truyền hình và các user đã đang ký sẽ

được lưu trong máy chủ cơ sở dữ liệu bao gồm 2 bảng. Bảng

iptv_subscription chứa thông tin về các người dùng đã đăng ký dịch vụ.

Bảng iptv_media_source chứa thông tin về danh sách các kênh xem hiện tại

đang phục vụ. Nội dung các bảng như sau:

120



Giang Kỳ Nam

6.2.3.2.2 Khởi tạo dịch vụ

Lưu đồ thuật toán khâu khởi tạo dịch vụ:

121



Giang Kỳ Nam

HÌnh 6-48: Lưu đồ thuật toán khởi tạo dịch vụ

Khi dịch vụ được triển khai lên server ứng dụng, hàm init() trong servlet

Main.java sẽ được kích hoạt, khởi tạo module diameter và các biến, tham

số dùng cho dịch vụ.

6.2.3.2.3 Đăng nhập vào dịch vụ

Dưới đây là lưu đồ thuật toán đăng nhập vào dịch vụ

122



Giang Kỳ Nam

HÌnh 6-49: Lưu đồ thuật toán đăng nhập vào dịch vụ

123



Giang Kỳ Nam

Lớp IPTvdoLOGIN.java mô tả cách thức đăng nhập người dùng bằng bản

tin SUBSCRIBE, nhận thực người dùng thông qua giao diện Sh giữa AS

và HSS và sau đó cấu trúc lên nội dung chương trình cho từng đối tượng

cụ thể rồi gửi về cho người dùng trong bản tin 200 Ok.

Chi tiết mã nguồn được để trong đĩa CD đính kèm tài liệu.

6.2.3.2.4 Thực hiện và xử lý yêu cầu đối với 1 kênh cụ thể

Lưu đồ thuật toán xử lý yêu cầu đối với 1 kênh:

124



Giang Kỳ Nam

HÌnh 6-50: Lưu đồ thuật toán xử lý yêu cầu kênh

Lớp IPTvdoSERVICE.java mô tả cách thức xử lý mỗi yêu cầu truy cập

vào 1 kênh cụ thể bằng bản tin INVITE. Kiểm tra xem người dùng đã

đăng nhập chưa, kênh yêu cầu có tồn tại hay không và là yêu cầu truyền

hình cơ bản hay là Video on demand, người dùng có phải thuộc diện quản

lý truy cập hay không… và phục vụ với chức năng tương ứng

125



Giang Kỳ Nam

Chi tiết mã nguồn được để trong đĩa CD đính kèm tài liệu.

6.2.4 Kịch bản thực thi ứng dụng

Sip.xml là file định nghĩa các lớp SIP servlet và chỉ ra các ánh xạ của chúng.

Các ánh xạ cho Sip Servlet sử dụng các toán tử “and”, “equal”, và “not” để

định nghĩa ra các điều kiện trong đó servlet được kích hoạt.

6.3 Cài đặt và sử dụng dịch vụ

6.3.1 Yêu cầu hệ thống

Yêu cầu về phần cứng:

• Máy tính để bàn có cài đặt hệ điều hành Unix (tốt nhất dùng

Ubuntu phiên bản 8.04 trở lên).

• Đường truyền ADSL hoặc các thiết bị trong mạng LAN.

Yêu cầu về phần mềm:

• Linux có kernel 2.6.

• Máy tính có cài đặt Sailfin với đầy đủ thư viện.

• Hut - Communicator

6.3.2 Hướng dẫn cài đặt

Xem phụ lục kèm theo.

6.3.3 Kết quả thu được

Xem phụ lục kèm theo.

126



Giang Kỳ Nam

KẾT LUẬN

Trong thời đại ngày nay, Internet có vai trò ngày càng quan trọng trong lĩnh vực

viễn thông, chính vì vậy IMS – sự kết hợp giữa điện thoại di động truyền thống và

mạng internet hứa hẹn sẽ đem lại nhiều lợi ích cho cả người sử dụng lẫn nhà cung

cấp dịch vụ. Trong thời gian thực hiện đồ án, dưới sự tận tình của TS. Nguyễn Tài

Hưng cùng sự giúp đỡ chia sẻ của các bạn trong nhóm. Em đã nắm được những

kiến thức về kiến trúc IMS và hiểu cách phát triển các dịch vụ mới trên nền kiến

trúc IMS.

Trong đồ án, em đã tiến hành xây dựng các lược đồ báo hiệu và điều khiển trong

các trường hợp khác nhau của dịch vụ IPTV, và bước đầu đi vào triển khai dịch vụ

trong các trường hợp đơn giản đến phức tạp. Tuy nhiên bên cạnh những mặt thuận

lợi và những gì đã đạt được là những khó khăn, những nhược điểm:

• Đó là sự thiếu kinh nghiệm trong lập trình dẫn đến việc phát triển

nâng cao hệ thống còn nhiều hạn chế.

• Vấn đề bảo mật chưa được quan tâm nhiều.

• Hệ thống mới chỉ phát triển trong mạng nội bộ chứ chưa đưa ra được

ngoài mạng internet công cộng.

• Dịch vụ đa phần chỉ dừng lại ở mức nghiên cứu lý thuyết, thực hiện

mô phỏng chứ chưa đi vào thực tế.

Tuy nhiên, với sự nỗ lực hết mình của cá nhân và sự giúp đỡ nhiệt tình của các thầy

giáo và các bạn, em tin rằng trong thời gian tới sẽ có thể tiếp tục nghiên cứu và phát

triển dịch vụ hoàn thiện hơn. Đồng thời tiến tới xây dựng được nhiều dịch vụ ứng

dụng phục vụ cho người sử dụng và đem lại nhiều lợi ích cho các nhà cung cấp dịch

vụ.

127



Giang Kỳ Nam

PHỤ LỤC

1. Poster paper gửi tại hội nghị TridentCom – Berlin

IMS IPTV: An Experimental Approach

Nguyen Tai Hung, Nguyen Huu Thanh, Giang Ky Nam, Bui Quang Anh, Dinh Thai Hoang

Department of Communication Engineering Hanoi University of Technology{hungtaifet, thanhnh}@mail.hut.edu.vn

Abstract. IMS has been widely recognized as the control and signaling framework for delivering of the rich communication & multimedia services to broadband users. Amongst others, it’s deploying as the service (middleware) platform for interactive and personalized IPTV services. The goal of this paper is to provide a short description and analysis of the (IPTV) use cases that have been selected for design and implementation at Hanoi University of Technology (HUT) in scope of its initiatives for NGN researching program. Major use cases, or we called intelligent features, are the advanced electronic service guide, video on demand (VoD), (IPTV) session continuity, and parental control. Development results for each of the use case are depicted.

Keywords: IMS; IMS IPTV; enhanced EPG; Parental Control; Blending Service, Intelligent Features;

1. Introduction

IP Multimedia Subsystem (IMS) is a next generation network (NGN) architecture currently planned for mobile and fixed multimedia services, standardized by the 3rd Generation Partnership Project (3GPP) [1]. IMS promises a scalable integrated platform that enables new services and provides for the combination of telecommunications and Internet services, therefore, we have chance of using IMS to provide a highly integrated solution for seamless, networked-based media transportation over any end-user device. Since the IPTV had been developed and deployed for some time and had gone through numbers of generation with different middleware technologies. It’s now facing the challenges of the market which demands that IPTV must be equipped with more intelligent and interactive features in a standardized & interoperable way. This paper therefore will explore, in experimental perspective, the possibility of application of the IMS framework as the service control plane to provide the interactive and personalized Video services. The paper begins with a concise description of the novel IMS based IPTV architecture as well as our setup for an academic IMS Test-bed. The main part of the paper will be reserved for presentation of IPTV use cases that we have developed in our test-bed environment. Six use cases have been selected for design and implementation as listed below.

• Standard Video on Demand• Parental Control/Authorization: An intelligent feature that allows the parent to control their children

access to (IPTV) broadcast channels and/or on-demand contents.

• Enhanced EPG: Another feature that provides the (IPTV) viewers with personalized program guide

• Blending services [8]: a feature that allows the composition of telephony/messaging session with IPTV session.

128



Giang Kỳ Nam

• Sharing IMS profiles in the same device and IPTV application examples: Usage of several IMS profiles on a device when several users are sharing the same device

• Session transfer: A rich multi-device and multimodal interaction model that allows the user to start up a session of a converged service while commuting on the train, continue the interaction while walking to his office and complete the transaction while sitting down at his office-desk.

2. IMS Based IPTV Architecture

Novel Framework

Fig. 1. IMSbased IPTV

Figure-1 shows a high-level functional IPTV network architecture being supported by an IMS infrastructure. The model provides multimedia services to the end user by means of the SIP Application Server (SAS). The SAS implements the SIP server with which users interact and request the movies or other online contents and, more importantly, inclusive of advanced functionalities like the personalized electronic service guide (ESG), interactive (parental) authorization, blending sessions, etc. The SAS interacts with the IPTV User Terminal (IUT) that handles the display and interactivity functions for viewers. The IUT also performs functions such as content encoding/decoding and buffering for both unicast and multicast streams. The system is divided into a number of logically separated parts, namely, the home network, access network, aggregation network, and the service/content domain.

IPTV User ProfileIn the IMS IPTV architecture, personalization is an important feature. To achieve personalization at the

application level (i.e. personalized EPG’s, advertisements, or even personalized blended communication services), every user has an IPTV profile. The relation between the IPTV profile and the IMS profile depends on the availability of a home IMS gateway. The home gateway is a functional block with an attached ISIM card reader, which can be deployed in the residential gateway or any other networked consumer equipment. The gateway translates home signaling, whether SIP, UPnP or perhaps pure HTTP to IMS signaling. It also takes care of NAT traversal and secures connectivity with the P-CSCF in the IMS domain, as well as identity, device subscription, and management inside the home domain and towards the IMS core.

If the household contains a home gateway, the family members can choose whether they want to have full IMS identity, one which enables them full communication capabilities supported by IMS, or they opt to just have an IPTV profile, that will use the default IMS household identity for authentication purposes. The IPTV profile information that needs to be shared between different IMS services is stored in the IPTV XDMS database. This database is accessed using XCAP, which works over HTTP. These profiles can be shared by different users and other stakeholders within the IPTV system.

129



Giang Kỳ Nam

Our Testbed

In the scope of the joint-research project between Hanoi University of Technology and Fraunhofer Institute FOKUS, we was setting up a next generation Test-bed in our lab for purpose of prototyping of new multimedia and rich-feature communication services using IMS framework. The test-bed consists of all three layers: media layer for transportation of media traffic in the modes of unicast, multicast and broadcast. The core layer of signaling and session/service control uses the FOKUS’ open source IMS Core [3][4][5] that delivers CSCF servers and a light user profile database (HSS). Our project main focus is on the application layer in which we specified and developed prototypes for value added services to IP Telephony and IP Television using the Sailfin platform. A Media Server was also developed at our lab using VLC (VideoLAN) media stack. Besides that we had developed a comprehensive framework and prototype of IMS IPTV Client that based on the open source IMS Communicator. Finally, several IMS interfaces, namely, Sh, Mw, etc are implemented on our own effort. Figure 2 depicts high level view of our Test-bed setup.

Fig. 2. The HUT Next Generation Test-bed

3. IMS IPTV Use Cases

3.1. Message Flow

Standard Video on Demand

130



Giang Kỳ Nam

UE (emulated STB)CSCFs IPTV AS IMS MRF

RTP

INVITE


sip:[email protected] INVITE


183 Session Progress183 Session Progress

183 Session Progress

ACK

BYEBYE

BYE

200 OK

200 OK

200 OK

200 OK

200 OK

ACKACK

200 OK

Fig. 3. Requesting the on-demand contents

In our research, as depicted on figure 3, we consider a scenario in which an IMS user initiates a call to a specific content (a movie, a song or other resources) at the content provider through an IMS domain. The request would be routing through different SIP servers (CSCFs) and at S-CSCF a suitable iFC would be invoked to forward the request to IPTV AS, the AS will then proxy the request to MRF (Media Server). Media Server, after accepting the request, will send back the successful responses (via AS) as well as the RTP streams directly to Emulated STB. In our scenario, we had implemented the AS based on Sailfin platform and our Media Server was designed and implemented using VLC (VideoLAN) RTP stack and oSIP library.

Parental Control

`

Peter CSCFs AS Alice

INVITEsip:[email protected]

INVITEsip:[email protected]

Permission Resquest Message

Permission Resquest Message

Answer: Decline

Answer: Decline

Decline Message

Decline Message

603 Decline

603 Decline

Acess Control Decision

Fig. 4. IPTV Parental Control Feature

A special feature, called Parental Control, had been designed and implemented which allows the parent to control their child from requesting and viewing classified contents. In this scenario, as shown on the figure 4, the child (Peter) initiates a call to a specific content (movie and channel), the request will be forwarded to IPTV AS through IMS Core, the AS, through the in-house developed Sh interface, will download and check the service registration of this user and learnt that this user need the permission (from his parent) in order to view the requested content. The AS then checks the status of Parent (Alice) through Presence service and asks for her permission (via Message method). Depend on the response from Alice, whether she accept or

131



Giang Kỳ Nam

deny the request, IPTV AS will either send back to Peter the denial response (603 Decline) or proxy the request to Media Server which will subsequently send RTP stream to Peter’s Client.

Enhanced EPG Personalization is a key feature in the IMS IPTV solution. In this sense, we have complemented the user

profile with a new XML-formatted [9] service profile for each IMS identity to contain the personalized information. That leads to another intelligent feature for IMS-based IPTV, we called Enhanced EPG. With this feature user will be classified in to different groups (via subscription) with different service levels.

UE CSCFs AS HSS

SUBSCRIBEsip:[email protected]

SUBSCRIBEsip:[email protected]

User Data Request

User-Id: [email protected] Reference: ifc

User Data Answer

Ifc Attached

200 OK

200 OK

Channel list

If no acess controlConstruct the list of channel

Channel list

Fig. 5. Message Flow for EPG of uncontrolled access

UE CSCFs AS

SUBSCRIBEsip:[email protected] SUBSCRIBE

sip:[email protected] Data Request

User-Id: [email protected] Reference: ifc

User Data Answer

Ifc Attached

Acess control required

User Data Request

User-Id: [email protected] Reference: Repository Data

User Data Answer

Peter’s Repository Data Attached

Construct channel list Add access control to session

200 OK200 OK

Channel listChannel list

Fig. 6. Message flow for Enhanced EPG Feature

In this scenario, users in different classes, after registering in to the IMS Core, will send Subscribe request to IPTV AS for the EPG service. The AS then, via Sh interface, will query the HSS to download the relevant iFC and check the registered service profile of requesting user, if user is belonging to the free service package (no need access control) then AS will build the relevant channel list and send it, through the payload (in XML) of 200 OK Response message, back to the requesting user. In the other hand, if user is belonging to the group that need access control (e.x. for Premium service packages) then the AS need to query the HSS

132



Giang Kỳ Nam

again to obtain the necessary data to build the suitable channel list and send back to the requesting user. Figure 5&6 below show the basic message exchanges for implementation of these two scenarios. The access control also provides the time constrained service profile in which the requesting for different time slots will receive different channel lists.

Session ContinuityThe issue of session continuity is also studied in our test-bed, in which we investigated a new approach that allows handing over of an on-going IPTV session between different access heterogeneous environments. We propose a new component in the IMS domain, namely an proxy based on mSCTP (mobile Stream Control Transmission Protocol) that acts as an anchor point for soft vertical handover of mobile nodes, which have multiple physical interfaces (e.g., WLAN/UMTS). The mSCTP-based proxy also supports QoS provisioning and adaptation for the mobile nodes when moving in a heterogeneous wireless environment. Our simulation results show that the signaling cost for handover in our approach can be up to 23 times smaller than that in the conventional approach.

MN P-CSCF I-CSCF S-CSCF proxy AS

305 use proxy

INVITE(mSCTP)INVITE

INVITE(mSCTP) INVITE(mSCTP)INVITE(mSCTP)

INVITE(mSCTP)INVITE(mSCTP)

INVITE(mSCTP)100 trying

100 trying100 trying

183 sp183 sp183 sp

183 sp183 sp

PRACKPRACK

PRACKPRACK

MN PDP Context Activation 200 OK

200 OK

proxy PDP Context Activation

AS PDP Context Activation

200 OK200 OK

Visited IMS Domain 1 Home IMS Domain

REFER (AS)

200 OK

MN P-CSCF I-CSCF S-CSCF proxy AS

305 use proxy

INVITE(mSCTP)INVITE

INVITE(mSCTP) INVITE(mSCTP)INVITE(mSCTP)

INVITE(mSCTP)INVITE(mSCTP)

INVITE(mSCTP)100 trying

100 trying100 trying

183 sp183 sp183 sp

183 sp183 sp

PRACKPRACK

PRACKPRACK

MN PDP Context Activation 200 OK

200 OK

proxy PDP Context Activation

AS PDP Context Activation

200 OK200 OK

Visited IMS Domain 1 Home IMS Domain

REFER (AS)

200 OK

UPDATEUPDATE

180 ringing180 ringing


180 ringing

PRACKPRACK

PRACKPRACK

200 OK200 OK

200 OK200 OK

UPDATE

200 OK200 OK

200 OK200 OK

UPDATE

200 OK200 OK

200 OK200 OK200 OK ACK

ACKACK

ACKACK

mSCTP connection between MN and proxy

TCP/UDPconnectionproxy <> AS

UPDATEUPDATE



180 ringing

PRACKPRACK

PRACKPRACK

200 OK200 OK

200 OK200 OK

UPDATE

200 OK200 OK

200 OK200 OK

UPDATE

200 OK200 OK

200 OK200 OK200 OK ACK

ACKACK

ACKACK

mSCTP connection between MN and proxy

TCP/UDPconnectionproxy <> AS

Fig. 7. mSCTP connection setup between MN, proxy, AS and other components in IMS

After registering with a network, let’s say the visited IMS domain 1 as illustrated on Figure 7, the MN wants to initiate a call to an IPTV Application Server. At this moment the MN does not know the existence of an mSCTPbased proxy, thus it sends an INVITE message with the URI of the service identity (PSI). Since the MN supports mSCTP in the transport layer, it would like to set up an mSCTP connection if possible. In our implementation, instead of sending an INVITE message informing that the expected transport protocol is TCP or UDP, mSCTP is specified in the INVITE message on the VIA header field. Upon receiving the INVITE message, the home SCSCF analyses the message and realizes that the MN requests mSCTP. Instead of forwarding INVITE to the AS, the home SCSCF sends a redirect message “305 use proxy” to the MN,

133



Giang Kỳ Nam

which specifies the URI of the mSCTPbased proxy in the Contact field. The MN then sends INVITE to the proxy, requesting to build an mSCTP transport session between the MN and the mSCTPbased proxy. When the home SCSCF process the redirected INVITE message from the MN, it will also send a REFER to the proxy instructing it to establish a session from the proxy to the AS.Following INVITE messages are QoS provisioning steps. These steps are much like the conventional signaling flow, except that the proxy should set up two sessions: one between MN and the proxy with mSCTP tunnel, and the other between the proxy and the AS. There are three PDP contexts that should be established for the MN, proxy and AS. The session setup procedure in our approach is a bit more complex than usual with 66 messages. In Figure 7, we neglect some messages that do not play significant role in the signaling flow.

3.2. Results

This section highlights some of the various intelligent features implemented in the prototype at our Test-bed. Figure 8 illustrates a personalized user portal which provides a different content meta data (channel list) to different registered user. Figure 8 shows the Parental Control feature in which the child’s request (for a specific online content, like movie) will be accepted or rejected based in different criteria like the acceptance from the parent, the time slot of the request and the category of the requested content.

Fig. 8. Channel List for different User Categories of Enhanced EPG feature

134



Giang Kỳ Nam

Fig. 9. Incoming Call/Message Display

Figure 9 shows feature of blending services that allows displaying the Incoming Call/Message from buddies on the online TV screen if the watching user is not on the “Do not Disturb” mode. The viewer then has options of pausing the TV session to handle the incoming call/message or reject it. Finally, figure 10 shows our proposed architecture for the implementation of (IP TV) session continuity.

Visited IMS domain 2 - WLANVisited IMS domain 1 - UMTS

Home IMS domain

GGSN PDG

AP

P-CSCF

I-CSCF

HSS

GGSN

S-CSCF

AS

MN

mSCTPProxy

P-CSCF

Data path

Signaling path

RNC

Visited IMS domain 2 - WLANVisited IMS domain 1 - UMTS

Home IMS domain

GGSN PDG

AP

P-CSCF

I-CSCF

HSS

GGSN

S-CSCF

AS

MN

mSCTPProxy

P-CSCF

Data path

Signaling path

RNC

Fig. 10. Signaling paths and data paths between MN, mSCTP proxy, AS and IMS components

4. Conclusions and Further Discussions

This paper presents our investigation, in experimental perspective, of using IMS framework to provide intelligent features for IPTV services. In particular, it focuses on the video on demand, remote parental control, blending services, session handover without interruption and other interactive features which some of the use cases were discussed and presented here-above. It shows how SIP [2][7] signaling and IMS can be used to provide the Interactive and Blending features for the entertainment video services.

135



Giang Kỳ Nam

The initial results promise the great potential of those IMS-based TV interactive and differentiated features, which offer attractive and rich multimedia experiences to the end user. We are currently investigating and developing several other intelligent features of IMS-based TV, namely, the context-based session continuity that allows to seamlessly handover the IPTV sessions across different screens/terminals on different access networks

2. Cài đặt Open IMS Core lên UbuntuBước 1: Download Open IMS Core về máy

sudo su (sau đó nhập pass của root để vào quyền root)

apt-get install subversion

mkdir /opt/OpenIMSCore/

chown –R username /opt/OpenIMSCore/

cd /opt/OpenIMSCore

mkdir ser_ims

mkdir FHoSS

svn checkout http://svn.berlios.de/svnroot/repos/openimscore/ser_ims/trunk

ser_ims

svn checkout http://svn.berlios.de/svnroot/repos/openimscore/FHoSS/trunk

FHoSS

Bước 2: Cài đặt các gói yêu cầu

apt-get install sun-java6-jdk mysql-server libmysqlclient15-dev libxml2

libxml2-dev bind9 ant flex bison

Sau đó thiết lập pass cho sql (mysql root password imshut)

Bước 3: Cài đặt DNS

Edit /etc/dhcp3/dhclient.conf và bỏ comment tại dòng:

prepend domain_name_servers 127.0.0.1;

136



Giang Kỳ Nam

cp /opt/OpenIMSCore/ser_ims/cfg/open-ims.dnszone /etc/bind/

Thêm dòng này vào file sau: /etc/bind/named.conf.local

zone "ims.hut.vn" {

type master;

file "/etc/bind/open-ims.dnszone";

};

Cấu hình file open-ims.dnszone thay thế địa chỉ IP

/etc/init.d/bind9 restart

Bước 4: Biên dịch

cd /opt/OpenIMSCore/ser_ims

make install-libs all

java –version (để kiểm tra phiên bản của java)

export JAVA_HOME="/usr/lib/jvm/java-6-sun-1.6.0.03/" (tùy theo phiên

bản ubuntu của người dùng, trong câu lệnh trên là ubuntu 7.10).

cd /opt/OpenIMSCore/FHoSS

ant compile deploy

Bước 5: Thiết lập cơ sở dữ liệu và chạy

cp /opt/OpenIMSCore/ser_ims/cfg/* /opt/OpenIMSCore/

cd /opt/OpenIMSCore

Thay đổi tên miền của IMS core (fresh install) (ims.hut.vn)

./configurator.sh pcscf.cfg icscf.cfg icscf.xml scscf.cfg scscf.xml

ser_ims/cfg/icscf.sql FHoSS/deploy/DiameterPeerHSS.xml

FHoSS/deploy/hss.properties FHoSS/scripts/hss_db.sql

FHoSS/scripts/userdata.sql

137



Giang Kỳ Nam

Thiết lập cơ sở dữ liệu

mysql -uroot -p < ser_ims/cfg/icscf.sql

mysql -uroot -p < FHoSS/scripts/hss_db.sql

mysql -uroot -p < FHoSS/scripts/userdata.sql

Mở terminal và chạy:

./pcscf.sh

./icscf.sh

./scscf.sh

cd FHoSS/deploy

./startup.sh

Nếu gặp vấn đề khi chạy FHoSS thì thiết lập lại biến môi trường

JAVA_HOME bằng cách gõ lại dòng lệnh sau:

export JAVA_HOME="/usr/lib/jvm/java-6-sun-1.6.0.03/"

3. Cài đặt máy chủ ứng dụng sailfin• Yêu cầu tối thiểu để cài đặt là máy phải có jdk1.5 trở lên.

• Download phiên bản miễn phí của sailfin (v1.0 final release)

• Giải và tạo thư mục mới sailfin bằng cách thực hiện lệnh:

% java –Xmx256m –jar filename.jar

• Chuyển đến thư mục sailfin:

% cd sailfin

• Nếu sử dụng máy tính với các hệ điều hành có phân quyền như Unix

thì thực hiện cấp quyền thực thi cho các thư mục bin và sailfin:

138



Giang Kỳ Nam

% chmod –R +x lib/ant/bin

• Tiến hành cài đặt:

o Cho Linux:

% lib/ant/bin/ant –f setup.xml

o Cho Window:

% lib\ant\bin\ant –f setup.xml

4. Cài đặt dịch vụ IPTV lên máy chủ Sailfin

Provisioning FHoSSXem: “Kịch bản demo dịch vụ IPTv”

Povisioning content databaseTại dấu nhắc người dùng gõ lệnh:# mysql –uroot –p < iptv_db.sqlEnter password:# mysql –uroot –p < iptv_media_source.sqlEnter password:

Povisioning Diameter PeerCopy file clientForJ.xml tới thư mục /path/to/sailfin/domains/domain1/config/ Copy toàn bộ các file trong thư mục Libs/diameter/ tới thư mục /path/to/sailfin/domains/domain1/libs/ext/Sửa lại các tham số địa chỉ IP trong file clientForJ.xml cho đúng với hệ thống.

Povisioning User RepositorySử dụng phần mềm DiameterClient, tại terminal gõ lệnh:# java –jar diameterClient.jar upload /path/to/shdata.xml sip:[email protected] iptv

Cấu hình máy chủ IPTVKhởi động Sailfin:#asadmin <enter>#asadmin> start-domain --user admin domain1

Login to administration console at http://localhost:4848139

http://localhost:4848/



Giang Kỳ Nam

User: adminPassword: adminadmin

Tạo JDBC Resources cho MySQL(để kết nối tới máy chủ MySql)

Tải về connector của MySql cho java tại đây MySQL Connector/J .

Copy file mysql-connector-java-5.1.7-bin.jar tới thư mục <sailfin installation dir>/domains/sailfin-cluster-domain/lib/ext và khởi động lại máy chủ Sailfin như trên (asadmin stop-domain <name> followed by asadmin start-domain <name>).

Trong trang chủ quản lý của Sailfin, vào phần

JDBC Connection Pool

Click vào Connection Pools để tạo 1 JDBC Connection pool mới.

140

http://www.mysql.com/products/connector/j

http://alexyu.se/sites/default/files/images/sailfin-admin-jdbc.png



Giang Kỳ Nam

Ấn vào new

Thiết lập tham số: jdbc:mysql://iptv.ims.hut.vn:3306/iptv_db?user=nhong&password=nhong

Ở đây ‘nhong’ là tải khoản truy cập vào mysql server.

141

http://alexyu.se/sites/default/files/images/sailfin-admin-jdbc2.png



Giang Kỳ Nam

Click Finish sau đó chọn lại MySQLPool để kiểm tra xem nó có hoạt động không.

142




Giang Kỳ Nam

Click Ping.

143




Giang Kỳ Nam

Thành công.

144




Giang Kỳ Nam

Cài đặt dịch vụ:

Trong panel bên trái click vào Converged SIP

145




Giang Kỳ Nam

Click deploy, specify chọn file fet_iptv.war và click ok.

Xong!

146



Giang Kỳ Nam

5. Chạy thử với HUT - CommunicatorXem: “Kịch bản demo dịch vụ IPTv”

Kịch bản đê mô dịch vụ IMS based IPTV

Ngữ cảnh:• Có 2 User đăng ký dịch vụ IPTv, 1 là Alice và 2 là con gái của cô, Alice’s

daughter• 2 người đăng ký chung 1 thuê bao IMS có tên là Alice.• Alice đăng ký 1 private user identity là [email protected] và 1 public user

identity kèm theo nó là sip:[email protected].• Con gái của cô Peter được Alice đăng ký 1 private user identity là

[email protected] và 1 public user identity kèm theo là sip:[email protected].

• Việc này được thực hiện thông qua trang cấu hình của FHoSS (HSS provisioning):

Thiết lập dịch vụ Iptv và Parental control:• Tạo Iptv-parental control server:

147





Giang Kỳ Nam

• Tạo Iptv trigger point:

• Tạo Iptv IFC:

• Tạo Iptv service:

148



Giang Kỳ Nam

• Tương tự với Parental control:

149



Giang Kỳ Nam

Như thế chúng ta đã tạo xong 2 gói dịch vụ, 1 là Iptv và gói kia là Parental control, user sử dụng gói Iptv sẽ được xem tất cả các kênh mà IPtv server cung cấp còn user sử dụng dịch vụ Parental control thì chỉ được phép xem 1 số kênh nhất định, nếu yêu cầu xem các kênh ko cho phép server sẽ gửi tin nhắn hỏi quyền truy cập từ 1 user khác.

Sau đây là thiết lập 2 user nói trên với các gói dịch vụ tương ứng: Alice sử dụng dịch vụ Iptv còn con gái cô ấy được đăng ký dịch vụ Parental control. Cả 2 mẹ con đều đăng ký chung 1 IMS subscriber.

150



Giang Kỳ Nam

151



Giang Kỳ Nam

Và chúng ta có subscriber ‘Alice’ như sau :

Với user Alice có sẵn của FHoSS ta sửa lại service profile của user này thành iptv:

Hoạt độngBây giờ chúng ta mở 2 client, 1 client đăng ký với tên Alice và 1 đăng ký với tên Peter, ở đây 2 user được đăng ký trong HUT Communicator

152



Giang Kỳ Nam

Danh sách chương trình của User Alice:

Và danh sách chương trình của user Peter:

153



Giang Kỳ Nam

Danh sách chương trình của user Alice dài hơn và bao gồm cả nhưng kênh người lớn.

Alice xem 1 kênh truyền hình:

154



Giang Kỳ Nam

Peter truy cập vào 1 kênh thuộc diện phải quản lý: hệ thống gửi tin nhắn tới Alice hỏi xem có cho phép hay không.

155



Giang Kỳ Nam

Alice từ chối:

156



Giang Kỳ Nam

Peter truy cập vào 1 kênh khác và lần này Alice cho phép con bà ta xem:

157



Giang Kỳ Nam

Và kết quả:

158



Giang Kỳ Nam

TÀI LIỆU THAM KHẢO

[1] Gonzalo Camarillo & Miguel A.Garcia-Martin, The 3G IP Multimedia

Subsystem Merging The Internet And The Cellular Worlds, Second Edition, John

Wiley & Sons, Ltd, 2006.

[2] Alan B.Johnston, SIP: Understanding the session initiation protocol, second

edition, Artech House telecommunications library, 2004.

[3] Miikka Poikselkä and Georg Mayer, The IMS: IP Multimedia Concepts and

Services, Second Edition, Hisham Khartabil and Aki Niemi © 2006 John Wiley &

Sons, Ltd. ISBN: 0-470-01906-9

[4] Rfc 3725, Best Current Practices for Third Party Call Control (3pcc) in the

Session Initiation Protocol (SIP)

[5] 820-4281, SunGlassFish Communications Server 1.5 AdministrationGuide,

SunMicrosystems, Inc. 4150Network Circle Santa Clara, CA 95054 U.S.A.

[6] Presence, Vishal Kumar Singh and Henning Schulzrinne April 10, 2006,

Columbia Computer Science.

[8] Rfc 3327, Session Initiation Protocol (SIP) Extension Header Field

[9] http://www.iptel.org

[10] http://tech-invite.com

[11] http://uctimsclient.berlios.de

[12] https://sailfin.dev.java.net

[13] http://blogs.sun.com/enterprisetechtips/entry/adding_voice_to_java_ee

[15] http://blogs.voxeo.com/speakingofstandards/tag/sipoint/

159

Documents

Iptv Tren Ims