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 hãng 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 học tập và nghiên cứu về kiến trúc IMS và triển khai các dịch vụ trên

IMS, được sự gợi ý của TS. Nguyễn Tài Hưng em đã lựa chọn đề tài “Nghiên cứu và

khảo sát các công nghệ tiên tiến phục vụ xây dựng nền tảng phát triển ứng dụng cho

các mạng thế hệ mới”.

Em xin chân thành cám ơn TS. Nguyễn Tài Hưng đã giúp đỡ tận tình cho em trong thời

gian làm luận văn vừa qua.

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

Hà Nội, ngày 01 tháng 12 năm 2012

Học viên

Nguyễn Sỹ Thanh Sơn

1

Tóm tắt luận văn

Trong xu thế phát triển của công nghệ nói chung và các mạng viễn thông nói riêng, việc

nghiên cứu phát triển các ứng dụng nhằm thỏa mãn yêu cầu người sử dụng đồng thời có

khả năng tích hợp các nền tảng kỹ thuật mới rất được các nhà khai thác mạng quan tâm.

Sự ra đời của HTML5, CSS3 đã tạo ra cuộc cách mạng lớn cho công nghệ Web. Đi theo

xu hướng phát triển đó, nhiều ý tưởng đã dần được cụ thể hóa bằng các ứng dụng. Trong

số đó, ý tưởng sử dụng nền tảng web cho tất cả các ứng dụng bao gồm cả các ứng dụng

viễn thông như việc gọi điện trực tiếp từ trình duyệt của bạn. Đã có rất nhiều tổ chức, cá

nhân nghiên cứu và xây dựng ứng dụng đó trên nền tảng công nghệ mới HTML5 và IMS.

Nhờ vậy, việc gọi điện trực tiếp từ trình duyệt đã được thực hiện thành công với quy mô

phòng lab, và đang chạy thử nghiệm ở nhiều hệ thống khác nhau.

Nội dung luận văn này sẽ đề cập, nghiên cứu các công nghệ mới như HTML5

WebSocket, IMS. Tất cả các công nghệ đó đều trong quá trình phát triển, và đều là mã

nguồn mở. Luận văn cũng có một ứng dụng chạy thử bằng việc sử dụng các công nghệ

mới đó. Điều đó thể hiện tính khả dụng cũng như định hướng phát triển rất rõ ràng của

các công nghệ mới đó trong tương lai.

2

MỤC LỤC

Tóm tắt luận văn..................................................................................................................2

Mục lục................................................................................................................................3

CHƯƠNG 1. MỞ ĐẦU..................................................................................................7

1.1 Tầm quan trọng của đề tài......................................................................................7

1.2 Nội dung nghiên cứu..............................................................................................8

CHƯƠNG 2. TỔNG QUAN VỀ IMS............................................................................9

2.1 Các yêu cầu đối với IMS........................................................................................9

2.1.1 Phiên đa phương tiện IP..................................................................................9

2.1.2 Chất lượng dịch vụ QoS................................................................................10

2.1.3 Internetworking.............................................................................................10

2.1.4 Chuyển vùng (Roaming)...............................................................................11

2.1.5 Điều khiển dịch vụ.........................................................................................11

2.1.6 Phát triển dịch vụ...........................................................................................11

2.1.7 Đa truy nhập..................................................................................................12

2.2 Tổng quan về các giao thức sử dụng trong IMS..................................................12

2.2.1 Giao thức điều khiển phiên............................................................................12

2.2.2 Giao thức AAA..............................................................................................13

2.2.3 Các giao thức khác........................................................................................14

2.3 Kiến trúc tổng quát IMS.......................................................................................14

2.3.1 Mạng truy nhập.............................................................................................15

2.3.2 Mạng lõi........................................................................................................16

2.3.3 Tầng dịch vụ..................................................................................................25

2.4 Định danh trong IMS...........................................................................................26

2.4.1 Định danh người dùng công cộng.................................................................26

2.4.2 Định danh người dùng riêng..........................................................................28

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

3

2.4.4 Định danh dịch vụ công cộng........................................................................30

2.5 SIM, USIM và ISIM trong 3GPP.........................................................................31

2.5.1 SIM................................................................................................................32

2.5.2 USIM.............................................................................................................32

2.5.3 ISIM...............................................................................................................32

2.6 Tiêu chuẩn lọc......................................................................................................33

2.7 Triển khai kiến trúc IMS......................................................................................38

CHƯƠNG 3. ĐIỀU KHIỂN PHIÊN TRONG IMS......................................................41

3.1 Chức năng của SIP...............................................................................................41

3.1.1 Mô tả phiên và SDP.......................................................................................41

3.1.2 Mô hình Offer/Answer..................................................................................43

3.1.3 SIP và SIPS URIs..........................................................................................44

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

3.2 Cơ bản về SIP.......................................................................................................46

3.2.1 SIP là gì.........................................................................................................46

3.2.2 SIP liên hệ với HTTP như thế nào................................................................47

3.2.3 Bản tin SIP.....................................................................................................49

3.2.4 Phiên giao dịch (Transaction)........................................................................50

3.2.5 Hội thoại (dialog)..........................................................................................52

3.2.6 Trường điều khiển Record-Route, Route và Contact....................................54

CHƯƠNG 4. SIP và Web Application........................................................................56

4.1 HTML5................................................................................................................56

4.2 HTML5 Websocket..............................................................................................57

4.3 SIP over Websocket.............................................................................................63

4.4 WebRTC..............................................................................................................66

4.5 SIPML5................................................................................................................67

4.6 Webrtc2SIP..........................................................................................................68

4.7 Wordpress............................................................................................................71

4.8 Memcached..........................................................................................................72

4

CHƯƠNG 5. Thiết kế, xây dựng ứng dụng trên nền mạng thế hệ mới........................75

5.1 Bài toán thực tế....................................................................................................75

5.2 Tổng quan ứng dụng............................................................................................75

5.2.1 Mục đích........................................................................................................75

5.2.2 Yêu cầu..........................................................................................................76

5.3 Thiết kế ứng dụng quản lý trường học.................................................................77

5.3.1 Lựa chọn công nghệ......................................................................................77

5.3.2 Kiến trúc hệ thống.........................................................................................80

5.3.3 Sơ đồ hoạt động.............................................................................................83

5.3.4 Sơ đồ ca sử dụng...........................................................................................94

5.3.5 Thiết kế ứng dụng trên nền tảng Wordpress.................................................96

5.3.6 Giao diện chương trình..................................................................................98

5.4 Cài đặt, thiết lập Test Bed..................................................................................102

5.4.1 Sơ đồ kiến trúc Test Bed.............................................................................102

5.4.2 Cài đặt OpenIMSCore trên Ubuntu 12.04...................................................103

5.4.3 Cấu hình OpenIMSCore..............................................................................106

5.4.4 Cài đặt WebRTC2Sip..................................................................................107

5.4.5 Thiết lập cấu hình Client.............................................................................110

CHƯƠNG 6. Kết luận và hướng phát triển đề tài.......................................................112

6.1 Kết luận..............................................................................................................112

6.2 Hướng phát triển của đề tài................................................................................113

5

6

CHƯƠNG 1. MỞ ĐẦU

1.1 Tầm quan trọng của đề tài

IMS là 1 công nghệ trong đó hội tụ và triển khai thoại, 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.

Ngày nay, công nghệ web đang phát triển không ngừng, trình duyệt web đã trở nên vô

cùng thân thuộc với tất cả mọi cá nhân sử dụng internet cho mục đích giải trí hay công

việc. Sử dụng công nghệ web để phát triển ứng dụng cũng là các để bỏ qua mối quan ngại

rằng ứng dụng chúng ta đang phát triển được chạy trên platform nào, thiết bị phần cứng

ra sao. Cùng với sự ra đời của HTML5, IMS sẽ giúp chúng ta tiến gần hơn mục đích hội

tụ về công nghệ, hội tụ thiết bị đầu cuối, nhằm thỏa mãn nhu cầu sử dụng của người

dùng. Những câu chuyện nhỏ sau đây sẽ trở nên gần gũi với tất cả chúng ta ở một tương

lại không xa:

“Bạn đang shoping online trên một website thương mại điện tử, và bạn tìm thấy một

chiếc áo lông cừu xinh xắn và ấm áp. Bạn muốn tìm hiểu kỹ hơn về sản phẩm mà bạn

đang định mua để tặng cho bạn gái. Bạn chỉ việc ấn chuột vào số điện thoại của người

7

chủ gian hàng, một cuộc gọi video sẽ được thiết lập ngay lập tức từ trình duyệt web tới

người chủ gian hàng. Bạn sẽ thấy vô cùng thoải mái và tiện lợi. Bởi thay vì phải cầm điện

thoại đọc và ấn từng số một để thực hiện cuộc gọi, thì bây giờ bạn chỉ việc ấn chuột.”

“Cả ngày làm việc mệt mỏi, bạn đang thảnh thơi ngồi xem chương trình tivi buổi tối. Bạn

chợt nhận được cuộc gọi từ một người bạn rủ mình cùng đi shopping online. Trên màn

hình smart phone của bạn xuất hiện lời đề nghị. Bạn đồng ý, và yêu cầu cuộc đàm thoại

qua tivi để tiện theo dõi, và trên màn hình tivi nhà bạn sẽ xuất hiện hình hình ảnh từ siêu

thị online. Bạn cùng với người bạn của mình có thể cùng xem đi xem các gian hàng, cùng

bình luận về cùng một sản phẩm, và có thể đặt mua hàng qua hệ thống. ”

“Bạn có con nhỏ đang học học tiểu học ở một trường bán trú. Công việc bận rộn khiến

bạn không thể ở bên cạnh con suốt cả ngày. Tuy vậy, bạn vẫn có thể cập nhật thông tin,

hình ảnh của con mình thường xuyên. Bạn quay số đến địa chỉ maugiao@ims.hut.vn, trên

màn hình smart phone của bạn xuất hiện danh mục các chức năng trả về, và bạn chọn

xem hình ảnh hiện tại của con mình. Ngay lập tức, hệ thống trả về hình ảnh thu được từ

chiếc camera đặt ở lớp học của con bạn. Và bạn cảm thấy rất hài lòng về dịch vụ …”

