Nghiên cứu hệ thống truyền thông đa phương tiện thời gian thực trên cơ sở giải pháp kỹ thuật WEBRTC

Với các ưu điểm kể trên, thì việc tìm hiểu hệ thống truyền thông đa phương tiện thời gian thực trên cơ sở giải pháp kỹ thuật WebRTC và ứng dụng giải pháp kỹ thuật này vào thực tế là vấn

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

ĐẠI HỌC ĐÀ NẴNG

HỒ MINH HOÀNH

NGHIÊN CỨU HỆ THỐNG TRUYỀN THÔNG

ĐA PHƯƠNG TIỆN THỜI GIAN THỰC TRÊN CƠ SỞ GIẢI PHÁP KỸ THUẬT WEBRTC

LUẬN VĂN THẠC SĨ HỆ THỐNG THÔNG TIN

Đà Nẵng - Năm 2016

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

ĐẠI HỌC ĐÀ NẴNG

HỒ MINH HOÀNH

NGHIÊN CỨU HỆ THỐNG TRUYỀN THÔNG

ĐA PHƯƠNG TIỆN THỜI GIAN THỰC TRÊN CƠ SỞ GIẢI PHÁP KỸ THUẬT WEBRTC

Chuyên ngành: HỆ THỐNG THÔNG TIN

Mã số: 60.48.01.04

LUẬN VĂN THẠC SĨ HỆ THỐNG THÔNG TIN

Người hướng dẫn khoa học: PGS.TS LÊ VĂN SƠN

Đà Nẵng - Năm 2016

LỜI CAM ĐOAN

Tôi cam đoan đây là công trình nghiên cứu của riêng tôi Các số liệu, kết quả nêu trong luận văn là trung thực và chưa từng được ai công bố trong bất kỳ công trình nào khác

Tác giả luận văn

Hồ Minh Hoành

MỤC LỤC

MỞ ĐẦU 1

1 Lý do chọn đề tài 1

2 Mục tiêu và nhiệm vụ đề tài 2

3 Đối tượng và phạm vi nghiên cứu 2

4 Phương pháp nghiên cứu 3

5 Mục đích và ý nghĩa của đề tài 3

6 Kết quả dự kiến 4

7 Bố cục của luận văn 4

CHƯƠNG 1 TỔNG QUAN VỀ TRUYỀN THÔNG ĐA PHƯƠNG TIỆN 5

1.1 TRUYỀN THÔNG ĐA PHƯƠNG TIỆN 5

1.1.1 Khái niện truyền thông đa phương tiện 5

1.1.2 Ví dụ về truyền thông đa phương tiện 7

1.2 DỮ LIỆU ĐA PHƯƠNG TIỆN 8

1.2.1 Phân loại 8

1.2.2 Truyền dữ liệu đa phương tiện 9

1.2.3 Các phương pháp truyền dữ liệu đa phương tiện 11

1.3 CÁC ỨNG DỤNG TRUYỀN THÔNG ĐA PHƯƠNG TIỆN 15

1.3.1 Truyền video và audio đã được lưu trữ trên server 15

1.3.2 Truyền trực tiếp audio/video (Streaming live audio/video) 15

1.3.3 Ứng dụng tương tác audio/video thời gian thực 16

1.3.4 Ứng dụng video conference 16

CHƯƠNG 2 GIẢI PHÁP KỸ THUẬT WEBRTC 17

2.1 GIỚI THIỆU CHUNG 17

2.2 LỊCH SỬ PHÁT TRIỂN 18 2.3 KIẾN TRÚC VÀ PHƯƠNG THỨC HOẠT ĐỘNG CỦA WEBRTC 19

2.3.1 Kiến trúc WebRTC 19

2.3.2 Phương thức hoạt động 20

2.4 CÁC GIAO THỨC MẠNG TRUYỀN THÔNG THỜI GIAN THỰC 23

2.5 CÁC API CƠ BẢN 29

2.5.1 MediaStream (hay getUserMedia) 29

2.5.2 RTCPeerConnection 32

2.5.3 RTCDataChannel 33

2.6 BẢO MẬT TRONG WebRTC 35

CHƯƠNG 3 XÂY DỰNG ỨNG DỤNG HỖ TRỢ TRỰC TUYẾN 36

3.1 GIỚI THIỆU VỀ EASYRTC FRAMEWORK 37

3.2 PHÂN TÍCH HỆ THỐNG 38

3.2.1 Mục tiêu 38

3.2.2 Thực trạng 38

3.2.3 Phân tích yêu cầu của ứng dụng 40

3.3 THIẾT KẾ ỨNG DỤNG 41

3.3.1 Xác định các tác nhân của hệ thống 41

3.3.2 Biểu đồ ca sử dụng 42

3.3.3 Biểu đồ tuần tự 45

3.3.4 Biểu đồ hoạt động 46

3.3.5 Thiết kế giao diện 47

3.4 CÀI ĐẶT ỨNG DỤNG 48

3.4.1 Chuẩn bị môi trường và công cụ phát triển 48

3.4.2 Xây dựng hàm kết nối 49

3.4.3 Xây dựng hàm performCall 51

3.4.4 Xây dựng hàm gửi tin nhắn 53

3.5 CHẠY THỬ VÀ ĐÁNH GIÁ ỨNG DỤNG 53

3.5.1 Chạy thử ứng dụng 53

3.5.2 Đánh giá hiệu quả của ứng dụng 58

KẾT LUẬN 59 TÀI LIỆU THAM KHẢO

QUYẾT ĐỊNH GIAO ĐỀ TÀI LUẬN VĂN (bản sao)