Tất nhiên, những câu chuyện nhỏ ở trên chỉ là giả định ở thời điểm hiện tại. Trong một

tương lai rất gần, câu chuyện sẽ trở nên bình thường và gần gũi. Sự phát triển không

ngừng của công nghệ nói chung và nền tảng mạng di động thế hệ mới IMS nói riêng sẽ

tạo nên một cuộc cách mạng dịch vụ, thế giới trở nên nhỏ bé, ngoan ngoãn và sẵn sàng

phục vụ bạn.

1.2 Nội dung nghiên cứu

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.

Điều khiển phiên trong IMS: giới thiệu về giao thức SIP và sử dụng giao

thức SIP trong IMS.

8

HTML5 WebSocket: giới thiệu về giao thức WebSocket

SIP over Websocket: giới thiệu giao thức SIP trên nền WebSocket và cách

các trình duyệt web làm việc với nhau qua bản tin SIP.

Xây dựng ứng dụng tích hợp: xây dựng ứng dụng quản lý đào tạo có tích

hợp chức năng gọi điện thoại từ trình duyệt.

CHƯƠNG 2. TỔNG QUAN VỀ IMS

Trong chương này em xin giới thiệu tổng quan về kiến trúc của IMS cũng như các thành

phần và chức năng của nó. Đồng thời em xin giới thiệu chung về các giao thức sử dụng

trong IMS cũng như các định nghĩa liên quan.

2.1 Các yêu cầu đối với IMS

IMS hướng đến:

Kết hợp các xu thế mới nhất trong công nghệ.

Tạo ra mô hình di động Internet.

Tạo ra nền tảng phổ biến để phát triển các dịch vụ đa phương tiện khác nhau.

Tạo ra cơ chế nâng cao lợi nhuận vì cách sử dụng của mạng chuyển mạch

gói di động.

2.1.1 Phiên đa phương tiện IP

IMS có thể đưa ra một dải rộng các dịch vụ. Mặc dù vậy, có một dịch vụ đặc biệt quan

trọng với người dùng: đó là thông tin liên lạc audio và video. Yêu cầu này nhấn mạnh

đến sự cần thiết hỗ trợ dịch vụ chính được tạo ra bởi IMS: các phiên multimedia qua

mạng chuyển mạch gói. Multimedia có liên quan đến sự tồn tại đồng thời của một vài loại

media, trong trường hợp này là audio và video.

9

Giao tiếp multimedia được chuẩn hóa trong tài liệu 3GPP trước đây, nhưng những giao

tiếp multimedia này diễn ra trên mạng chuyển mạch kênh hơn là trên mạng chuyển mạch

gói.

2.1.2 Chất lượng dịch vụ QoS

Chất lượng dịch vụ (QoS – Quality of Service) là yêu cầu chủ yếu trong IMS. QoS cho

một phiên liên quan được xác định bởi một số nhân tố, như băng thông cực đại có thể cấp

cho người dùng dựa trên thuê bao của người dùng hoặc trạng thái hiện tại của mạng. IMS

cho phép nhà khai thác mạng điều khiển QoS mà người dùng đưa ra, do đó các nhà khai

thác mạng có thể phân biệt các nhóm khách hàng khác nhau.

2.1.3 Internetworking

Hỗ trợ cho tương tác với Internet là một yêu cầu rõ ràng với IMS, Internet đưa ra hàng

triệu đích đến tiềm năng cho các phiên multimedia được khởi tạo trong IMS. Khi tương

tác với Internet, số lượng đích đến tiềm năng cho các phiên đa phương tiện được mở rộng

một cách đột ngột.

IMS cũng được yêu cầu có thể làm việc được với mạng chuyển mạch kênh, như mạng

PSTN (Public Switched Telephone Network), hay các mạng tế bào đang tồn tại. Đầu cuối

IMS có thể kết nối được đến cả mạng chuyện mạch kênh và mạng chuyển mạch gói. Vì

thế, khi người dùng muốn gọi đến điện thoại trong mạng PSTN hay mạng tế bào, đầu

cuối IMS sẽ chọn sử dụng vùng chuyển mạch kênh.

Vì vậy, mặc dù tương tác với mạng chuyển mạch kênh không được yêu cầu một cách

nghiêm ngặt, thì hầu hết các đầu cuối IMS sẽ hỗ trợ vùng chuyển mạch kênh. Yêu cầu hỗ

trợ tương tác với mạng chuyển mạch kênh có thể được coi như là một yêu cầu dài hạn.

Yêu cầu này sẽ được triển khai khi ta xây dựng đầu cuối IMS chỉ hỗ trợ chuyển mạch

gói.

10

2.1.4 Chuyển vùng (Roaming)

Chuyển vùng (roaming) là yêu cầu chung kể từ khi phát minh ra mạng tế bào thứ hai.

Người dùng có thể chuyển vùng sang các mạng khác, ví dụ như khi chuyển sang một

quốc gia khác. Hiển nhiên là IMS sẽ kế thừa yêu cầu này, do đó nó có thể cho phép người

dùng chuyển vùng sang các quốc gia khác nhau.

2.1.5 Điều khiển dịch vụ

Các nhà khai thác mạng muốn áp dụng những chính sách trong việc phân phát dịch vụ

đến người dùng. Chúng ta có thể chia những chính sách đó làm hai loại.

Các chính sách chung có thể áp dụng được cho tất cả người dùng trong

mạng.

Các chính sách cá nhân có thể áp dụng cho một người dùng nhất định.

Loại chính sách đầu tiên bao gồm một tập hợp các giới hạn được áp dụng cho tất cả

người dùng trong mạng. Ví dụ, nhà vận hành mạng có thể muốn giới hạn việc sử dụng

audio codec băng rộng, như G.711 (ITU-T Recommendation G.711), trong mạng của họ.

Thay vì như thế, họ có thể đưa ra các codec băng thông thấp hơn như AMR (Adaptive

Multi Rate).

Loại chính sách thứ hai bao gồm một tập các chính sách được đáp ứng cho mỗi người

dùng. Ví dụ, một người dùng có thể có vài thuê bao để sử dụng các dịch vụ IMS không

bao gồm video. Đầu cuối IMS sẽ hầu hết là có khả năng hỗ trợ video, nhưng trong trường

hợp nỗ lực khởi tạo một phiên multimedia mà có cả video, thì nhà vận hành mạng sẽ

ngăn không cho phiên đó được khởi tạo.

2.1.6 Phát triển dịch vụ

Yêu cầu về tạo ra dịch vụ có ảnh hưởng mạnh trong thiết kế kiến trúc IMS. Yêu cầu này

nói rõ các dịch vụ IMS không cần thiết phải được chuẩn hóa. Yêu cầu này biểu diễn một

dấu mốc trong thiết kế cellualar bởi vì trong quá khứ, mọi dịch vụ đơn đều được chuẩn

11

hóa hoặc là có sự triển khai phù hợp. Thậm chí các dịch vụ được chuẩn hóa thì không có

gì đảm bảo rằng các dịch vụ sẽ làm việc khi chuyển sang một mạng khác.

IMS hướng đến làm giảm thời gian cần thiết khi đưa ra một dịch vụ mới. Trong quá khứ,

việc chuẩn hóa dịch vụ và kiểm tra vận hành gây ra sự chậm trễ lớn, và IMS ra đời sẽ làm

giảm việc chậm trễ đó.

2.1.7 Đa truy nhập

Yêu cầu đa truy nhập ở đây nói đến các phương tiện truy nhập khác hơn GPRS. IMS là

mạng all-IP và cũng như bất kỳ một mạng IP nào khác, nó ở lớp thấp hơn và độc lập truy

nhập. Bất kỳ mạng truy nhập nào về nguyên tắc cũng có thể truy cập đến IMS. Ví dụ,

IMS có thể được truy nhập sử dụng WLAN (Wireless Local Area Network), ADSL

(Asymmetric Digital Subscriber Line), HFC (Hybird Fiber Coax) hoặc là Cable Modem.

Tuy nhiên, 3GPP cam kết phát triển giải pháp cho việc cải tiến GSM, tập trung vào truy

nhập GPRS (cả trong GSM và UMTS, Universal Mobile Telecommunication System)

cho phiên bản đầu tiên của IMS (ví dụ, Release 5). Các phiên bản tiếp theo sẽ nghiên cứu

các truy nhập khác, ví dụ như WLAN.

2.2 Tổng quan về các giao thức sử dụng trong IMS

2.2.1 Giao thức điều khiển phiên

Các giao thức điều khiển cuộc gọi đóng vai trò quan trọng trong bất kỳ một hệ thống điện

thoại nào. Trong mạng chuyển mạch kênh, các giao thức điều khiển cuộc gọi nói chung là

TUP (Telephony User Part), ISUP (ISDN User Part) và BICC (Bearer Independent Call

Control). Các giao thức được xem xét để sử dụng làm giao thức điều khiển phiên cho

IMS hiển nhiên là dựa trên IP. Các giao thức có thể được sử dụng là:

Bearer Independent Call Control (BICC) : BICC là một cải tiến của ISUP. Không như

ISUP, BICC tách biệt mặt phẳng báo hiệu ra khỏi mặt phảng media, do đó báo hiệ có thể

truyền qua một tập các nút riêng biệt chứ không đi qua mặt phẳng media. Thêm nữa,

12

BICC hỗ trợ và có thể chạy trên các công nghệ khác nhau như IP, SS7 (Sinaling System

No. 7) hay ATM (Asynchoronous Transfer Mode).

H.323 : tương tự như BICC, H.323 là giao thức do ITU-T phát triển. H.323 định nghĩa

một giao thức mới để thiết lập phiên multimedia. Không như BICC, H.323 được thiết kế

từ những ngày đầu tiên nhằm hỗ trợ công nghệ IP. Trong H.323, báo hiệu và media

không cần truyền qua cùng một tập các host.

SIP (Session Initiation Protocol) : được đặc tả bởi IETF như là một giao thức để thiết

lập và quản lý các phiên multimedia qua mạng IP. SIP tuân theo mô hình client-server

nổi tiếng, mô hình được sử dụng bởi nhiều giao thức được phát triển bởi IETF. Các nhà