DANH MỤC CÁC KÝ HIỆU, CÁC CHỮ VIẾT TẮT

API Application Programmable Interface

DTLS Datagram Transport Layer Security

GIPS Global IP Solutions

IETF Internet Engineering Task Force

ICE Interactive Connectivity stablishment

NAT Network Address Translation

STUN Session Traversal Utilities for NAT

SDP Session Description Protocol

SIP Session Initiation Protocol

SCTP Stream Control Transport Protocol

SRTP Secure Real-Time Transport Protocol

TFTP Trivial File Transfer Protocol

TURN Traversal Using Relays around NAT

TCP Transfer Control Protocol

UDP User Datagram Protocol

WebRTC Web Real-Time Communication

XMPP Extensible Messaging and Presence Protocol

2.7 Phân phối audio video qua SRTP trên UDP 29

2.9 Trình duyệt hỏi cấp phép chia sẻ sử dụng camera và

3.3 Màn hình đăng nhập Skype trên máy tính 40 3.4 Các tác nhân của hệ thống phòng Đào tạo 41

3.14 Giao diện của cán bộ phòng Đào tạo 56

3.16 Cán bộ tư vấn và người học nói chuyện, chia sẻ webcam

và gửi tin nhắn với nhau

57

MỞ ĐẦU

1 Lý do chọn đề tài

Hãy tưởng tượng một ngày mà điện thoại, máy tính, tivi, có thể kết nối trực tiếp với nhau và thực hiện được các cuộc gọi thông qua một nền tảng chung Việc giao tiếp của chúng ta sẽ trở nên dễ hàng hơn và điều này có thể thay thế các phương phức liên lạc hiện có Đó là mục tiêu mà dự án WebRTC đang theo đuổi, WebRTC được kỳ vọng sẽ tạo bước ngoặt lớn trong lĩnh vực truyền thông đa phương tiện

Điểm đột phá của WebRTC là ta có thể tham gia cuộc hội thoại ngay trên trình duyệt mà không cần cài thêm bất cứ một phần mềm hay plugin nào khác

Nó đang được chuẩn hóa ở cấp độ API của W3C và cấp độ giao thức của IETF, được hỗ trợ bởi các trình duyệt Google Chrome, Mozilla Firefox và Opera trên

PC và Android Ngoài ra WebRTC còn được hỗ trợ trên Chrome OS

Tính đến thời điểm hiện tại, đã có trên 1 tỷ thiết bị đầu cuối hỗ trợ WebRTC, dự báo tăng lên 4 tỷ vào năm 2016, trong đó có khoảng 1,5 tỷ người dùng thường xuyên WebRTC có thể hoạt động trên bất cứ thiết bị nào

có cài một trong các trình duyệt hỗ trợ WebRTC

Ở góc độ nhà phát triển, nếu không có WebRTC, việc tạo ra ứng dụng RTC đòi hỏi phải mất nhiều công sức từ việc lấy dữ liệu từ thiết bị camera, microphone đến việc thiết lập phiên, xử lý tín hiệu, truyền tín hiệu, … Nhưng với WebRTC, tất cả công việc để tạo ra một cuộc hội thoại chỉ nằm trong vài chục dòng lệnh Việc phát triển ứng dụng với chức năng gọi điện, video chat

và chia sẻ file, là rất đơn giản khi dùng WebRTC kết hợp giữa JavaScript và HTML5

Ở góc độ người sử dụng, sử dụng WebRTC chỉ cần thông qua trình duyệt Web Tính sẵn sàng cao cho phép thực hiện cuộc gọi mà không cần

đăng ký tài khoản hay cài đặt thêm thành phần nào ngoài một trình duyệt có

hỗ trợ WebRTC Ví dụ, hai người dùng chỉ cần truy cập vào cùng một đường dẫn web để gọi video với nhau sử dụng trình duyệt Google Chrome hay Mozilla Firefox

Với các ưu điểm kể trên, thì việc tìm hiểu hệ thống truyền thông đa phương tiện thời gian thực trên cơ sở giải pháp kỹ thuật WebRTC và ứng dụng giải pháp kỹ thuật này vào thực tế là vấn đề cần thiết hiện nay

2 Mục tiêu và nhiệm vụ đề tài

- Tìm hiểu tổng quan về hệ thống truyền thông đa phương tiện

- Tìm hiểu cấu trúc và cách thức hoạt động của WebRTC

- Tìm hiểu các API cơ bản của WebRTC

 Về thực tiễn:

Đề tài ứng dụng các giải pháp kỹ thuật WebRTC vào xây dựng các ứng dụng thực tiển

3 Đối tượng và phạm vi nghiên cứu

3.1 Đối tượng nghiên cứu

3.2 Phạm vi nghiên cứu

Trong khuôn khổ của một luận văn thực nghiệm, chúng tôi chỉ giới hạn thực nghiệm xây dựng ứng dụng hỗ trợ trực tuyến ứng dụng tại trường Đại học Sư phạm – Đại học Đà Nẵng

4 Phương pháp nghiên cứu

Phương pháp nghiên cứu, chúng tôi đã sử dụng hai phương pháp chính

là nghiên cứu lý thuyết và nghiên cứu thực nghiệm

4.1 Phương pháp nghiên cứu tài liệu

- Các tài liệu về cơ sở lý thuyết: truyền thông đa phương tiện thời gian thực, WebRTC, framework EasyRTC…

- Các tài liệu liên quan đến một số nghiên cứu

Tìm hiểu và ứng dụng được giải pháp kỹ thuật WebRTC vào thực tế