thiết kế SIP đã mượn nguyên lý thiết kế từ SMTP (Simple Mail Transfer Protocol) và đặc

biệt là HTTP (Hypertext Transfer Protocol). SIP kế thừa hầu hết các đặc điểm của nó từ

hai giao thức trên. Đó là một điểm mạnh của SIP bởi vì HTTP và SMTP là những giao

thức thành công nhất trên Internet. SIP không giống như BICC và H.323, SIP là giao thức

dựa trên text. Điều đó có nghĩa là nó dễ dàng để mở rộng, sửa lỗi và sử dụng để xây dựng

các dịch vụ.

SIP được chọn làm giao thức điều khiển phiên trong IMS. Thực tế SIP làm cho việc tạo

ra các dịch vụ mới trở nên dễ dàng và vì SIP dựa trên HTTP nên các nhà phát triển dịch

vụ SIP có thể sử dụng tất cả các cơ chế được phát triển cho HTTP như CGI (Common

Gateway Interface) và Java Servlet.

2.2.2 Giao thức AAA

Ngoài giao thức điều khiển phiên thì còn có một số giao thức khác đóng vai trò quan

trọng trong IMS. Diameter (là giao thức được định nghĩa trong RFC 3588) được chọn

làm giao thức AAA (Authentication, Authorization, and Accounting) trong IMS.

Diameter là một cải tiến của RADIUS (được định nghĩa trong RFC 2865), đó là một giao

thức được sử dụng rộng rãi trong Internet để thực hiện AAA. Ví dụ, khi người dùng quay

số đến nhà cung cấp dịch vụ Internet thì server truy nhập mạng sử dụng RADIUS để

13

chứng thực (authenticate) và cấp quyền (authorize) cho người dùng truy cập mạng.

Diameter bao gồm một giao thức cơ bản được bổ sung với ứng dụng Diameter. Các ứng

dụng Diameter là sự lựa chọn hoặc mở rộng Diameter để phù hợp với một ứng dụng cụ

thể trong một môi trường. IMS sử dụng Diameter trong một số giao diện, mặc dù không

phải tất cả các giao diện sử dụng cùng một ứng dụng Diameter. Ví dụ, IMS định nghĩa

ứng dụng Diameter để tương tác với SIP trong quá trình phiên được thiết lập và một ứng

dụng khác để thực hiện điều khiển tài khoản.

2.2.3 Các giao thức khác

Cùng với SIP và Diameter là các giao thức khác được sử dụng trong IMS. Giao thức

COPS (Common Open Policy Service) được sử dụng để truyền các chính sách giữa các

PDP (Policy Decision Points) và PEP (Policy Enforcement Points). H.248 và các gói của

nó được sử dụng bởi các nút tín hiệu điều khiển trong mặt phẳng media. H.248 được phát

triển bởi ITU-T và IETF cũng được đề cập đến như là giao thức MEGACO (Media

Gateway Control). RTP (Real-time Transport Protocol) và RTCP (RTP Control Protocol)

được sử dụng để truyền dữ liệu thời gian thực như video và audio.

2.3 Kiến trúc tổng quát IMS

Trướ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ể.

14

Hình 2-1: Tổng quan 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.3.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 (UE). Đầ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

15

khác. Thiết bị hỗ trợ cá nhân PDAs và máy tính là 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.3.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 như 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.3.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 là sự phát triển của 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 Location Function). Mặt khác, mạng với nhiều hơn một HSS

yêu cầu có SLF.

16

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.3.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 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 đăng

ký vớ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.

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.

17

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 chức năng 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 đượ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 I-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.

18

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.

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-

19

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.3.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 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.3.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à

20

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.3.2.5 PSTN/CS Gateway

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

21

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 [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

22

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.3.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 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á cuowics 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.

23

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.

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ủ

24

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 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.3.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

Click to dial

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

25

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.4 Định danh trong IMS

Trong 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.4.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ư đị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

26

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:first.last@operator.com, 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:+1-212-555-0293@operator.com;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 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

27

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.4.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à: username@operator.com.

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.4.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 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

28

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 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).

29

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.4.4 Định danh dịch vụ công cộng

2.4.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.

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.

30

2.4.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!.*!@example.com”.

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!.*!@example.com”. Khi chứa trong HSS:

sip:chatlist1@example.com

sip:chatlist2@example.com

sip:chatlist42@example.com

sip:chatlistabc@example.com

sip:chatlist!1@example.com

2.5 SIM, USIM và ISIM trong 3GPP

UICC (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 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.

31

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.5.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.5.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.5.3 ISIM

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

32

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.6 Tiêu chuẩn lọc

Tiê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 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.

33

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.

34

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ý.

35

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

36

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:user@example.com)

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

sip:user@example.com.

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.

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.

37

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 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.7 Triển khai kiến trúc IMS

Kiến trúc IMS được triển khai trong đề tài:

38

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ụ.

o Phát triển các dịch vụ Click-to-dial, 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:

39

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 tác thoại (IVR).

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:

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ụ.

Như vậy qua chương này ta đã thấy rằng kiến trúc IMS là một kiến trúc mới có khả năng

kết nối với tất cả các loại mạng hiện nay. Điều này giúp cho IMS có khả năng cung cấp

nhiều dịch vụ mà không cần quan tâm đến mạng truy nhập. IMS dựa trên giao thức báo

hiệu chính là giao thức SIP với ưu điểm là đơn giản nhưng rất mạnh. Điều này chúng ta

sẽ được thấy rõ hơn trong chương 3 dưới đây

40

CHƯƠNG 3. ĐIỀU KHIỂN PHIÊN TRONG IMSTrong chương này em xin giới thiệu chi tiết hơn về giao thức SIP cũng như cách

thức mà SIP điều khiển các phiên làm việc trong IMS.

3.1 Chức năng của SIP

3.1.1 Mô tả phiên và SDP

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.

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ề

41

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.

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

42

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ã…

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.

43

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:hoang.danghuy@ims.hut.vn

sip:thien.nguyenduc@ims.fet.hut

sip:asims@hut.edu.vn;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:

sips:son.dinhngoc@ims.fet.hut

sips:hoang.daoxuan@ims.hut.vn

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

sip:Alice.Smith@domain.com

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à

44

sip:asmith@ws1234.company.com

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

sip:alice@pc12.university.edu

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

sip:Alice.Smith@domain.com

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:Alice.Smith@domain.com sẽ được quản lý bởi SIP registrar tại domain.com.

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ủ

45

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 Cơ bản về SIP

3.2.1 SIP là gì

SIP là một giao thức báo hiệu thường được sử dụng để thiết lập, chỉnh sửa, và kết

thúc một phiên giữa hai điểm đầu cuối. SIP có thể được sử dụng để thiết lập một cuộc gọi

giữa hai bên, một cuộc gọi nhiều bên, hoặc một phiên multicast cho các cuộc gọi Internet,

các cuộc gọi đa phương tiện và phân phối đa phương tiện.

Một cách đơn giản để mô tả SIP là xem xét một mô hình sử dụng. Giả sử một

người dùng có định danh là A muốn thiết lập cuộc gọi với người dùng có định danh là B.

Trong viễn thông, người dùng A và người dùng B có thể giao tiếp thông qua một thiết bị

được gọi là tác nhân người dùng (User Agent). Một ví dụ về User Agent là một soft

phone, một chương trình phần mềm sử dụng để thiết lập cuộc gọi điện thoại qua Internet.

Một ví dụ khác là VoIP Phone, một loại điện thoại cho phép sử dụng VoIP (Voice over

IP). Dưới đây là các bước cần thiết để thiết lập một cuộc gọi:

A mời B bắt đầu cuộc hội thoại. Như một phần của lời mời, A sẽ chỉ ra loại

media nào sẽ được hỗ trợ.

B nhận lời mời, gửi đáp ứng trung gian tới người dùng A, và sau đó đánh

giá lời mời.

Khi B sẵn sàng chấp nhận lời mời, nó gửi một xác nhận lại cho người dùng

A. Như một phần của xác nhận, B cũng chỉ ra loại media mà nó hỗ trợ.

A kiểm tra xác nhận mà nó nhận được từ B và quyết định xem liệu media

hỗ trợ bởi A và B có giống nhau không. Nếu A và B hỗ trợ cùng một loại media, cuộc gọi

sẽ được thiết lập giữa A và B.

46

Hình 3-14: 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.2.2 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, UDP, SCTP như là các giao thức nền của lớp dưới.

47

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ó.

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.

48

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.2.3 Bản tin SIP

Cấu trúc của bản tin SIP:

49

Hình 3-15: 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.2.4 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.

50

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 đó.

51

Hình 3-16: Transaction

3.2.5 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 không các user agent sẽ xử lý nó như là các

52

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-17: Luồng cuộc gọi trong một hội thoại SIP

Một vài bản tin dùng để thiết lập ra một dialog. Nó cho phép biểu diễn rõ ràng, chi

tiết mối quan hệ giữa các bản tin và còn dùng để gửi bản tin mà không liên quan đến các

bản tin khác đến các bản tin nằm ngoài một dialog. Điều đó được thực hiện một cách dễ

dàng bởi user agent không lưu trạng thái của dialog.

Lấy ví dụ, bản tin INVITE thiết lập một dialog, bởi sau đó sẽ có bản tin yêu cầu

BYE dùng để kết thúc dialog tạo ra bởi bản tin INVITE ở trên. Bản tin BYE này được

gửi bên trong dialog được thiết lập bởi bản tin INVITE.

53

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.2.6 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.

54

Hình 3-18: Cách sử dụng Record-Route, Route và Contact

55

CHƯƠNG 4. SIP và Web Application

4.1 HTML5

HTML5 là một ngôn ngữ được thiết kế để thiết lập nội dung web. Nó nhằm làm cho việc

thiết kế và phát triển web dễ dàng hơn bằng cách tạo một giao diện ngôn ngữ đánh dấu

chuẩn hóa và trực quan. HTML5 cung cấp các phương tiện phân tích và phân định các

trang của bạn, và nó cho phép bạn tạo các thành phần rời rạc không chỉ được thiết kế để

cấu tạo trang web của bạn một cách hợp lý mà còn được tạo ra để cung cấp cho trang web

của bạn các khả năng cung cấp thông tin. HTML5 có thể được gọi là “cách tiếp cận lập