5.2 Ý nghĩa khoa học và thực tiễn đề tài

a Về khoa học

Tìm hiểu công nghệ WebRTC để phục vụ việc phát triển các ứng dụng truyền thông đa phương tiện thời gian thực trên Web

b Về thực tiễn

Có thể phát triển ứng dụng với chức năng gọi điện, video chat và chia

sẻ file sẽ rất đơn giản khi dùng WebRTC Việc sử dụng WebRTC chỉ cần thông qua trình duyệt Web Tính sẵn sàng cao cho phép thực hiện cuộc gọi

mà không cần đăng ký tài khoản hay cài đặt thêm thành phần nào ngoài một trình duyệt có hỗ trợ WebRTC

6 Kết quả dự kiến

6.1 Lý thuyết

- Nắm được công nghệ WebRTC và framework EasyRTC

- Hiểu được cách xây dựng một hệ thống truyền thông đa phương tiện thời gian thực

6.2 Thực tiễn

- Phát triển được ứng dụng hỗ trợ trực tuyến ứng dụng tại trường Đại học

Sư phạm – Đại học Đà Nẵng

7 Bố cục của luận văn

Bố cục của luận văn bao gồm 3 chương như sau:

Chương 1: Giới thiệu sơ lược về truyền thông đa phương tiện, các đặc điểm của dữ liệu đa phương tiện, và giới thiệu một số các ứng dụng truyền thông đa phương tiện hiện nay

Chương 2: Chúng tôi dành để nói về kiến trúc, các thành phần chính của WebRTC

Chương 3: Tập trung vào phân tích, thiết kế và xây dựng một ứng dụng

hỗ trợ trực tuyến sử dụng WebRTC để hỗ trợ cho người học về các thông tin đào tạo tại trường Đại học Sư phạm – Đại học Đà Nẵng

CHƯƠNG 1

TỔNG QUAN VỀ TRUYỀN THÔNG ĐA PHƯƠNG TIỆN

Ngày nay, truyền thông nói chung, và truyền thông đa phương tiện nói riêng đang rất được quan tâm Nhờ có truyền thông đa phương tiện con người trao đổi thông tin từ xa thông qua văn bản, hình ảnh và âm thanh

Bên cạnh đó, mạng máy tính đã và đang phổ biến trong cơ quan, doanh nghiệp, nên ứng dụng mạng như chia sẻ dữ liệu, phần mềm trực tuyến ngày càng được ưu chuộng và trở thành yếu tố không thể thiếu trong xã hội thông tin hiện đại

Bởi vậy, việc nghiên cứu kỹ thuật truyền thông nói chung, truyền thông

đa phương tiện nói riêng nhằm làm chủ và tạo nền tảng phát triển ứng dụng truyền thông đa phương tiện như dạy học trực tuyến, hội nghị truyền hình trực tuyến… đang trở thành chủ đề nghiên cứu của nhiều tổ chức nghiên cứu trong

và ngoài nước

Trong chương này chúng tôi sẽ giới thiệu sơ lược về truyền thông đa phương tiện, các đặc điểm của dữ liệu đa phương tiện, và giới thiệu một số các ứng dụng truyền thông đa phương tiện hiện nay

1.1 TRUYỀN THÔNG ĐA PHƯƠNG TIỆN

1.1.1 Khái niện truyền thông đa phương tiện

Thuật ngữ đa phương tiện dùng để chỉ các thông tin như dữ liệu, tiếng nói, đồ họa, hình ảnh tĩnh, âm thanh và phim ảnh được các mạng truyền đi cùng thời điểm

Truyền thông đa phương tiện là một công nghệ truyền thông giúp người dùng trao đổi, chia sẻ thông tin đa phương tiện trên mạng truyền thông, thông tin gồm: Dữ liệu Audio, Video thời gian thực, hình ảnh văn bản và các dạng dữ liệu khác

Truyền thông đa phương tiện thời gian thực là một phương thức

truyền thông, trong đó tất cả người dùng có thể trao đổi thông tin ngay lập tức hoặc với độ trễ không đáng kể [8]

Các ứng dụng sử dụng truyền thông đa phương tiện trên gồm: Hội thảo từ xa (video conferencing), nói chuyện qua internet (voice over IP), truyền hình internet, truyền hình theo yêu cầu (video on demand)…

Các thành phần của hệ thống truyền thông đa phương tiện: Hình 1.1 thể hiện mô hình client/server để truyền dữ liệu đa phương tiện hai đầu Ở phía nguồn, dữ liệu đa phương tiện được nén và lưu trữ Qua hệ thống điều khiển từ phía server, các dữ liệu này sẽ được gửi đi qua mạng tùy theo yêu cầu của người dùng Giao thức ở tầng application/transport sẽ được dùng để truyền dữ liệu tới máy khách, dữ liệu này sẽ được lưu trong bộ đệm hoặc thiết

bị lưu trữ, từ đó được giải mã và được hiển thị cho người dùng

Hình 1.1 Sơ đồ khối cơ bản của 1 hệ thống đa phương tiện

Đặc trưng duy nhất của mô hình hệ thống này là: Các thành phần của hệ thống sẽ thực hiện công việc một cách tuần tự theo các bước trong quá trình truyền dữ liệu Do đó, nếu 1 thành phần hoạt động không tốt sẽ ảnh hưởng tới toàn bộ hệ thống

Tóm lại, các thành phần của hệ thống truyền thông đa phương tiện bao gồm:

 Dữ liệu đa phương tiện

+ Video theo yêu cầu là một dạng dữ liệu được lưu trữ trên multimedia server và được truyền đến người dùng khi có yêu cầu, người dùng có toàn quyền để hiển thị cũng như thực hiện các thao tác (tua, dừng, …) với các đoạn

dữ liệu này

+ Video thời gian thực là dạng dữ liệu video được convert trực tiếp từ các nguồn cung cấp dữ liệu theo thời gian thực (máy camera, microphone, các thiết bị phát dữ liệu video, …) Các dữ liệu này sẽ được multimedia phát quảng bá thành các kênh người dùng sẽ chỉ quyền truy nhập bất kỳ kênh ưu thích nào để hiển thị dữ liệu mà không được thực hiện các thao tác tua, dừng

… trên các dữ liệu đó (giống như TV truyền thống)

 Hội nghị truyền hình

Là sự hoạt động tương tác giữa tín hiệu audio, video trong thời gian thực Nó được ứng dụng trong hội họp từ xa giúp những người tham gia không tốn thời gian đi lại mà vẫn có thể gặp mặt nhau

Ví dụ:

Hệ thống hội nghị truyền hình đã được ứng dụng rộng rãi trong các trường đại học như dạy học trực tuyến từ xa theo mô hình Elearning Trong lĩnh vực xã hội cũng như an ninh, quốc phòng Trong các hội nghị giao ban, trao đổi công việc của các đơn vị có vị trí địa lý cách xa nhau Các xí nghiệp, các trung tâm thương mại, bệnh viện như người bệnh có thể được khám bệnh, chuẩn đoán hay thậm chí phẫu thuật gián tiếp từ các chuyên gia y tế tại những nơi rất xa Và các công việc, lĩnh vực yêu cầu trao đổi thông tin, hình ảnh, âm thanh thời gian thực khác

Ta có thể phân loại các loại dữ liệu trên ra thành 2 loại, theo ngữ cảnh của việc truyền dữ liệu đa phương tiện

- Loại thứ nhất: dữ liệu rời rạc gồm các loại dữ liệu mà khi hiển thị không bị bó buộc chặt chẽ về thời gian Ví dụ ta có thể nhận một bức ảnh từ web server để hiển thị trong web browser Tùy theo thông lượng mạng mà thời gian nhận bức ảnh có thể nhanh hay chậm trước khi nó được giải mã và hiển thị

- Loại thứ hai: dữ liệu liên tục Dữ liệu này có một yêu cầu chặt chẽ về thời gian hiển thị và các thông tin này được nhúng bên trong dữ liệu Ta có thể thấy ngay ví dụ đó là dữ liệu video, audio Dữ liệu video thường được mã hóa theo các frame được hiển thị tuần tự với một tần số nào đó, ví dụ 25

hình/giây Do đó, để hiển thị các đối tượng video một cách đúng đắn, thì không chỉ cần nhận dữ liệu video một cách chính xác mà còn cần phải giải mã

và hiển thị chúng theo đúng trình tự và thời điểm Nếu không làm được điều

đó thì video hiển thị sẽ bị hỏng, chất lượng thấp Do đó lưu lượng mạng dành cho dữ liệu đa phương tiện có thể coi là lưu lượng cố định do sự cần thiết duy trì bộ định thời chặt chẽ

Từ đó ta thấy, thách thức trong truyền thông đa phương tiện nói chung

và đặc biệt là truyền thông dữ liệu đa phương tiện liên tục, đó là phải đảm bảo tính vẹn toàn của cả dữ liệu và thời gian hiển thị Hơn nữa, dữ liệu đa phương tiện thông thường là sự kết hợp của nhiều dòng dữ liệu khác nhau và được đồng bộ với nhau Do đó, độ phức tạp sẽ được nhân lên nhiều lần và phải đồng bộ giữa các dòng dữ liệu với nhau

1.2.2 Truyền dữ liệu đa phương tiện

Với 2 loại dữ liệu đa phương tiện đã bàn ở trên, trong khuôn khổ luận văn này chúng tôi chỉ tập trung vào truyền dữ liệu liên tục Chúng ta có thể phân lớp việc truyền dữ liệu đa phương tiện liên tục thành 2 loại: truyền thời gian thực và truyền bán thời gian thực Truyền dữ liệu thời gian thực là dữ liệu phải truyền từ nguồn và hiển thị tại đích với một độ trễ cho trước Truyền

dữ liệu thời gian thực thường được sử dụng để người dùng tương tác với nhau như: Internet Phone, đàm thoại video từ xa (Hình 1.2)

Hình 1.2 Truyền dữ liệu liên tục thời gian thực trong đàm video từ xa

Truyền dữ liệu bán thời gian thực là không cho trước thời gian trễ, thay vào đó, hệ thống phải truyền sao cho đảm bảo tính toàn vẹn của dữ liệu và toàn vẹn thời gian hiển thị, đồng thời giảm thời gian trễ ở mức tối đa Ví dụ của việc truyền dữ liệu bán thời gian thực là dịch vụ video theo yêu cầu Hệ thống này có thể có độ trễ ban đầu lớn để đổi lấy chất lượng video mịn trong quá trình play (Hình 1.3)

Hình 1.3 Truyền dữ liệu bán thời gian thực

1.2.3 Các phương pháp truyền dữ liệu đa phương tiện

Việc truyền dữ liệu trên mạng máy tính đã được thực hiện từ lâu, và có rất nhiều phương pháp khác nhau để áp dụng Trong đó phương pháp download là phương pháp phổ biến nhất để truyền dữ liệu đa phươn tiện từ server tới client

Hình 1.4 Tương tác giữa client và server trong mô hình download