bản đồ thông tin để thiết kế trang web” do nó kết hợp yếu tố cơ bản về lập bản đồ thông

tin, phân chia và ghi nhãn thông tin giúp dễ dàng sử dụng và hiểu thông tin. Đây là nền

tảng của tiện ích ngữ nghĩa và thẩm mỹ gây ấn tượng sâu sắc

của HTML5. HTML5 cung cấp khả năng xuất bản tất cả mọi thứ trên thế giới từ nội

dung văn bản đơn giản đến đa phương tiện phong phú, tương tác cho các nhà thiết kế và

các nhà phát triển ở mọi trình độ.

HTML5 cung cấp các công cụ quản lý dữ liệu, vẽ, video, và âm thanh có hiệu quả. Nó

tạo điều kiện cho sự phát triển của các ứng dụng giữa các trình duyệt với nhau cho trang

web cũng như cho các thiết bị di động.HTML5 là một trong những công nghệ thúc đẩy

những cải tiến trong các dịch vụ điện toán đám mây di động, vì nó tính đến tính linh hoạt

rộng hơn, cho phép phát triển các trang web thú vị và có khả năng tương tác. Nó cũng

đưa vào thẻ và các cải tiến mới, bao gồm cấu trúc thu nhỏ, các nút điều khiển của biểu

mẫu, các API, đa phương tiện, hỗ trợ cơ sở dữ liệu, và tốc độ xử lý nhanh hơn đáng kể.

56

4.2 HTML5 Websocket

Đặc điểm kỹ thuật HTML5 Websocket định nghĩa một API cho phép các trang web sử

dụng giao thức Websocket để kết nối 2 chiều với máy chủ từ xa. Nó giới thiệu về giao

diện Websocket và định nghĩa một kênh kết nối full-duplex hoạt động qua một socket

trên nền web. HTML5 Websocket ra đời nhằm giảm một lượng lớn lưu lượng không cần

thiết.

WebSoket là công nghệ hỗ trợ giao tiếp hai chiều giữa client và server bằng cách sử dụng

một TCP socket để tạo một kết nối hiệu quả và ít tốn kém. Mặc dù được thiết kế để

chuyên sử dụng cho các ứng dụng web, lập trình viên vẫn có thể đưa chúng vào bất kì

loại ứng dụng nào.

57

Dữ liệu truyền tải thông qua giao thức HTTP (thường dùng với kĩ thuật Ajax) chứa nhiều

dữ liệu không cần thiết trong phần header. Một header request/response của HTTP có

kích thước khoảng 871 byte, trong khi với WebSocket, kích thước này chỉ là 2 byte (sau

khi đã kết nối).

Vậy giả chúng ta làm một ứng dụng game có thể tới 10,000 người chơi đăng nhập cùng

lúc, và mỗi giây họ sẽ gửi/nhận dữ liệu từ server. Hãy so sánh lượng dữ liệu header mà

giao thức HTTP và WebSocket trong mỗi giây:

- HTTP: 871 x 10,000 = 8,710,000 bytes = 69,680,000 bits per second (66 Mbps)

- WebSocket: 2 x 10,000 = 20,000 bytes = 160,000 bits per second (0.153 Kbps)

Như chúng ta thấy chỉ riêng phần header thôi cũng đã chiếm một phần lưu lượng đáng kể

với giao thức HTTP truyền thống.

HTML5 WebSocket hỗ trợ tính năng bảo mật như proxy và firewall, hỗ trợ streaming

trên nhiều kết nối, và có cả khả năng upstream và downstream trên một kết nối đơn,

HTML5 WebSocket giảm tải cho server, cho phép các máy hiện tại hỗ trợ nhiều kết nối

đồng thời. Hình minh họa ở dưới mô tả kiến trúc của kết nối full-duplex của WebSocket,

kết nối với máy chủ từ xa.

58

Một trong những tính năng độc đáo của WebSocket là cung cấp khản năng đi qua tường

lửa và proxy, một vấn đề của rất nhiều ứng dụng hiện nay. Các ứng dụng Comet thông

thường sử dụng long-polling (Ajax) như một đường thô sơ, bỏ qua tường lừa và proxy.

Công nghệ là hiệu quả, tuy nhiên không phù hợp với các ứng dụng yêu cầu độ trễ 500

phần nghìn giây hoặc băng thông lớn. Các công nghệ khác sử dụng plugin như Adobe

Flash cũng cung cấp một vài mức socket, nhưng gặp vấn đề proxy và đi qua tường lửa.

Và bây giờ, WebSocket giải quyết tất cả các vấn đề đó.

WebSocket dò sự hiện diện của proxy server và tự động thiết lập một tunnel (đường

ngầm) đi qua proxy. Đường ngầm được thiết lập bằng cách phát hành một HTTP

CONNECT tới proxy server yêu cầu proxy server mở kết nối TCP/IP với host và post cụ

thể. Khi đó, proxy sẽ không cản trở kết nối đã được thiết lập. HTTP và HTTPS hoạt động

theo cách tương tự, WebSocket bảo mật qua SSL có thể tận dụng cùng một HTTP

CONNECT. Hiện tại WebSocket chỉ mới được hỗ trợ bởi các trình duyệt hiện đại

59

(Chrome, Firefox Nighty). Tuy nhiên, các trình duyệt đang phát triển và sẽ tương thích

trong thời gian tới.

WebSocket cũng giống như các phần khác của HTML5 như Local Storage và

Geolocation, tất cả đều là đặc tính kỹ thuật cơ bản của HTML5, nhưng đã được chuyển

vào tài liệu tiêu chuẩn riêng để tập trung hơn vào các đặc tính kỹ thuật. WebSocket đã

được đệ trình bởi tổ chức Internet Engineering Task Force (IETF), Hypertext Application

Technology Working Group (WHATWG).

Giao thức WebSocket

Giao thức WebSocket là được thiết kế để có thể làm việc tốt nên kiến trúc Web hiện tại.

Một phần của nguyên lý thiết kế này, tài liệu kỹ thuật của giao thức định nghĩa rằng kết

nối WebSocket bắt đầu và tồn tài như một kết nối HTTP, đảm bảo đầy đủ khản năng

tương thích ngược vởi phiên bản WebSocket trước đó. Giao thức chuyển từ HTTP qua

WebSocket thông qua bước WebSocket bắt tay.

Trình duyệt gửi yêu cầu đến server, chỉ ra rằng nó muốn chuyển từ HTTP qua

WebSocket. Phần header của bản tin đó được mô tả như sau:

GET ws://echo.websocket.org/?encoding=text HTTP/1.1 Origin: http://websocket.org Cookie: __utma=99as Connection: Upgrade Host: echo.websocket.org Sec-WebSocket-Key: uRovscZjNol/umbTt5uKmw== Upgrade: websocket Sec-WebSocket-Version: 13

Nếu server hiểu giao thức WebSocket, nó đồng ý chuyển giao thức qua bản tin sau:

HTTP/1.1 101 WebSocket Protocol Handshake Date: Fri, 10 Feb 2012 17:38:18 GMT Connection: Upgrade Server: Kaazing Gateway Upgrade: WebSocket Access-Control-Allow-Origin: http://websocket.org

60

Access-Control-Allow-Credentials: true Sec-WebSocket-Accept: rLHCkw/SKsO9GAH/ZSFhBATDKrU= Access-Control-Allow-Headers: content-type

Từ điểm này, kết nối HTTP bị phá vỡ và thay thể bởi kết nối WebSocket trên cùng một

kết nối TCP/IP cơ bản. Trong trường hợp mặc định, kết nối WebSocket sử dụng cùng

một cổng như HTTP(80) và HTTPS(443).

Ngay khi thiết lập, frame dữ liệu Websocket được gửi qua lại giữ máy khách và máy chủ

theo chế độ full-duplex. Cả frame văn bản và nhị phân có thể gửi theo hai hướng cùng

một lúc. Dữ liệu là được đóng khung tối thiểu với 2 byte. Trong trường hợp frame văn

bản, mỗi frame bắt đầu với byte 0x00, kết thúc với byte 0xFF, và chứa dữ liệu UTF-8 ở

giữa. WebSocket frame văn bản sử dụng terminator, trong khi frame nhị phân sử dụng

tiền tố chiều dài.

Sử dụng HTML5 WebSocket API

Với việc giới thiệu một giao diện gọn gàng, người phát triển có thể thay thế các công

nghệ như long-polling và “forever frames”, kết quả sẽ giảm được độ trễ.

[Constructor(in DOMString url, optional in DOMString protocol)]

interface WebSocket { readonly attribute DOMString URL; // ready state

const unsigned short CONNECTING = 0;

const unsigned short OPEN = 1;

const unsigned short CLOSED = 2;

readonly attribute unsigned short readyState;

readonly attribute unsigned long bufferedAmount;

// networking attribute Function onopen; attribute Function onmessage;

61

attribute Function onclose;

boolean send(in DOMString data);

void close(); };

WebSocket implements EventTarget;

Việc sử dụng giao diện WebSocket không thể đơn giản hơn. Để kết nối tới một điểm

cuối, chỉ cần tạo mới một WebSocket instance, cung cấp đối tượng mới với một URL của

điểm cuối cái mà bạn muốn kết nối, đoạn mã dưới là một ví dụ. Chú ý rằng tiền tố ws://

và wss:// chỉ ra việc sử dụng kết nối WebSocket hay WebSocket Secure.

var myWebSocket = new WebSocket("ws://www.websockets.org");

Một kết nối WebSocket được thiết lập bởi việc chuyển từ giao thức HTTP tới giao thức

WebSocket thông qua biệc bắt tay giữa client và server. Qua giao diện WebSocket chúng

ta sử dụng hàm “onmessage” và “send”.

Trước khi kết nối tới điểm cuối và gửi bản tin, bạn có thể liên kết với một loạt các sự kiện

listener để nắm bắt các phase của vòng kết nối như ví dụ dưới đây.

myWebSocket.onopen = function(evt) { alert("Connection open ..."); };

myWebSocket.onmessage = function(evt) {

alert( "Received Message: " + evt.data);

};

myWebSocket.onclose = function(evt) { alert("Connection closed."); };