Đặc điểm của phương pháp: Trước tiên đối tượng dữ liệu phải được nhận về toàn bộ và lưu trong bộ đệm hoặc file trước khi được giải mã và hiển thị Khi đối tượng dữ liệu đã được client nhận đầy đủ thì việc giải mã và hiển thị dữ liệu đó sẽ được thực hiện như trên hệ thống file nội bộ của client Mô hình này hoạt động tốt trong một số ứng dụng nhưng lại không phù hợp với

dữ liệu liên tục

Giả sử quá trình download như trong Hình 1.5, bỏ qua thời gian xử lý, thời gian từ khi bắt đầu yêu cầu đến khi có thể hiển thị được dữ liệu được tính theo kích thước của đối tượng dữ liệu và tốc độ truyền Với những ứng dụng như WWW thì dữ liệu thường là văn bản HTML, hoặc ảnh nhỏ thì độ trễ này

tương đối nhỏ

Tuy nhiên, với đối tượng dữ liệu liên tục thì độ trễ có thể sẽ rất lớn, đến mức không chấp nhận được

Hình 1.5 Thời gian bắt đầu trễ trong mô hình download

Nhược điểm cơ bản của mô hình download (được thể hiện trên Hình 1.6) là nó yêu cầu phải tải toàn bộ đối tượng video về thì mới bắt đầu hiển thị được

Hình 1.6 Thời gian trễ để download 5.4 GB video

Từ đặc điểm này mà người ta đã cải tiến mô hình download thành mô hình Streaming như sau:

b Mô hình Streaming

Trong mô hình streaming, dữ liệu liên tục sẽ được phát lại trong khi quá trình nhận dữ liệu về vẫn tiếp diễn (minh họa trong Hình 1.7) Sau khi gửi yêu

cầu tới server để bắt đầu quá trình streaming client sẽ đợi gói dữ liệu đầu tiên tới và bắt đầu phát lại, trong khi nhận gói dữ liệu thứ 2, và cứ nhƣ thế Do đó, quá trình phát lại và quá trình nhận dữ liệu đƣợc thực hiện song song

Hình 1.7 Play từng phần dữ liệu trong mô hình streaming

So sánh với mô hình download thì cần phải đáp ứng thêm 2 yêu cầu sau

để mô hình streaming có thể hoạt động Thứ nhất, dữ liệu đa phương tiện phải

có thể chia nhỏ thành các đoạn độc lập, các đoạn này có thể được giải mã và phát lại Hầu hết các dữ liệu liên tục như audio, video đều có tính chất này Thứ hai, để bảo toàn bộ định thời trong khi hiển thị hay trình diễn, ta cần đảm bảo các đoạn dữ liệu sẽ được nhận về trước thời điểm dự kiến sẽ hiển thị nó Đây chính là yêu cầu về tính liên tục, một trong các tham số chủ đạo trong thiết kế và đánh giá hệ thống đa phương tiện liên tục

c So sánh các phương pháp truyền dữ liệu đa phương tiện

 Phương pháp tải xuống (download)

 Phương pháp tải theo dòng (streaming)

Với sự phát triển nhanh của công nghệ mạng thì người ta có thể đặt ra câu hỏi rằng liệu trong tương lai mạng máy trính sẽ có thể có thông lượng rất lớn khiến cho thời gian truyền sẽ không đáng kể ngay cả khi dùng mô hình download hay không? Đây vẫn là một câu hỏi hỏi hợp lý, nhưng mô hình streaming một mặt có thể giúp cho việc hiển thị được tiến hành sớm hơn, mặt khác nó còn mang đến một cải tiến khác: truyền đồng thời nhiều dòng

Các media server thường đồng thời phục vụ nhiều clients Khi nhiều client yêu cầu dịch vụ cùng lúc, sẽ có 2 lựa chọn cho media server khi dùng mô hình download: Một là phục vụ các clients một cách tuần tự hoặc phục vụ đồng thời Nếu phục vụ tuần tự thì các client thứ 2 trở đi trong hàng đợi sẽ phải chờ rất lâu mặc dù thông lượng mạng có thể rất lớn Nếu phục vụ đồng thời thì thông lượng mạng dành cho từng client sẽ giảm do đó sẽ kéo dài thời gian download

Ngược lại, mô hình streaming sẽ không mắc phải vấn đề này, quá trình hiển thị sẽ được thực hiện ngay khi một đoạn dữ liệu đa phương tiện được nhận về (Hình 1.8) Thời gian chờ để bắt đầu hiển thị độc lập với số lượng client yêu cầu đồng thời miễn sao media server và mạng không bị quá tải

Hình 1.8 Multistream pipelining trong mô hình streaming

1.3 CÁC ỨNG DỤNG TRUYỀN THÔNG ĐA PHƯƠNG TIỆN

Chúng ta có thể chia các ứng dụng truyền thông đa phương tiện thành 3 lớp lớn

1.3.1 Truyền video và audio đã được lưu trữ trên server

Trong lớp ứng dụng này, client yêu cầu các tệp tin audio, video đã được nén và lưu trữ trên server Các tệp tin audio có thể là bài giảng, bài hát … Các tệp tin video có thể là phim, clips … Tại một thời điểm nào đó, client yêu cầu tệp tin audio, video từ server Trong hầu hết các ứng dụng loại này, sau một thời gian trễ vài giây, client sẽ chạy tệp tin audio, video trong khi tiếp tục nhận tệp tin từ server Đặc tính vừa chạy tệp tin, trong khi tiếp tục nhận những phần sau của tệp tin gọi là streaming Nhiều ứng dụng còn cung cấp tính năng tương tác người dùng Ví dụ: pause, resume, jump, skip Khoảng thời gian từ lúc người dùng đưa ra yêu cầu (play, skip, forward, jump) tới khi bắt đầu nghe thấy trên máy client nên nằm trong khoảng từ 1 – 10 giây để người dùng có thể chấp nhận được

1.3.2 Truyền trực tiếp audio/video (Streaming live audio/video)

Các ứng dụng loại này cũng tương tự như phát thanh và truyền hình quảng bá truyền thống chỉ có điều nó được thực hiện trên internet Nó cho phép người dùng nhận được audio/video trực tiếp được phát ra từ bất kỳ nơi

nào trên thế giới Trong lớp ứng dụng mạng đa phương tiện loại này, audio/video được truyền trực tiếp, không được lưu trữ trên server như loại ứng dụng mạng đa phương tiện đã nói ở trên, người dùng không thể tương tác người như: pause, forward, rewind được Tuy nhiên, nếu các tiệp tin audio/video được lưu giữ cục bộ tại các client, thì người dùng có thể pause, rewind được

1.3.3 Ứng dụng tương tác audio/video thời gian thực

Lớp ứng dụng này cho phép người dùng audio, video để tương tác thời gian thực với người dùng khác Một ví dụ về audio tương tác thời gian thực là điện thoại internet Nó cung cấp dịch vụ điện thoại với giá rất rẻ so với dịch vụ điện thoại truyền thống nhưng bù vào đó là chất lượng không được tốt và ổn định như điện thoại truyền thống Với tương tác video thời gian thực, còn gọi là video-conferenceing, mọi người có thể giao tiếp với nhau một cách rất trực quan Trong các ứng dụng tương tác audio/video thời gian thực thì độ trễ nên nhỏ hơn vài trăm mili giây Ví dụ với âm thanh: độ trễ nên nhỏ hơn 400 ms

1.3.4 Ứng dụng video conference

Như đã đề cập ở trên, video conference là ứng dụng mạng đa phương tiện thuộc lớp thứ ba: ứng dụng tương tác thời gian thực Đây là lớp ứng dụng đòi hỏi chất lượng dịch vụ mạng (độ trễ, jitter, sự mất mát gói tin) cao nhất trong ba lớp ứng dụng ở trên để thoả mãn nhu cầu của người dùng Video conference hiện nay được sử dụng rộng rãi trong rất nhiều lĩnh vực: trong cuộc họp của các công ty, các tổ chức; trong giáo dục: đào tạo từ xa; trong y tế: khám chữa bệnh, phẫu thuật từ xa

CHƯƠNG 2

GIẢI PHÁP KỸ THUẬT WEBRTC

Như chúng ta đã thấy, để liên lạc với bạn bè bằng những cuộc gọi video thông qua Yahoo Messenger, Skype là những sự lựa chọn tối ưu Đặc điểm chung của chúng là mã nguồn đóng và được phát triển bởi những công ty phần mềm lớn trên thế giới và đặc biệt chúng ta cần cài đặt ứng dụng, tạo một tài khoản để sử dụng Với sự xuất hiện của chuẩn WebRTC, một bộ mã nguồn

mở, thì việc thực hiện những điều trên trở nên dễ dàng hơn bao giờ hết Vậy, WebRTC là gì?

2.1 GIỚI THIỆU CHUNG

WebRTC là tên viết tắt của cụm từ Web Real – Time Communications

Nó có nghĩa là truyền thông thời gian thực trên nền Web

Hình 2.1 Mô hình WebRTC

WebRTC là một công nghệ với tập hợp các tiêu chuẩn, các giao thức,

bộ API viết bằng JavaScript để nỗ lực đưa truyền thông thời gian thực cho người dùng lên tất cả các trình duyệt mà không cần phải cài đặt bất kỳ plugin của nhà phát triển ứng dụng bên thứ ba nào

Tập các giao thức là một tập hợp các quy tắc chuẩn dành cho việc biểu diễn dữ liệu, phát tín hiệu, chứng thực và phát hiện lỗi dữ liệu, những việc cần thiết để gửi thông tin qua các kênh truyền thông, nhờ đó mà các máy tính (và

các thiết bị) có thể kết nối và trao đổi thông tin với nhau Một số giao thức sử dụng trong WebRTC như TCP, UDP, ICE, TURN, STUN, SCTP, SRTP,

DTLS…

WebRTC cho phép thực hiện các kết nối âm thanh, video, chia sẻ dữ liệu giữa các trình duyệt một cách ngang hàng (peer-to-peer) WebRTC biến thông tin liên lạc thời gian thực thành một tính năng tiêu chuẩn mà bất kỳ ứng dụng web có thể tận dụng thông qua một số API JavaScript [9]

2.2 LỊCH SỬ PHÁT TRIỂN

Trong lịch sử, truyền thông RTC chỉ được dùng trong các doanh nghiệp Nó sử dụng công nghệ truyền tải audio và video rất phức tạp với những ràng buộc hết sức chặt chẽ và chi phí lắp đặt rất cao Một số sản phẩm của một số hãng khi đó đã hỗ trợ giao tiếp RTC như Google với Google Talk, Yahoo với Yahoo Messenger, Microsoft với Skype… Một trong những thách thức lớn nhất cho các trang web là cho phép con người giao tiếp thông qua giọng nói và video: giao tiếp thời gian thực hay RTC - Real Time Communication [9]