Để gửi bản tin tới server, chỉ cần gọi hàm “send” và cung cấp nội dung bạn muốn gửi.

Sau khi gửi bản tin, gọi hàm “close” để kết thúc kết nối, như ví dụ dưới. Bạn có thể thấy

rằng nó không thể dễ dàng hơn.

myWebSocket.send("Hello WebSockets!"); myWebSocket.close();

62

4.3 SIP over Websocket

Websocket[RFC6455] là một giao thức tin cậy và vì vậy giao thức con SIP WebSocket

được định nghĩa là một giao thức SIP chuyển vận tin cậy. Vì vậy, client và server giao

tiếp qua WebSocket để chuyển vận phải theo thủ tục và trình tự của giao thức chuyển vận

tin cậy được định nghĩa ở [RFC3261].

Mỗi bản tin SIP chỉ được mang trong một bản tin WebSocket, và một bản tin WebSocket

không được chứa hơn nhiều hơn một bản tin SIP, vì tầng chuyển vận WebSocket duy trì

các bản tin ranh giới, việc sử dụng tiêu đề Content-Length trong bản tin SIP là tùy biến

khi chúng được chuyển vận qua giao thức WebSocket.

Việc phân tích bản tin SIP được đơn giản hóa cho cả client và Server. Không cần thiết lập

bản tin biên sử dụng tiêu đề Content-Length giữa các message. Các chuyển vận SIP khác

như UDP và SCTP [RFC4168] cung cấp thông tin này.

Hình ảnh dưới đây là một ví dụ cho bản tin REGISTER của SIP, thông qua chuyển vận

WebSocket.

Bản tin F1 và F2 có nội dung như sau:

63

Bản tin F3 – SIP REGISTER REQUEST:

Bản tin F4 – SIP 200 OK:

64

Và kết quả được môt tả qua ví dụ sau:

65

4.4 WebRTC

WebRTC là miễn phí, dự án mở cho phép trình duyệt giao tiếp thời gian thực (Real-Time

Communication – RTC) qua Javascript API đơn giản. Thành phần WebRTC được tối ưu

để phục vụ tốt nhật mục đích của nó.

Nhiệm vụ của WebRTC: cho phép các ứng dụng thời gian thực chất lượng cao, dung

lượng lớn qua trình duyệt với Javascript đơn giản và HTML5.

Hiện tại WebRTC đã được đưa vào Chrome và được hỗ trợ bởi Google, Mozilla và

Opera.

Kiến trúc tổng quan của WebRTC như sau:

66

4.5 SIPML5

SIMML5 là HTML5 SIP client mã nguồn mở đầu tiên trên thế giới, toàn bộ được viết

bằng Javascript, được sử dụng để tích hợp vào các mạng xã hội (facebook, twitter,

google+), game online, website thương mại điện tử …, hoàn toàn không cần thêm bất kỳ

module mở rộng, plugin hay gateway nào khác. Giao tiếp media qua WebRTC. Chúng ta

hoàn toàn có thể sử dụng SIPML5 để kết nối tới bất kỳ một mạng IMS nào hoặc thiết bị

đầu cuối SIP khác. Từ trình duyệt web của mình, chúng ta có thể thực hiện hoặc nhận

cuộc gọi audio/video hoặc nhắn tin.

Toàn bộ chồng giao thức SIP và SDP được viết bằng javascript và sử dụng giao thức

chuyển vận websocket theo tiêu chuẩn được mô tả trong tài liệu sơ bộ draft-ibc-sipcore-

sip-websocket của IETF.

Danh sách các đặc tính được hỗ trợ bởi SIMML5:

Làm việc trên Chrome, Firefox, IE, Safari, Opera và Bowser

Gọi Audio / Video

Nhắn tin

Presence

Call Hold / Resume

Call transfer

Hỗ trợ nhiều tài khoản, nhiều cuộc gọi đồng thời

Báo hiệu Dual-tone multi-frequency (DTMF) sử dụng SIP INFO

67

Dữ liệu media phục thuộc vào WebRTC (Web Real Time Communication) được hỗ trợ

bởi một vài trình duyệt. SIPML5 có thể làm việc tốt trên tất cả các trình duyệt có hỗ trợ

WebRTC như Google Chrome hoặc Firefox Nightly.

Sử dụng SIPML5 kết hợp với WebRCT2Sip, chúng ta có thể thực hiện được các cuộc gọi

từ trình duyệt vào các mạng viễn thông PSTN.

Các giao diện lập trình của SIPML5 được thiết kế để dễ dàng sử dụng nhất cho các nhà

phát triển. Việc sử dụng và tích hợp SIPML5 vào ứng dụng có thể được thực hiện chỉ một

vài dòng code.

4.6 Webrtc2SIP

Webrtc2SIP là một gateway mạnh mẽ và thông minh sử dụng WebRTC và SIP.

Webrtc2SIP cho phép trình duyệt thực hiện và nhận mọi cuộc gọi từ các mạng SIP-legacy

hoặc PSTN.

Cho ví dụ, chúng ta có thể thực hiện các cuộc gọi từ trình duyệt web đến một Softphone

(X-Lite) hoặc mobile, fixed phone.

Webrtc2sip có 3 module: SIP Proxy, RTCWeb Breaker, Media Coder.

68

SIP Proxy

Vai trò của module SIP Proxy là để chuyển từ SIP trên giao thức WebSocket qua UDP,

TCP hoặc TLS được hỗ trợ bở tất cả các mạng. Nếu nhà cung cấp hoặc máy chủ có hoox

trợ SIP trên WebSocket (như Asterisk hoặc Kamailio) thì chúng ta có thể bỏ qua chức

năng này mà kết trực tiếp để client khác. Nếu chúng ta cần sử dụng 2 module RTCWEB

Breaker hoặc Media Coder cho việc duy trì kết nối thì chúng ta nên sử dụng module SIP

Proxy cho kết nối đó.

Nếu sử dụng SIP Proxy thì chúng ta không cần quan tâm đến các điểm kết nối khác.

 

SIP Proxy architecture

RTCWeb Breaker

Đặc tính kỹ thuật của RTCWEB hỗ trợ cho ICE và DTLS/SRTP. Trong khi các chuẩn

viễn thông hiện tại (ví dụ: mạng PSTN) không hỗ trợ đặc tính đó. RTCWEB Breaker

69

được sử dụng để bắt tay, thiết lập và chuyển đổi luồng media để trình duyệt và các hệ

thống viễn thông có thể làm việc được với nhau.

RTCWeb Breaker architecture

Media Coder

Chuẩn RTCWeb định nghĩa 2 chuẩn MTI (Mandatory To Implement) audio codecs sau:

Opus và g.711.

Ngày nay, đã có nhiều cuộc thảo luận về chuẩn MTI video codecs. Hai chuẩn video

codecs được lựa chọn là VP8 và H.264. VP8 là miễn phí tiền bản quyền nhưng không

được triển khai rộng rãi, trong khi H.264 AVC lại không miễn phí nhưng được phổ biến

rộng rãi. Google đã quyết định chọn VP8 cho Chrome trong khi Ericsson sử dụng H.264

AVC cho Bowser. Mozilla và Opera Software rất có thể sẽ sử dụng VP8 và Microsoft

H.264 AVC. Cho một ví dụ, Media Coder sẽ cho phép thực hiện cuộc gọi video giữa

Chrome và Bowser. Một ví dụ khác là chúng ta có thể thực hiện cuộc gọi tự hệ thống

Telepresence sử dụng H.264 AVC từ trình duyệt Chrome.

Media Coder architecture

70

4.7 Wordpress

WordPress là phần mềm mã nguồn mở được cung cấp miễn phí, sử dụng ngôn ngữ lập

trình PHP và hệ cơ sở dữ liệu MySQL. Tuy nhiên khi bạn sử dụng và thay đổi nội dung

bên trong cấu trúc của nó phải thực hiện đúng luật, tiêu chuẩn của GNU General Public

License.

Mục đích ban đầu của Wordpress là để sử dụng cho các blogger. Tuy nhiên, từ phiên bản

2.6 đến nay, Worpress đã mở rộng rất nhiều tính năng cũng như khản năng tùy biến. Hiểu

biết càng sâu về Wordpress chúng ta có thể sử dụng nó như một CMS thực sự, và hơn thế

nữa.

Tên gọi WordPress được đề xuất bởi Christine Selleck, một người bạn của nhóm trưởng

Matt Mullenweg.

71

4.8 Memcached

Memcached là hệ thống caching đối tượng bộ nhớ phân tán, hiệu năng cao, miễn phí và

mã nguồn mở. Memcached được sử đụng dể tăng tốc độ ứng dụng web động bằng các

giảm tải cho cơ sở dữ liệu.

72

Memcached lưu trữ dữ liệu vào bộ nhớ dưới dạng key-value và chia dữ liệu thành các

chunk nhỏ.

Mecached là đơn giản nhưng mạnh mẽ. Sự thiết kế đơn giản dẫn tới việc triển khai

nhanh, dễ dàng phát triển, và giải quyết nhiều vấn đề của dữ liệu cache lớn. Nó có đầy đủ

các API cho hầu hết các ngôn ngữ lập trình phổ biến.

Trong thế giới điện toán máy tính, Memcached là một hệ thống caching bộ nhớ phân tán.

Ban đầu, nó được phát triển bởi công ty Danga Interactive cho LiveJournal. Nhưng ngày

nay, nó được sử dụng ở rất nhiều các site khác. Memcached được sử dụng để tăng tốc độ

các ứng dụng web động bằng cách caching dữ liệu và đối tượng vào RAM để giảm sô lần

truy xuất vào dữ liệu nguồn (như là cơ sở dữ liệu hoặc API). Memcached chạy trên Unix,

Linux, Widows và Mac OS X dưới sự cấp phép miễn phí bản quyền.

Các API của Memcached cung cấp một lương khổng lổ các bảng băm qua nhiều máy.

Khi bảng đầy, dữ liệu tiếp theo được chèn sẽ làm các dữ liệu cũ bị thanh lọc theo thứ tự

sử dụng. Các ứng dụng sử dụng Memcached để lấy và thêm dữ liệu vào RAM trước khi

gửi yêu cầu tới tầng lưu trữ chậm hơn như cơ sở dữ liệu.