Ý tưởng phát triển WebRTC được đưa ra bởi nhóm phát triển Google Hangouts từ năm 2009 Vào thời gian đó, để truyền tải video, hình ảnh trên web, người sử dụng phải cài đặt Flash và các plugin Đến Năm 2010, Google mua lại hai công ty là On2 và Global IP Solutions (GIPS) Sau đó họ chuyển các công nghệ liên quan đến RTC của hai công ty này thành mã nguồn mở và kết hợp với IETF và W3C để đưa ra WebRTC vào năm 2011 Tháng 6/2011, được đánh dấu

là thời gian bộ mã nguồn mỡ API của chuẩn WebRTC chính thức được giới thiệu rộng rãi, cung cấp miễn phí, xây dựng trên nền web [11]

2.3 KIẾN TRÚC VÀ PHƯƠNG THỨC HOẠT ĐỘNG CỦA WEBRTC

2 Các nhà phát triển ứng dụng web sẽ quan tâm đến các web API

Hình 2.2 Mô hình kiến trúc WebRTC

Để có thể tích hợp các ứng dụng thời gian thực vào web, các browser phải thêm vào các khối chức năng hỗ trợ dành cho WebRTC:

 Voice/video engine: Dùng để thu nhận âm thanh và hình ảnh từ thiết

bị ngoại vi (microphone, camera), điều chế mã hoá âm thanh và hình ảnh dựa trên các chuẩn mã hoá cơ bản trước khi truyền Các chuẩn mã hoá cơ bản

dành cho voice và video bao gồm: Opus, iSac, iLBC <voice>, VP8, H263, H264 (video)

 Transport: cũng cấp chức năng kết nối với các thành phần khác cùng tham gia trong WebRTC (STUN, TURN, ICE )

 Session management: đóng vai trò điều khiển hoạt động của ứng dụng

 Application Programming Interface - API: cung cấp các hàm cơ bản

để các nhà phát triển có thể sử dụng API ở đây có thể xét nằm trên hai mức

cơ bản: API dành cho Browser developer và API dành cho Front end developer

2.3.2 Phương thức hoạt động

Trong mô hình hoạt động truyền thống của web, mô hình client - server được sử dụng khá là phổ biến khi mà server sẽ đảm nhiệm tất cả bao gồm: điều khiển, truyền dữ liệu, security Tuy nhiên, nếu áp dụng mô hình này vào trong các ứng dụng thời gian thực sẽ ảnh hướng tới hiệu năng hoạt động của ứng dụng vì các lý do sau:

 Khối lượng dữ liệu trao đổi giữa các client là cực kỳ lớn Chuẩn mã hoá voice OPUS có bitrate dao động từ 6 Kbps cho tới 510 Kbps Nếu dữ liệu này truyền trực tiếp tới server để server truyền tải tới client thì sẽ xảy ra việc quá tải không chỉ dành cho server mà cho cả hệ thống mạng

 Chất lượng dịch vụ (Quality of service - QoS) Trong QoS dành cho các ứng dụng thời gian thực, có hai tham số cực kỳ quan trọng cần được giảm thiểu tối đa là delay (trễ client) và jitter (trễ giữa các gói tin) Việc phải truyền tải toàn bộ dữ liệu tới server sẽ gia tăng rủi do trong delay và jitter

Do đó, các ứng dụng thời gian thực đòi hỏi một mô hình khác có thể đáp ứng được hai yêu cầu trên, đó là mô hình Peer-to-Peer (P2P) Trong mô hình này, dữ liệu truyền tải được chia ra làm hai loại: dữ liệu điều khiển, báo

hiệu (Signalling) và dữ liệu nội dung (Data stream) Các máy client thường sẽ giao tiếp với server để gửi/nhận các tín hiệu điều khiển và sau đó sẽ truyền nhận trực tiếp dữ liệu với các client khác

Hình 2.3 Kênh báo hiệu trong WebRTC

Lấy một ví dụ đơn giản về Video chat sử dụng WebRTC:

1 Caller và Callee khi bắt đầu sử dụng ứng dụng phải gửi các tín hiệu

về ứng dụng mà mình đang sử dụng tới server (session description)

2 Caller gọi: Caller request tới server để đăng ký một cuộc gọi với Callee, server sẽ trả về cho Caller địa chỉ IP của Callee cùng với port ứng dụng hiện tại của Callee

3 Callee sẽ nhận một bản tin của server báo về một cuộc gọi từ phía caller

4 Caller bắt đầu truyền dữ liệu từ phía mình trực tiếp sang Callee

5 Caller/callee ngắt kết nối: thông báo về server và dừng truyền dữ liệu

Tuy nhiên, trên thực tế, các peer đều sử dụng các địa chỉ IP private (thuộc các dải: 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8) và sử dụng cơ chế NAT để kết nối internet, do đó việc kết nối trực tiếp giữa các peer sẽ gặp khó khăn nếu sử dụng dải mạng nội bộ Do đó, chúng ta phải có cơ chế hỗ trợ phân giải sang địa chỉ IP public

Hình 2.4 Máy chủ STUN

Để tiết kiệm địa chỉ IP, rất nhiều các nhà điều hành mạng sử dụng cơ chế NAT để chuyển đổi từ địa chỉ IP mạng nội bộ sang địa chỉ IP Public Về

cơ bản địa chỉ IP sẽ đƣợc chuyển đổi nhƣ sau : IP private <-> IP public: port