Memcached được sử dụng bởi rất nhiều hệ thống lớn hiện tại bao gồm YouTube, Reddid,

Zynga, Facebook, Orange, Twitter và Wikipedia. Heroku đưa ra một dịch vụ quản lý

memcached xây dựng trên Couchbase Server như một của PAAS. Google App Engine,

AppScale, Windows Azure và Amazon Web Services cũng xây dựng dịch vụ memcached

qua một API.

Memcached là được phát triển lần đầu tiên bởi Brad Fitzpatrick cho website LiveJournal,

vào ngày 22 tháng 5 năm 2003.

Memcached hoạt động theo kiến trúc client-server. Các server duy trì một mảng liên kết

key-value; các client sử dụng mảng này để lấy dữ liệu của nó. Các key có thể lưu trữ tối

đa với 250 byte và dữ liệu có thể lên tới 1 Mebabyte.

73

Client sử dụng các thư viện để liên kết với server, ở chế độ mặc định, mecached sử dụng

cổng giao tiếp dịch vụ 12111. Mỗi client biết tất cả server, các server không liên kết với

nhau. Nếu một client muốn ghi hoặc đọc giá trị tương ứng với một key nào đó, thư viện

của client sẽ tính giá trị băm đầu tiên của key để xác định server sẽ sử dụng. Sau đó nó sẽ

thiết lập phiên làm việc với server đó. Server sẽ tính giá trị băm thứ 2 của key để xác định

nơi lưu trữ giá trị dữ liệu tương ứng.

Các server lưu các giá trị dữ liệu vào RAM; nếu dung lượng RAM bị đầy, nó sẽ loại bỏ

các giá trị cũ nhất. Vì vậy, client phải cư xử với Memcached như một bộ nhớ cache tạm

thời; chúng không thể cho rằng dữ liệu lưu trữ trong Memcached vẫn ở đó khi chúng cần

nó. MemcachedDB và Couchbase Server cung cấp lưu trữ liên tục trong khi vẫn duy trì

khản năng tương thích với giao thức memcached.

74

CHƯƠNG 5. Thiết kế, xây dựng ứng dụng trên nền

mạng thế hệ mới

5.1 Bài toán thực tế

Giáo dục luôn là vấn đề đáng được quan tâm. Việc ứng dụng công nghệ vào việc quản lý

đào tạo và dạy học mang lại ý nghĩa rất to lớn. Đã có rất nhiều các phần mềm, hoặc hệ

thống phần mềm được xây dựng và triển khai ở nhiều trường đại học, trung học và tiểu

học. Những hệ thống đó đã góp phần không nhỏ vào sự phát triển của giáo dục.

Trong xu thế phát triển không ngừng của công nghệ, các phần mềm giáo dục luôn được

cải tiến, mở rộng, thay thế hoặc nâng cấp để đáp ứng nhiều hơn nữa những nhu cầu thiết

thực công việc quản lý đào tạo, dạy và học.

Với cấp bậc tiểu học, việc quản lý đào tạo không chỉ cho học sinh và nhà trường mà còn

cho cả các cấp bậc phụ huynh. Do vậy, những ứng dụng này vừa phải đáp ứng được các

yêu cầu của một hệ thống quản lý đào tạo vừa phải cho phép phụ huynh học sinh theo dõi

con em mình một cách thuận tiện nhất.

Ứng dụng sau đây có thể đáp ứng đầy đủ các yêu cầu đó. Ngoài việc đáp ứng đầy đủ các

chức năng của một hệ thống quản lý, ứng dụng còn tích hợp dịch vụ giá trị gia tăng trên

nền IMS để phụ huynh có thể tiện theo dõi việc học của con em mình mọi lúc mọi nơi.

5.2 Tổng quan ứng dụng

5.2.1 Mục đích

Mục đích của ứng dụng là để giải quyết bài toán quản lý đạo tạo, công tác dạy học ở cấp

bậc tiểu học. Đối tượng sử dụng chương trình bao gồm phụ hunh, học sinh, giáo viên, cán

bộ quản lý đào tạo.

Để đáp ứng được mục đích đó, ứng dụng phải có những yêu cầu sau.

75

5.2.2 Yêu cầu

Yêu cầu chung

Ứng dụng phải được xây dựng trên nền web để người dùng có thể sử dụng mọi

lúc, mọi nơi có kết nối internet.

Giao diện phải thân thiện và dễ sử dụng.

Ứng dụng phải đáp ứng được 1000 người sử dụng đồng thời.

Tiết kiệm chi phí

Tích hợp chức năng gọi điện cho học sinh qua giao diện web, trên nền tảng dịch

vụ mạng thế hệ mới.

Chức năng dành cho giáo viên

Quản lý đề thi

Quản lý câu hỏi thi

Quản lý câu hỏi ôn tập

Quản lý môn học

Quản lý học kỳ

Quản lý lớp học

Quản lý điểm tối đa của đề thi

Quản lý điểm tối đa của câu hỏi

Quản lý điểm, kết quả bài thi của học sinh

Câu hỏi thi và câu hỏi ôn tập đều dưới dạng trắc nghiệm. Mỗi đề thi có số điểm tối đa

khác nhau và không giới hạn về số câu hỏi. Mỗi câu hỏi có số điểm khác nhau. Và điểm

tối đa của đề thi không phải là tổng số điểm của tất cả các câu hỏi.

Khi kết thúc bài thi, học sinh sẽ biết được kết quả thi ngay tức thì. Hơn thế nữa, hệ thống

sẽ cập nhật ngay kết quả đó và xuất ra báo cáo cho giáo viên. Đồng thời, phụ huynh học

sinh cũng nhận được tin nhắn kết quả thi qua hệ thống IMS.

76

Chức năng dành cho các bộ quản lý đào tạo

Quản lý học sinh

Quản lý kết quả học tập của học sinh

Quản lý nhân sự nhà trường

Gửi thông báo đến học sinh, và cán bộ nhà trường.

Chức năng dành cho học sinh

Làm bài thi trực tuyến

Ôn tập trực tuyến

Học sinh chỉ có thể làm bài thi khi giao viên kích hoạt đề thi đó. Học sinh được phép làm

bài thi cho đến khi đồng hồ đếm ngược trở về 0.

Học sinh dễ dàng lựa chọn đề thi ôn tập của mình theo lớp, môn. Học sinh có thể bỏ qua

hoặc lựa chọn đáp án cho đến khi đúng mới thôi với đề thi ôn tập.

5.3 Thiết kế ứng dụng quản lý trường học

5.3.1 Lựa chọn công nghệ

Các công nghệ được lựa chọn để sử dụng để xây dựng ứng dụng trên bao gồm:

Wordpress

Trước hết Wordpress là một CMS được sử dụng để tạo một website hoặc blog. Rất nhiều

các website đang hoạt động sử dụng Wordpress.

Wordpress đã phổ biến với tốc độ rất nhanh: trên 73 triệu người (các blogger, tổ chức phi

lợi nhuận, doanh nghiệp nhỏ và cả các tập đoàn) đang sử dụng WordPress cho website cá

nhân hay chuyên nghiệp của họ.

77

Dưới đây là các lý do chúng ta nên chọn WordPress để phát triển website của mình:

1. WordPress rất dễ sử dụng

Rất nhiều người dùng than phiền gặp khó khăn trong việc sử dụng website của họ, tuy

nhiên, với WordPress thì không. Cách bố trí các chức năng của WordPress rất thân thiện

với người dùng và đã được hoàn thiện và chuẩn hóa qua nhiều phiên bản. Đặc biệt,

WordPress hỗ trợ rất nhiều ngôn ngữ khác nhau, phù hợp với tất cả người dùng trên thế

giới.

2. WordPress vô cùng thân thiên với công cụ tìm kiếm.

Nếu chúng ta đang cần một website mà mục tiêu thân thiện với công cụ tìm kiếm được

đặt lên đầu tiên, thì Wordpress là lựa chọn hoàn hảo nhất.

Wordpress cũng có rất nhiều công cụ hỗ trợ việc quảng bá website của bạn, làm cho việc

SEO web rất dễ dàng.

3. Wordpress được hỗ trợ rất tốt từ cộng đồng mạng

Bởi vì WordPress là mã nguồn mở (có nghĩa rằng nó miễn phí, chỉnh sử, phân phối

không cần đăng ký). Vì vậy, có hàng triệu người cùng nhau tham gia phát triển, cập nhật

giao diện, plugin và viết các tài liệu hướng dẫn. Điều đó là Wordpress ngày càng tốt hơn.

Bất cứ khi nào chúng ta gặp khó khăn với website của mình, thì cũng đã có người đã từng

gặp khó khăn như bạn, và họ sẵn sàng giúp bạn.

4. WordPress rất dễ để tùy chỉnh

Có hàng nghìn các theme khác nhau của WordPress sẵn sàng cho bạn sử dụng, tất cả là

miễn phí. Tuy nhiên, nếu bạn là một nhà phát triển, bạn dễ dàng có thể tạo một theme

theo nhu cầu của bản thân.

Càng phát triển, WordPress càng hỗ trợ việc tùy chỉnh một các thông minh như sự ra đời

của dữ liệu Meta và Post-Type. Nhờ đó, việc mở rộng trở nên rất dễ dàng. Rất nhiều

78

trường hợp bạn không cần phải quan tâm đến cơ sở dữ liệu. Và cũng rất nhiều trường

hợp, để tạo mới một chức năng, bạn chỉ cần thêm một vài dòng code.

5. WordPress có rất nhiều Plugin.

WordPress hỗ trợ việc cài đặt chức năng mới qua Plug-In, vì vậy có rất nhiều chức năng

phố biến ở nhiều website thì chắc chắn nó đã có plug-in phù hợp cho bạn sử dụng. Bạn

chỉ việc cài đặt nó vào website và thiết lập cấu hình theo những hướng dẫn cụ thể.

Như vậy, với website yêu cầu nhiều tính năng chuyên biệt, bạn vẫn có thể sử dụng

WordPress nếu bạn là một nhà phát triển. WordPress hỗ trợ bạn một các thông minh,

giúp việc tùy chỉnh trở nên vô cùng dễ dàng. Còn nếu, WebSite của bạn có rất nhiều tính

năng trùng lặp với các tính năng của website khác, thì mọi việc càng trở nên dễ dàng hơn.

Bạn không cần phải là một nhà phát triển, bạn chỉ việc cài đặt thêm các Plug-In bạn đã có

một website như mong muốn.

Memcached

Với những website yêu cầu số lượng truy cập lớn, vấn đề đầu tiên gặp phải đó chính là

việc quá tải cơ sở dữ liệu. Cách giải quyết hiệu quả nhất vấn đề này chính là sử dụng hệ

thống Cache.

Ngày nay, memcached là một lựa chọn phố biến cho hệ thống cache của các ứng dụng

web động bởi vì những lý so sau:

1. Memcached là mã nguồn mở

2. Memcache hoạt động ổn định, hiệu quả, và được sử dụng bởi rất nhiều các hệ

thống lớn như Twitter, Yahoo, Google App Engine.

3. Memcached sử dụng đơn giản, nguyên lý hoạt động dễ hiểu.

4. Dễ dàng mở rộng, và hiệu năng cao.

79

Webrtc2Sip

Như đã đề cập ở chương 4, WebRTC2Sip đóng vai trò là gateway để chuyển tải các bản

tin SIP và Media từ website vào hệ thống viễn thông như IMS. Để có thể thực hiện các

cuộc gọi từ trình duyệt, ngoài việc sử dụng các tính năng mới của HTML5, cần thiết phải

có một gateway như vậy. WebRTC2Sip là gateway đầu tiên thực hiện chức năng này.

Hơn thế nữa, nó là mã nguồn mở và đang được nhiều nhà phát triển cùng tham gia xây

dựng.

SIPML5

Để tích hợp chức năng gọi điện vào website, ứng dụng phải có khản năng thao tác bản tin

SIP và điều khiển media. Hiện tại, có một vài thư viện có khản năng thực hiện yêu cầu đó

như SIPML5, và JSSIP. Cả 2 đều là mã nguồn mở, và đều hoạt động rất tốt. Trong luận

văn này, chúng ta sử dụng SIPML5.

5.3.2 Kiến trúc hệ thống

80

81

Để đáp ứng những yêu cầu đó, kiến trúc hệ thống được xây dựng bao gồm các thành phần

sau:

Webserver

Webserver được sử dụng để chạy các script của ứng dụng quản lý. Mỗi lần user truy cập

hệ thống bằng web browser, user sẽ gửi yêu cầu lên web server bằng giao thức HTTP.

Web server nhận các yêu cầu đó và xử lý để trả lại thông tin cần thiết dưới định dạng

HTML.

WebRTC2SIP

Webrtc2SIP sử dụng để nhận các bản tin SIP over WebSocket từ trình duyệt và chuyển

nó thành bản tin SIP truyền thống, để P-CSCF có thể hiểu được.

Đồng thời, Webrtc2SIP cũng chuyển các media stream theo chuẩn phù hợp với các hệ

thống viễn thông hiện hành cũng như IMS.

Application Server (SIP AS)

AS nhận yêu cầu từ Web server bằng giao thức SIP, xử lý bản tin SIP và gửi tin nhắn

đến điện thoại di động qua hệ thống OpenIMSCore.

82

5.3.3 Sơ đồ hoạt động

5.3.3.1 Quá trình đăng nhập vào hệ thống

83

5.3.3.2 Quá trình tạo lớp 5.3.3.3 Quá trình sửa lớp

84

5.3.3.1 Xóa lớp

85

5.3.3.2 Quá trình tạo môn 5.3.3.3 Quá trình sửa môn

86

5.3.3.4 Quá trình xóa môn

87

5.3.3.5 Quá trình tạo học kỳ 5.3.3.6 Quá trình sửa học kỳ

88

5.3.3.7 Quá trình xóa học kỳ

89

5.3.3.8 Quá trình tạo đề thi 5.3.3.9 Quá trình sửa đề thi

90

5.3.3.10Quá trình xóa đề thi 5.3.3.11Quá trình tìm kiếm đề thi

91

5.3.3.12Quá trình tạo câu hỏi 5.3.3.13Quá trình sửa câu hỏi

92

5.3.3.14Xóa câu hỏi 5.3.3.15Tìm kiếm câu hỏi

93

5.3.4 Sơ đồ ca sử dụng

5.3.4.1 Quá trình làm bài ôn tập

94

5.3.4.2 Quá trình làm bài thi

5.3.4.3 Quá trình gọi điện từ website

95

5.3.5 Thiết kế ứng dụng trên nền tảng Wordpress

Từ yêu cầu chức năng và công nghệ đã lựa chọn – Wordpress, hệ thống có các đối tượng

sau:

Người dùng:

Học sinh

Giáo viên

Cán bộ quản lý

Câu hỏi thi:

Câu hỏi thi

Câu hỏi ôn tập

Phân loại câu hỏi:

Lớp

Môn

Độ khó

Dạng câu hỏi

Học kỳ

Đề thi

Với Wordpress, ta có mô hình quan hệ thực thể như sau:

96

Wordpress cho phép các developer mở rộng tính năng một cách dễ dàng với POST TYPE

và TAXONOMY và dữ liệu META.

Sử dụng Wordpress để giải quyết bài toán trên, ta đưa gom các đối tượng chính thành các

POST TYPE, còn các đối tượng phân loại vệ tinh là các TAXONOMY. Đồng thời, với

mỗi POST TYPE ta có thể mở rộng dữ liệu không giới hạn với POST META.

97

Như vậy ta có các POST TYPE sau:

Câu hỏi thi

Câu hỏi ôn tập

Đề thi

Và các TAXONOMY sau:

Lớp

Học kỳ

Độ khó

Đề thi

Dạng câu hỏi

Với Đề thi, nó vừa là POST TYPE, vừa là TAXONOMY. Để giải quyết vấn đề này,

Wordpress hỗ trợ chúng ta với cơ chế HOOK. HOOK nghĩa là chúng ta có thể chèn thêm

các tác vụ vào trước và sau các tác vụ mặc định của Wordpress. Ở đây, sau mỗi tác vụ tạo

và cập nhật POST TYPE Đề thi, ta tiến hành thêm tác vụ tạo và cập nhật TAXONOMY

Đề thi.

Với Câu hỏi thi, mỗi câu hỏi thi có nhiều phương án trả lời. Các phương án trả lời này ta

sẽ đưa vào dữ liệu META của POST TYPE Đề thi.

5.3.6 Giao diện chương trình

Câu hỏi ôn tập:

98

Phần làm bài thi

99

Phần nhà trường gửi thông báo:

Phần xem kết quả học tập:

100

Phần tìm kiếm, quản lý đề thi và câu hỏi thi:

Chức năng gọi điện từ trình duyệt:

101

5.4 Cài đặt, thiết lập Test Bed

5.4.1 Sơ đồ kiến trúc Test Bed

102

5.4.2 Cài đặt OpenIMSCore trên Ubuntu 12.04

Bước 1: Cài đặt các thư viện và chương trình cần thiết bởi các lệnh sau:

sudo apt-get install libxml2 libxml2-dev sudo apt-get install bind9 sudo apt-get install bisonsudo apt-get install flexsudo apt-get install mysql-serversudo apt-get install curlsudo apt-get install antsudo apt-get install makesudo apt-get install libcurl4-gnutls-dev sudo apt-get install gccsudo apt-get install libmysqlclient-dev sudo apt-get install make

Bước 2: Cài đặt thư viện JAVA SUN:

sudo apt-get install python-software-propertiessudo add-apt-repository ppa:flexiondotorg/javasudo apt-get updatesudo apt-get install sun-java6-jdk sun-java6-plugin

Bước 3: Tạo thư mục và download mã nguồn của OpenIMSCore:

cd /opt/sudo mkdir OpenIMSCorecd OpenIMSCore/sudo mkdir ser_imssudo svn checkout http://svn.berlios.de/svnroot/repos/openimscore/ser_ims/trunk ser_imssudo mkdir FHoSSsudo svn checkout http://svn.berlios.de/svnroot/repos/openimscore/FHoSS/trunk FHoSS

103

Bước 4: Với Ubuntu 12.04, phải sửa file client.h (bỏ thư viện curl/type.h). Sau đó biên

dịch ser_ims

cd ser_ims/cd opt/OpenIMSCore/ser_ims/lib/lost/sudo vi client.h 

cd ../..sudo make install-libs all

Bước 5: Thiết lập Path JAVA_HOME trong file .bashrc

sudo vi .bashrc echo $JAVA_HOMEexitecho $JAVA_HOME

Bước 6: Biên dịch FhoSS

cd /opt/OpenIMSCore/FHoSS/sudo ant compileantsudo ant compilesudo ant deploy

Bước 7: Thiết lập domain name:

cd ..sudo cp ser_ims/cfg/open-ims.dnszone /etc/bindsudo vi /etc/bind/named.confsudo vi /etc/hostsudo vi /etc/hosts

Tham khảo thiết lập sau:

104

cp ser_ims/cfg/open-ims.dnszone /etc/bind

Sửa /etc/bind/named.conf, thêm zone như sau:

zone "open-ims.test" IN {type master;file "/etc/bind/open-ims.dnszone";};Sửa etc/hosts127.0.0.1 localhost127.0.1.1 yours-laptop/pc127.0.0.1 open-ims.test mobicents.open-ims.test ue.open-ims.test presence.open-ims.test icscf.open-ims.test scscf.open-ims.test pcscf.open-ims.test hss.open-ims.test

Bước 8: Import database

 sudo mysql -u root -p -h localhost < ser_ims/cfg/icscf.sql sudo mysql -u root -p -h localhost < FHoSS/scripts/hss_db.sql sudo mysql -u root -p -h localhost < FHoSS/scripts/userdata.sql