Trong đó port ở đây là các cổng ứng dụng nằm trên firewall hay router Điều này giúp cho nhiều địa chỉ IP nội bộ có thể sử dụng chung IP public STUN server sẽ đóng vai trò trung gian giúp cho các peer có thể lấy đƣợc địa chỉ của peer khác Hiện nay, google đã xây dựng một số STUN server hỗ trợ hoàn toàn miễn phí nhƣ stun:stun.l.google.com:19302

Hình 2.5 TURN server và STUN server

Trong mô hình OSI, tại lớp vận chuyển (Transport layer) có hai giao thức nổi tiếng là TCP và UDP Trong khi UDP cung cấp khả năng vận chuyển nhanh nhất có thể thì TCP lại đảm bảo truyền tin cậy Hầu hết trong các ứng dụng thời gian thực, tín hiệu điều khiển sẽ sử dụng TCP trong khi dữ liệu sẽ truyền bằng UDP Tuy nhiên, UDP không phải là cơ chế truyền tin cậy, dễ làm tăng số lượng các gói tin bị mất, do vậy đôi khi TCP được ưu tiên sử dụng

Trong mô hình peer-to-peer, dữ liệu thay vì được gửi trực tiếp tới các peer thì các peer sẽ gửi dữ liệu tới các TURN server và TURN server sẽ đóng vai trò trung gian vận chuyển gói tin Điều này nâng cao không những chất lượng dịch vụ của ứng dụng mà còn đảm bảo an toàn thông tin khi truyền dẫn

2.4 CÁC GIAO THỨC MẠNG TRUYỀN THÔNG THỜI GIAN THỰC

Đầu tiên, một điểm then chốt của truyền tải dữ liệu thời gian thực là giao thức mạng sử dụng để truyền tải nó tới người dùng khác WebRTC sử

dụng giao thức UDP để truyền tín hiệu, dữ liệu đi Trong WebRTC các ứng dụng chia sẻ audio và video được thiết kế với mục đích làm giảm thiểu khả năng mất mát gói tin liên tục trong một thời gian dài Các công cụ mã hóa gói tin audio và video có thể thêm, hay bổ sung những phần gói tin bị thiếu, bị mất trong quá trình truyền tải, một phần dữ liệu nhỏ Như vậy, các ứng dụng phải sử dụng logic để phục hồi các dữ liệu bị mất hay bị trì hoãn

Hình 2.6 Ngăn xếp giao thức WebRTC

Yêu cầu tính tức thời quan trọng hơn độ tin cậy nên đó là lý do chính tại sao giao thức UDP là một giao thức truyền thông tốt để truyền các dữ liệu thời gian thực trong WebRTC TCP cũng được sử dụng bởi tính đáng tin cậy

và đúng tuần tự của nó, nếu gói tin trung gian bị mất trong quá trình truyền,

dữ liệu sẽ được truyền lại với cơ chế hạn chế tắc nghẽn đường truyền

UDP là nền tảng trong giao tiếp thời gian thực trong trình duyệt nhưng

để đáp ứng tất cả các yêu cầu khắt khe của WebRTC, trình duyệt cũng cần rất nhiều giao thức giao vận và dịch vụ khác hỗ trợ nó Hình 2.8 mô tả ngăn xếp các giao thức và dịch vụ hỗ trợ trình duyệt trong WebRTC, trong đó:

ICE

ICE là một giao thức được tiêu chuẩn hóa bởi IETF (RFC- 5245) [2] Giao thức ICE được dùng để thiết lập phiên media dựa trên UDP đi qua NAT một cách nhanh nhất

Cũng giống như các hệ thống VoIP, WebRTC bị cản trở khi tạo kết nối peer-to-peer bởi tường lửa và NAT WebRTC sử dụng giao thức ICE để tạo kênh giao tiếp giữa các peer nhờ STUN và TURN server [12] ICE cố gắng tìm ra con đường tốt nhất để kết nối giữa các peer, nó thử tất cả các khả năng

có thể kết nối một cách song song và lựa chọn một con đường kết nối hiệu quả nhất Đầu tiên, ICE thử kết nối trực tiếp giữa hai peer bằng cách sử dụng địa chỉ thu được từ hệ điều hành và card mạng của thiết bị; nếu thất bại (có thể do thiết bị ở đằng sau một NAT), ICE lấy địa chỉ bên ngoài của thiết bị bằng cách sử dụng một máy chủ STUN, và nếu không thành công, lưu lượng mạng được chuyển qua một máy chủ chuyển tiếp TURN server

ICE được chạy vào lúc bắt đầu của một phiên trước khi thiết lập phiên SRTP giữa các trình duyệt

STUN

STUN (Session Traversal Utilities for NAT) là một giao thức mạng cho phép các máy khách tìm ra địa chỉ công khai của mình, loại NAT mà chúng đang đứng sau và cổng phía Internet được NAT gắn liền với cổng nội bộ nào

đó Thông tin này được sử dụng để thiết lập giao tiếp UDP giữa 2 host mà đều nằm sau NAT router Giao thức STUN được định nghĩa trong RFC 5389 [13]

Trong WebRTC, một STUN client được xây dựng sẵn trong user agent của trình duyệt, và các máy chủ web sẽ chạy một máy chủ STUN Gói tin kiểm tra STUN được gửi trước khi thiết lập phiên để cho phép trình duyệt biết nếu nó đang ở đằng sau một NAT và để khám phá các địa chỉ ánh xạ và cổng của nó Thông tin này sau đó được sử dụng để xây dựng các địa chỉ ứng cử viên trong kỹ thuật ICE "hole punching" STUN có thể được vận chuyển qua UDP, TCP, hoặc TLS [1]

TURN

TURN là một mở rộng của giao thức STUN, nó cung cấp một chuyển tiếp