Bước 9: Copy các file config ra thưc mục gốc:

 sudo cp ser_ims/cfg/*.cfg /opt/OpenIMSCore sudo cp ser_ims/cfg/*.xml /opt/OpenIMSCore sudo cp ser_ims/cfg/*.sh /opt/OpenIMSCore

Đã hoàn tất, bây giờ có thể khởi chạy pcscf.sh, scscf.sh, icscf.sh và HSS.

./pcscf.sh

./scscf.sh

./icscf.shcd /FHoSS/deploysh startup.sh

105

* Chú ý: Có thể phải thêm dòng JAVA_HOME=/usr/lib/jvm/java-6-sun trước khi sử

dụng biến $JAVA_HOME trong file startup.sh

5.4.3 Cấu hình OpenIMSCore

Tạo mới user

Bước 1: Tạo 1 IMS Subscription

Bước 2: Tạo Private User Identity

Bước 3: Tạo Public User Identity

106

Sử dụng MD5 Digest

Thay đổi file scscf.cfg để sử dụng phương thức mã hõa MD5 Digest, hỗ trợ các cuộc gọi

từ trình duyệt.

5.4.4 Cài đặt WebRTC2Sip

Bước 1: Chuẩn bị các thư viện

sudo -iapt-get updateapt-get upgradeapt-get install build-essential libtool automake subversion git-core libsrtp0-dev \libssl-dev libspeexdsp-dev yasm libvpx-dev libgsm1-dev libxml2-dev libx264-dev \screen pkg-config

107

Bước 2: Cài đặt Doubango và FFMPEG

FFMPEG:

apt-get remove libavutil51

cd /usr/local/srcwget -c http://ffmpeg.org/releases/ffmpeg-1.0.2.tar.gztar zxvf ffmpeg-1.0.2.tar.gz

cd ffmpeg

./configure --extra-cflags="-fPIC" --extra-ldflags="-lpthread" --enable-pic \--enable-memalign-hack --enable-shared --disable-static --disable-network \--disable-protocols --disable-pthreads --disable-devices --disable-filters \--disable-bsfs --disable-muxers --disable-demuxers --disable-parsers \--disable-hwaccels --disable-ffmpeg --disable-ffplay --disable-ffserver \

--disable-encoders --disable-decoders --disable-zlib --enable-gpl --disable-debug \--enable-encoder=h263 --enable-encoder=h263p --enable-decoder=h263 \--enable-encoder=mpeg4 --enable-decoder=mpeg4 --enable-libx264 \--enable-encoder=libx264 --enable-decoder=h264

make -j `getconf _NPROCESSORS_ONLN`

make install

ldconfig

Doubango:

cd /usr/local/src

svn co http://doubango.googlecode.com/svn/branches/2.0/doubango doubango

cd doubango./autogen.sh./configure --with-ssl --with-srtp --with-vpx --with-speex --with-speexdsp \

108

--enable-speexresampler --enable-speexjb --enable-speexdenoiser --with-gsm \--with-ffmpeg --with-h264 --prefix=/usr/local

make -j `getconf _NPROCESSORS_ONLN`

make install

ldconfig

Bước 3: Cài đặt WebRTC2Sip

cd /usr/local/src

svn co http://webrtc2sip.googlecode.com/svn/trunk/ webrtc2sipcd webrtc2sip./autogen.sh./configure --with-doubango=/usr/local --prefix=/usr/local

make -j `getconf _NPROCESSORS_ONLN`

make installmkdir -p /usr/local/etc/webrtc2sipcp config.xml /usr/local/sbin/

Bước 4: Cấu hình

<?xml version="1.0" encoding="utf-8" ?><!-- Please check the technical guide (http://webrtc2sip.org/technical-guide-1.0.pdf) for more information on how to adjust this file --><config>

<debug-level>ERROR</debug-level>

<transport>udp;*;10060</transport> <transport>ws;*;10060</transport> <transport>wss;*;10062</transport>

<enable-rtp-symetric>yes</enable-rtp-symetric> <enable-100rel>no</enable-100rel> <enable-media-coder>yes</enable-media-coder> <enable-videojb>yes</enable-videojb> <video-size-pref>vga</video-size-pref> <rtp-buffsize>65535</rtp-buffsize> <avpf-tail-length>100;400</avpf-tail-length> <srtp-mode>optional</srtp-mode>

109

<srtp-type>sdes;dtls</srtp-type>

<codecs>pcma;pcmu;gsm;vp8;h264-bp;h264-mp;h263;h263+</codecs>

<!--nameserver>66.66.66.6</nameserver-->

<!--ssl-certificates> C:/Projects/ssl/priv.pem; C:/Projects/ssl/pub.pem; C:/Projects/ssl/ca-cert.pem; no </ssl-certificates-->

</config>

Bước 5: Chạy WebRTC2Sip

webrtc2sip --config=/usr/local/etc/webrtc2sip/config.xml

5.4.5 Thiết lập cấu hình Client

Trên điện thoại, ta sử dụng phần mềm mã nguồn mở IMSDroid, để kết nối được với

OpenIMSCore, ta cấu hình như hình dưới:

110

Trên trình duyệt, ta sử dụng thư viện SIPML5, cấu hình các tham số như sau:

Private Identity: bob@open-ims.test

Public Identity: sip:bob@open-ims.test

Password: bob

Realm: open-ims.test

WebSocket Server URL: ws://192.168.1.80:10060

111

CHƯƠNG 6. Kết luận và hướng phát triển đề tài

6.1 Kết luận

Ngày nay, Internet ngày càng đóng vai trò quan trọng trong lĩnh vực viễn thông. Trong

đó, công nghệp web đóng vai trò cốt lõi và tiên phong tạo nên sự phát triển không ngừng

của Internet. Với sự ra đời của HTML5 và CSS3, công nghệ web sẽ tiếp tục phát triển

mạnh mẽ và tạo ra nhiều cuộc cách mạng lớn trong tương lai.

Trước nhu cầu hội tụ để phát triển, IMS đã ra đời để có thể kết hợp giữa mạng điện thoại

truyền thống và mạng internet.

Dưới sự hướng dẫn tận tình của TS. Nguyễn Tài Hưng, nội dung luận văn đề cập đến vấn

đề xây dựng và triển khai một ứng dụng trên nền web tích hợp khản năng nghe gọi, nhắn

tin tới các SIP Client khác qua mạng thế hệ mới IMS. Đồng thời, luận văn cũng giới thiệu

và nghiên cứu các công nghệ mới có liên quan nhằm hỗ trợ việc xây dựng các ứng dụng

thân thiện và có ý nghĩa nhằm phục vụ người dùng.

Bên cạnh những mặt thuận lợi và kết quả đã đạt được là những khó khăn và nhược điểm:

Các công nghệ và các thư viện mới đang trong giai đoạn xây dựng nên vẫn còn

nhiều lỗi và tính ổn định chưa cao.

Về mặt tài liệu, dù đã nhận được sự hỗ trợ từ nhiều nguồn, nhưng do các công

nghệ nghiên cứu còn mới nên tài liệu đưa ra chưa đủ chi tiết.

Ứng dụng quản lý đào tạo chỉ mới xây dựng nội bộ, dừng lại ở mức độ mô phỏng

nghiên cứu, chưa đưa ra thực tiễn để kiểm thử.

Tuy vậy, trong xu thế phát triển của công nghệ, ứng dụng quản lý đào tạo sẽ ngày càng

hoàn thiện và có nhiều ý nghĩa thực tiễn hơn. Những công nghệ mới được đề cập trong

nội dung luận văn đang từng ngày được hoàn thiện và ổn định hơn bởi sự đóng góp

không mệt mỏi của cộng đồng mã nguồn mở. Chúng ta có quyền tin chắc rằng, nền tảng

112

web là nền tảng cốt lõi cho các ứng dụng trong tương lai và IMS sẽ là cầu nối hiệu quả

giữa internet và mạng viễn thông.

6.2 Hướng phát triển của đề tài

Một vài công nghệ, thư viện được đề cập trong nội dung luận văn đang trong giai đoạn

xây dựng và phát triển như HTML5, SIP over Websocket, SIPML5, Webrtc2Sip. Tuy

vậy, những công nghệ này đã và đang được nhiều tổ chức, cá nhân ủng hộ, chung sức xây

dựng. Trong tương lai chúng sẽ trở nên phổ biến, gần gũi và quen thuộc hơn. Những nhà

phát triển phần mềm sẽ sử dụng chúng để tích hợp vào các ứng dụng của mình.

Sự phát triển của IMS sẽ mang lại sự hội tụ giữa các mạng viễn thông và Internet. Sự

phát triển của công nghệ web sẽ mang lại sự hội tụ các thiết bị đầu cuối. Trong một tương

lai gần, việc thực hiên cuộc gọi hoặc nhắn tin tới các thiết bị di động từ trình duyệt web

sẽ trở nên phổ biến. Do các ứng dụng được xây dựng trên nền tảng web, nên việc mở

rộng, nâng cấp để có thể phục vụ nhiều user đồng thời, hay lưu trữ dữ liệu lớn ta có thể

sử dụng các công nghệ đang rất phổ biến hiện hay như caching, NoSQL, Load Balancing.

Xa hơn nữa, khi các thiết bị đầu cuối như điện thoại thông minh, TV thông minh, máy

tính sử dụng chung nền tảng công nghệ web (Ví dụ: Chrome OS), và IMS trở thành nền

tảng mạng viễn thông thì việc bạn có thể nhận cuộc gọi video từ chiếc TV thông minh sẽ

không còn là điều đáng ngạc nhiên. Hơn thế nữa, những câu chuyện được nêu lên ở phần

đầu của cuốn luận văn này sẽ là sự thật hiển nhiên.

113

Tài liệu tham khảo

http://vi.wikipedia.org/wiki/Apache_maven

http://sipp.sourceforge.net/

http://memcached.org/

http://en.wikipedia.org/wiki/Memcached

http://scotty-t.com/2012/01/20/wordpress-memcached/

http://codex.wordpress.org

http://sipml5.org/

http://webrtc2sip.org/

http://wp.tutsplus.com/

http://websocket.org

http://tools.ietf.org/html/draft-ietf-sipcore-sip-websocket-06

WebSocket: http://en.wikipedia.org/wiki/WebSocket

HTML5 Web Socket in Essence: http://www.codeproject.com/Articles/209041/HTML5-

Web-Socket-in-Essence

The WebSocket protocol: http://tools.ietf.org/html/rfc6455

The WebSocket API: http://www.w3.org/TR/websockets/

Socket IO: http://socket.io/#how-to-use

Node.js Documentation: http://nodejs.org/api/

WebRTC: http://dev.w3.org/2011/webrtc/editor/webrtc.html

114