(Luận văn thạc sĩ) nghiên cứu giao tiếp thời gian thực trên web WebRTC và ứng dụng xây dựng hệ thống webchat thời gian thực

ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

KHÚC NGỌC HIỆP

NGHIÊN CỨU GIAO TIẾP THỜI GIAN THỰC TRÊN WEB
WEBRTC VÀ ỨNG DỤNG XÂY DỰNG HỆ THỐNG WEB
CHAT THỜI GIAN THỰC
LUẬN VĂN THẠC SỸ

Hà Nội - 2014


ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

KHÚC NGỌC HIỆP

NGHIÊN CỨU GIAO TIẾP THỜI GIAN THỰC TRÊN WEB
WEBRTC VÀ ỨNG DỤNG XÂY DỰNG HỆ THỐNG WEB
CHAT THỜI GIAN THỰC
Ngành:Công nghệ thông tin
Chuyên ngành: Công nghệ phần mềm
Mã số: 60480103

LUẬN VĂN THẠC SỸ
NGƯỜI HƯỚNG DẪN KHOA HỌC: PGS. TS. TRƯƠNG NINH THUẬN
TS. TRỊNH THANH BÌNH

Hà Nội - 2014

LỜI CAM ĐOAN
Tôi xin cam đoan rằng đây là công trình nghiên cứu của riêng tơi. Các số liệu và kết
quả nghiên cứu trong luận văn này là trung thực vàkhơng sao chép của bất kỳ ai. Các
thơng tin trích dẫn trong luận văn đã đƣợc chỉ rõ nguồn gốc.

Hà Nội, ngày

tháng

Học viên

Khúc Ngọc Hiệp

1

năm 2014


TÓM TẮT
WebRTC là một nỗ lực để xây dựng một framework mở có khả năng giao tiếp
audio và video thời gian thực, nó có thể biến các trình duyệt web thành một nền tảng
cho giao tiếp giữa ngƣời với ngƣời. Giao tiếp thời gian thực trong trình duyệt web đã
có trƣớc đây tuy nhiênchúng ta phải cài đặt phần mềm của bên thứ ba lên trình duyệt
web. WebRTC mang lại hỗ trợ giao tiếp thời gian thực từ ngay bên trong các trình
duyệt web và các nhà phát triển web có thể sử dụng một cách tự do thơng qua các
JavaScript API tiêu chuẩn. Điều này mang lại giao tiếp thời gian thực nhƣ là một tính
năng cho web, có thể thúc đẩy sự đổi mới hơn nữa.
Luận văn này nghiên cứu chuyên sâu về WebRTC, các kiến trúc và mơ hình trong
WebRTC, các giao thức và kỹ thuật đƣợc sử dụng trong WebRTC, các API của

WebRTC và các vấn đề về bảo mật và tính riêng tƣ đƣợc giải quyết trong WebRTC.
Dựa trên kết quả nghiên cứu về lý thuyết cho WebRTC và hiện trạng của hệ thống
hỗ trợ khách hàng trực tuyến của các website thƣơng mại điện tử ở Việt Nam phải sử
dụng các ứng dụng chat bên ngồi nhƣ Yahoo messenger và Skype, chúng tơi đã tiến
hành xây dựng một ứng dụng web chat thời gian thực sử dụng WebRTC để cải tiến hệ
thống hỗ trợ khách hàng này. Khách hàng sẽ không phải cài đặt thêm một ứng dụng
hoặc plugin nào để có thể chat video, gửi tin nhắn và gửi file với nhân viên hỗ trợ
khách hàng ngay trên trình duyệt web.
Chúng tơi thấy rằng WebRTC là một công nghệ rất khả thi, và rất thích hợp cho
trƣờng hợp giao tiếp một một từ trình duyệt đến trình duyệt. Mặc dù chúng tơi phát
hiện ra một số thách thức chƣa đƣợc giải quyết, chúng tôi không thấy bất kỳ trở ngại
không thể vƣợt qua nào sẽ ngăn cản việc chấp nhận WebRTC. WebRTC mở ra những
cơ hội cho các công ty sẽ sử dụng nó trực tiếp để cung cấp một dịch vụ giao tiếp thời
gian thực trên web, nó cũng tạo ra khơng gian cho các nhà cung cấp PaaS WebRTC
trên thị trƣờng. Thêm vào đó, WebRTC cho phép kết nối với các hệ thống cũ nhƣ
PSTN hay PLMN, mở ra cơ hội cho các nhà cung cấp viễn thông để khám phá tạo ra
cách thức truyền thông mới cho khách hàng của họ.

2


MỤC LỤC
LỜI CAM ĐOAN.................................................................................................. 1
TÓM TẮT ............................................................................................................. 2
MỤC LỤC ............................................................................................................. 3
DANH SÁCH HÌNH VẼ ...................................................................................... 5
DANH SÁCH BẢNG ........................................................................................... 5
BẢNG TỪ VIẾT TẮT .......................................................................................... 6
MỞ ĐẦU ............................................................................................................... 7
CHƢƠNG 1: GIỚI THIỆU VỀ TRUYỀN THÔNG WEB THỜI GIAN THỰC WEBRTC .............................................................................................................. 9

1.1 Ngắn gọn về lịch sử của WebRTC .....................................................................9
1.2 Kiến trúc của WebRTC ....................................................................................10
1.3 Chồng giao thức trong WebRTC .....................................................................13
1.4 Các API của WebRTC ......................................................................................19
1.5 Kênh báo hiệu trong WebRTC ........................................................................20
1.6 Bảo mật trong WebRTC ...................................................................................21

CHƢƠNG 2: GIỚI THIỆU VỀ EASYRTC FRAMEWORK ............................ 23
2.1 Giới thiệu về EasyRTC framework .................................................................23
2.2 Cài đặt và chạy máy chủ EasyRTC .................................................................24
2.3 Sử dụng EasyRTC .............................................................................................26
2.4 Một số API tiện ích khác của EasyRTC ..........................................................30

CHƢƠNG 3: SỬ DỤNG EASYRTC FRAMEWORK ĐỂ XÂY DỰNG ỨNG
DỤNG WEB CHAT THỜI GIAN THỰC .......................................................... 33
3.1 Phân tích hệ thống .............................................................................................33
3.1.1 Mục tiêu tổng thể của ứng dụng web chat thời gian thực ......................33
3.1.2 Thực trạng của hệ thống tư vấn bán hàng trực tuyến ...........................33
3.1.3 Phân tích yêu cầu của ứng dụng ...............................................................39
3.2 Thiết kế ứng dụng .............................................................................................39
3.2.1 Biểu đồ trường hợp sử dụng .....................................................................39
3.2.2 Biểu đồ tuần tự ...........................................................................................43
3.2.3 Biểu đồ lớp ..................................................................................................45
3.2.4 Thiết kế giao diện .......................................................................................46
3.3 Thực hiện ứng dụng ..........................................................................................47

3


3.4 Chạy thử và đánh giá ứng dụng.......................................................................50

3.4.1 Chạy thử ứng dụng ....................................................................................51
3.4.2 Đánh giá ứng dụng .....................................................................................57

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

4


DANH SÁCH HÌNH VẼ

Hình 1: Kiến trúc tổng thể của WebRTC [3]. ..................................................... 11
Hình 2: Kiến trúc bên trong của WebRTC [8]. ................................................... 12
Hình 3: Chồng giao thức trong WebRTC [1]...................................................... 14
Hình 4: Kênh báo hiệu trong WebRTC. ............................................................. 21
Hình 5: Góc hỗ trợ khách hàng trực tuyến trên website trananh.vn. .................. 34
Hình 6: Góc hỗ trợ khách hàng trực tuyến trên website mediamart.vn. ............ 34
Hình 7: Góc hỗ trợ khách hàng trực tuyến trên website nama.vn. ..................... 35
Hình 8: Lựa chọn hỗ trợ thông qua Skype trên website trananh.vn. .................. 36
Hình 9: Trình duyệt yêu cầu khách hàng cho phép bật ứng dụng Skype trên máy
tính. ...................................................................................................................... 36
Hình 10: Màn hình đăng nhập Skype trên máy tính. .......................................... 37
Hình 11: Màn hình đăng nhập Skype trên máy tính - tiếp. ................................. 37
Hình 12: Bắt đầu chat với nhân viên hỗ trợ khách hàng. .................................... 38
Hình 13: Biểu đồ trƣờng hợp sử dụng. ............................................................... 40
Hình 14: Biểu đồ tuần tự. .................................................................................... 45
Hình 15: Biểu đồ lớp. .......................................................................................... 46
Hình 16: Thiết kế wireframe cho ứng dụng web chat......................................... 47
Hình 17: Nhân viên mở trang hỗ trợ khách hàng bên trong phần quản trị của
website. ................................................................................................................ 51

Hình 18: Nhân viên hỗ trợ khách hàng đăng nhập vào phòng hỗ trợ mà họ chịu
trách nhiệm. ......................................................................................................... 52
Hình 19: Khách hàng xem sản phẩm và tìm đến góc hỗ trợ khách hàng. .......... 52
Hình 20: Khách hàng lựa chọn Gọi nhân viên hỗ trợ "Kinh doanh điện thoại". 53
Hình 21: Khách hàng lựa chọn kết nối với nhân viên hỗ trợ sau khi đã đăng
nhập. .................................................................................................................... 53
Hình 22: Trình duyệt yêu cầu quyền truy cập tới máy ảnh và microphone........ 54
Hình 23: Nhân viên hỗ trợ nhận đƣợc yêu cầu kết nối từ khách hàng và đồng ý
kết nối. ................................................................................................................. 54
Hình 24: Nhân viên hỗ trợ và khách hàng nói chuyện, chia sẻ webcam và gửi tin
nhắn với nhau. ..................................................................................................... 55
Hình 25: Gửi file khi đang nói chuyện................................................................ 55
Hình 26: Nhận file và lƣu lại trên máy tính. ....................................................... 56
Hình 27: Ứng dụng chạy trên điện thoại Android với trình duyệt Chrome cho
Android................................................................................................................ 56
DANH SÁCH BẢNG

Bảng 1: Bảng mô tả các trƣờng hợp sử dụng. ..................................................... 43
5


BẢNG TỪ VIẾT TẮT
Từ viết tắt

Giải nghĩa

WebRTC

Web Real-Time Communications

PaaS

Platform as a Service

PSTN

Public Switched Telephone Network

PLMN

Public Land Mobile Network

WWW

World Wide Web

SIP

Session Initiation Protocol

VoIP

Voice over Internet Protocol

IETF

Internet Engineering Task Force

W3C

World Wide Web Consortium

TCP

Transmission Control Protocol

UDP

User Datagram Protocol

STUN

Session Traversal Utilities for NAT

TURN

Traversal Using Relays around NAT

SDP

Session Description Protocol

DTLS

Datagram Transport Layer Security

SCTP

Stream Control Transport Protocol

SRTP

Secure Real-Time Transport Protocol

ICE

Interactive Connectivity Establishment

6


MỞ ĐẦU
World Wide Web (WWW hay Web) là hệ thống đƣợc biết đến rộng rãi nhất đƣợc
truy cập qua Internet. Hơn nữa, đối với đa số ngƣời sử dụng Internet, từ "Internet" là
tƣơng đƣơng với Web. Đối với họ, Internet là những gì bạn truy cập đƣợc thơng qua
trình duyệt web. Hai yếu tố này liên kết với nhau hơn nữa tại vì sự phát triển các tính
năng và dịch vụ web cung cấp có tác động đến các phần khác của hệ sinh thái Internet,
ví dụ các hệ thống khác, các nhà cung cấp dịch vụ, doanh nghiệp và ngƣời sử dụng. Vì
lý do đó, sự phát triển của web là một thành phần quan trọng trong sự phát triển của
bản thân Internet.
Ban đầu các trang web, cũng nhƣ các trình duyệt web - giao diện để truy cập web chỉ có dạng văn bản đơn giản. Sau đó, một trong những cột mốc quan trọng đầu tiên
trong sự phát triển của web là sự ra đời của trình duyệt web Mosaic, trong đó có một
giao diện ngƣời dùng hiển thị cả đồ họa và văn bản, nó trở thành phổ biến trong các tài
liệu trên web. Sau đó, sự phát triển trong các trình duyệt web hiện đại và các công
nghệ hỗ trợ đã mang các nội dung đa phƣơng tiện đƣa lên web. Video và audio, hình
ảnh tĩnh và hình ảnh động cùng đƣợc sử dụng trong các trang web tƣơng tác, đã trở
thành một chuẩn mực.
Tuy nhiên, nội dung đa phƣơng tiện chủ yếu là chỉ là nội dung tĩnh đƣợc sản xuất
trƣớc đó và phát hành, sau đó đƣợc gửi lên web để đến với mục tiêu ngƣời nhận. Web,
mặt khác, ngày càng trở nên một nền tảng cho truyền thông, thúc đẩy bởi sự gia tăng

của các mạng xã hội, một địa điểm nơi con ngƣời có thể thể hiện bản thân và chia sẻ
với bạn bè, gia đình các mảnh khác nhau trong cuộc sống của họ. Bất cứ khi nào khi
thông tin liên lạc thời gian thực là cần thiết, nếu không nhờ đến sự trợ giúp của phần
mềm bổ sung khác, các trang web chỉ có thể cung cấp tin nhắn tức thời dựa trên văn
bản.
Giao tiếp web thời gian thực (Web Real-Time Communications - WebRTC), là một
nỗ lực để loại bỏ hạn chế này của web đƣợc điều hành bởi một số nhà cung cấp trình
duyệt chính (Google, Mozilla, Microsoft, Opera) và các công ty nổi tiếng khác (Cisco,
Ericsson, vv). WebRTC là một framework mở có khả năng giao tiếp audio và video
thời gian thực, nó biến các trình duyệt web thành một nền tảng truy cập chung để giao
tiếp giữa ngƣời với ngƣời. Trong khi hội thoại và video thời gian thực không phải là
mới với Internet, cho đến nay nó chỉ sử dụng đƣợc trong trình duyệt web bằng cách cài

7


đặt thêm phần mềm của bên thứ ba, chẳng hạn nhƣ Adobe Flash [15] hoặc Skype plugin. WebRTC mang lại hỗ trợ cho giao tiếp thời gian thực cho các trình duyệt web và
giúp các nhà phát triển web sử dụng một cách tự do thông qua Javascript API đƣợc
tiêu chuẩn hóa.
Cấu trúc của luận văn:
Ngồi phần tóm tắt, kết luận và phụ lục. Luận văn đƣợc chia thành ba chƣơng nhƣ
sau:
 Chƣơng 1: Tổng quan lý thuyết. Chƣơng này đƣợc dành để nói về kiến trúc
của WebRTC và các kỹ thuật đƣợc sử dụng trong nền tảng này.
 Chƣơng 2: Tìm hiểu về EasyRTC framework. Chƣơng này chúng tơi tìm
hiểu về một framework đƣợc xây dựng trên nền WebRTC để hỗ trợ các nhà
phát triển trong việc xây dựng các ứng dụng có sử dụng WebRTC.
 Chƣơng 3: Sử dụng EasyRTC framework để xây dựng ứng dụng web chat
thời gian thực. Chƣơng này chúng tôi sẽ đi vào xây dựng một hệ thống web
chat thời gian thực sử dụng WebRTC để hỗ trợ cho hệ thống hỗ trợ khách

hàng trực tuyến của các website thƣơng mại điện tử.

8


CHƯƠNG 1: GIỚI THIỆU VỀ TRUYỀN THÔNG WEB THỜI GIAN
THỰC - WEBRTC
Hãy tƣởng tƣợng một thế giới nơi mà điện thoại, TV và máy tính của chúng ta đều
có thể giao tiếp trên cùng một nền tảng chung. Hãy tƣởng tƣợng rằng chúng ta có thể
dễ dàng thêm vào tính năng video chat và chia sẻ dữ liệu peer-to-peer cho ứng dụng
web. Đó là tầm nhìn của WebRTC.
Trƣớc đây khi chƣa có cơng nghệ WebRTC, chúng ta vẫn có thể thực hiện các cuộc
gọi video, audio và chat trên trình duyệt, tuy nhiên nó địi hỏi phải cài đặt thêm các
plugin cho trình duyệt, và thậm chí cả hai ngƣời thực hiện cuộc gọi cùng phải cài đặt
một loại plugin. Và nếu ngƣời sử dụng chuyển sang một máy tính khác hoặc sử dụng
một trình duyệt web khác, thì lại phải cài đặt lại plugin để có thể thực hiện cuộc gọi
đƣợc. Việc sử dụng plugin thƣờng hay gặp phải các vấn đề về bảo mật và gây khó
khăn cho ngƣời sử dụng.
Hiện tại, WebRTC là công nghệ duy nhất cho phép truyền thơng thời gian thực
trong trình duyệt web mà không cần cài đặt thêm bất cứ một plugin hoặc ứng dụng nào
khác.
WebRTC là một nỗ lực của ngành công nghiệp để đƣa khả năng truyền thông thời
gian thực vào tất cả các trình duyệt web, cho phép các nhà phát triển web dễ dàng sử
dụng các tính năng này thông qua các thẻ HTML5 tiêu chuẩn và các JavaScript API.
Ví dụ, thực hiện một ứng dụng web có các tính năng tƣơng tự nhƣ các tính năng
Skype™ cung cấp mà không cần phải cài đặt thêm bất kỳ phần mềm hay plug-in nào
của bên thứ ba [1].

1.1 Ngắn gọn về lịch sử của WebRTC
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.
Trong lịch sử, RTC đã đƣợc thực hiện một cách rất phức tạp, địi hỏi các giấy phép
cơng nghệ audio và video rất tốn kém hoặc các công nghệ tự phát triển riêng. Việc tích
hợp cơng nghệ RTC với các nội dung, dữ liệu và các dịch vụ hiện có rất khó khăn và
tốn nhiều thời gian, đặc biệt là trên web.

9


Gmail video chat trở nên phổ biến trong năm 2008, và vào năm 2011 Google đã
giới thiệu Hangouts, nó sử dụng dịch vụ Google Talk (cũng giống nhƣ trong Gmail).
Google mua lại GIPS, một công ty đã phát triển nhiều thành phần cần thiết cho RTC,
chẳng hạn nhƣ các bộ codec và các kỹ thuật triệt tiếng dội. Google mở mã nguồn các
công nghệ đƣợc phát triển bởi GIPS và tham gia vào các tiêu chuẩn có liên quan tại tổ
chức IETF và W3C để đảm bảo sự đồng thuậncủa ngành công nghiệp [19].
WebRTC hiện nay đã thực hiện các tiêu chuẩn mở cho thời gian thực, không cần
plugin chotruyền thông video, audio và dữ liệu. Nhu cầu sử dụng WebRTC là có thật:
 Nhiều dịch vụ web đã sử dụng RTC, nhƣng cần phải tải về thêm các ứng
dụng hoặc plugin. Trong đó bao gồm Skype, Facebook (trong đó sử dụng
Skype) và Google Hangouts (sử dụng plugin Google Talk).
 Tải, cài đặt và cập nhật các plugin có thể phức tạp, dễ bị lỗi và gây phiền
nhiễu.
 Các plugin có thể khó khăn để triển khai, gỡ lỗi, khắc phục sự cố, kiểm thử
và bảo trì và nó có thể yêu cầu giấy phép và tích hợp với các cơng nghệ phức
tạp đắt tiền. Thƣờng thì rất khó để thuyết phục mọi ngƣời cài đặt plugin ngay
từ đầu.
Các nguyên tắc dẫn đƣờng của dự án WebRTC là các API của nó phảilà mã nguồn
mở, miễn phí, đƣợc tiêu chuẩn hóa, đƣợc xây dựng trong các trình duyệt web và phải
hiệu quả hơn so với các cơng nghệ hiện có.

WebRTC hiện tại vẫn chƣa hồn thiện, nó vẫn đang tiếp tục đƣợc xây dựng, cả ở
cấp độ API của trình duyệt và ở cấp độ giao thức. Tuy nhiên, một số trình duyệt web
đã hỗ trợ hầu hết các API của WebRTC nhƣ các trình duyệt Google Chrome, Opera và
Mozilla Firefox mới nhất [8].

1.2 Kiến trúc của WebRTC
Cho phép truyền thơng thời gian thực trong trình duyệt là một cam kết đầy tham
vọng, và có lẽ là một trong những bổ sung quan trọng nhất cho nền tảng web từ khi
đƣợc hình thành cho đến nay. Với kết quả là kiến trúc WebRTC bao gồm rất nhiều tiêu
chuẩn, giao thức và API mới để cho nó hoạt động:
 Tổ chức W3C chịu trách nhiệm định nghĩa các APIs mới của WebRTC cho
trình duyệt [2].

10


 Tổ chức IETF chịu trách nhiệm định nghĩa các giao thức, định dạng dữ liệu,
bảo mật và các khía cạnh cần thiết khác để cho phép truyền thông peer-topeer trong trình duyệt [2].
Hình 1 dƣới đây mơ tả kiến trúc tổng thể của WebRTC.Khối màu nhạt hơn gọi là
"chức năng truyền thơng thời gian thực của trình duyệt". Chức năng nàytƣơng tác với
các ứng dụng web sử dụng các API tiêu chuẩn của WebRTC và nó giao tiếp với hệ
điều hành thơng qua trình duyệt.

Máy chủ Web

Máy chủ báo hiệu

HTTP hoặc
WebSocket

HTTP hoặc WebSocket cho báo hiệu

JavaScript/HTML/CSS

Các API khác

Trình duyệt
Web

Các API RTC

Giao thức trên dây (cho truyền
media hoặc dữ liệu)

Chức năng
RTC

Các dịch vụ của hệ điều hành

Hình 1: Kiến trúc tổng thể của WebRTC [3].

Một khía cạnh mới của WebRTC là sự tƣơng tác xảy ra giữa trình duyệt với trình
duyệt, đƣợc biết đến nhƣ một kết nối peer-to-peer, nơi mà chức năng RTC trong một
trình duyệt giao tiếp sử dụng các giao thức tiêu chuẩn trên dây (không phải HTTP) với
chức năng RTC trong một trình duyệt khác. Trong khi truyền thôngtrên web sử dụng

11


giao thức TCP, các giao thức tiêu chuẩn trên dây đƣợc RTC sử dụng giữa các trình

duyệt có thể sử dụng giao thức truyền UDP- User Datagram Protocol.
Một cái mới nữa là máy chủ báo hiệu (signaling server) cung cấp các kênh báo hiệu
giữa các trình duyệt trong kết nối peer-to-peer.
Hình 2 dƣới đây thể hiện kiến trúc bên trong của WebRTC. Chúng ta thấy có hai
tầng riêng biệt trong WebRTC [8]:
1. Các nhà phát triển trình duyệt web (nhƣ Google Chrome hoặc Mozilla Firefox)
sẽ quan tâm đến các WebRTC C ++ API cho kết nối peer-to-peervà các API cho
audio, video và vào/ra mạng theo ý của họ.
2. Các nhà phát triển ứng dụng web sẽ quan tâm đến các web API.
Ứng dụng
Web #n

Ứng dụng
Web #2

Ứng dụng
Web #1

...

WebRTC JavaScript API (Soạn thảo bởi W3C)

WebRTC
WebRTC C++ API (PeerConnection)
Quản lý phiên

Trình duyệt Web
Voice Engine
iSAC / iLBC / Opus
Codec

Giao vận

Video Engine
VP8 Codec

SRTP

Bộ đệm jitter NetEQ

Bộ đệm Video jitter

Dồn kênh

Bộ khử tiếng vọng/giảm
tiếng ồn

Tăng cường ảnh

P2P
STUN + TURN +ICE

Audio Capture/Render

Video Capture

Network I/O

JavaScript API cho các
nhà phát triển ứng dụng

Web

C++ API cho các nhà phát
triển trình duyệt Web

API viết chồng lên được cho các
nhà phát triển trình duyệt Web

Hình 2: Kiến trúc bên trong của WebRTC [8].

Ứng dụng web: là ứng dụng viết trên nền web sử dụng các JavaScript API của
WebRTCcho chức năng truyền thông thời gian thực nhƣ chia sẻ video, audio chat, chia
sẻ file.
WebRTC JavaScript API: là các API đƣợc xây dựng bởi các nhà phát triển trình
duyệt web theo tiêu chuẩn đƣợc quy định bởi tổ chức W3C. Các API này đƣợc các nhà

12


phát triển ứng dụng web sử dụng để viết ra các ứng dụng web có sử dụng chức năng
truyền thơng thời gian thực.
WebRTC C++ API: là một lớp API bên trong của WebRTC đƣợc các nhà phát triển
trình duyệt web sử dụng để dễ dàng thực hiện các WebRTC JavaScript API.
Khối giao vận: đảm nhiệm việc thiết lập kết nối qua các mơ hình mạng khác nhau
sử dụng STUN, TURN và ICE, đồng thời thực hiện việc dồn kênh và thực hiện chức
năng truyền thông thời gian thực.
VideoEngine: là một framework xử lý chuỗi khung hình video, từ máy ảnh vào
mạng, và từ mạng tới màn hình hiển thị.VideoEngine trong WebRTC sử dụng VP8
video codec, đây là một định dạng video mở, chất lƣợng cao và miễn phí cho nền tảng
web đƣợc phát triển từ dự án WebM - VideoEngine

cũng sử dụng bộ đệm jitter động cho video, nó giúp che giấu những ảnh hƣởng của
hiện tƣợng jitter và mất gói tin đến chất lƣợng hình ảnh tổng thể. Ngồi ra Video
Engine cịn có bộ tăng cƣờng ảnh, giúp loại bỏ nhiễu cho các hình ảnh thu đƣợc từ
webcam.
Voice Engine: là một framework xử lý chuỗi âm thanh từ card âm thanh vào mạng.
Nó sử dụng iSAC, iLBC và Opus audio codec và sử dụng bộ đệm jitter động để che
giấu những tác động của hiện tƣợng jitter và việc mất gói tin, trong khi giữ độ trễ thấp
nhất có thể và duy trì chất lƣợng âm thanh cao nhất. Voice Engine cũng sử dụng bộ
khử tiếng vọng và bộ giảm tiếng ồn để nâng cao chất lƣợng đàm thoại.

1.3 Chồng giao thức trong WebRTC
Hình 3 thể hiện các giao thức đƣợc sử dụng trong WebRTC.

13


Tầng ứng dụng

ICE
HTTP

WebSocket

SRTP

SDP

STUN
TURN

Tầng giao vận

TLS

DTLS
TCP

Tầng mạng

UDP

SCTP

IP
Hình 3: Chồng giao thức trong WebRTC [1].

a) Giao thức HTTP
WebRTC sử dụng giao thức HTTP - Hyper-Text Transport Protocol giống nhƣ bất
kỳ ứng dụng web nào, vì vậy khơng cần một kiến thức đặc biệt nào về HTTP. Phiên
bản hiện tại của HTTP là 1.1. IETF đang làm việc để định nghĩa phiên bản tiếp theo
của HTTP, đƣợc gọi là 2.0. Giao thức này sẽ có khả năng tăng tốc độ và hiệu quả tải
web và các ứng dụng. WebRTC sẽ có thể sử dụng giao thức này và bất kỳ phiên bản
khác trong tƣơng lai của HTTP.
b) Giao thức WebSocket
WebSocket là một giao thức cung cấp các kênh truyền thơng song cơng hồn tồn
thơng qua một kết nối TCP duy nhất [11].WebSocket làm cho giao tiếp thời gian thực
hiệu quả hơn vì nó giảm thiểu độ trễ để gửi/nhận thông báo giữa hai phía của kết nối
[12].WebRTC sử dụng WebSocket để trao đổi thơng báo giữa các trình duyệt với nhau
và giữa các trình duyệt với máy chủ web để thiết lập, duy trì và ngắt kết nối.
c) RTP và SRTP

Giao thức quan trọng nhất đƣợc sử dụng bởi WebRTC là RTP - Real-time Transport
Protocol. WebRTC chỉ sử dụng phiên bản an toàn của RTP gọi là SRTP - Secure RTP
[10]. SRTP là giao thức đƣợc sử dụng để vận chuyển và mang các gói tin audio và
video media giữa các WebRTC client. Các gói tin media chứa các audio hoặc các
khung hình video đƣợc số hóa đƣợc tạo ra bởi một microphone hoặc máy ảnh hoặc

14


ứng dụng, và đƣợc dựng lại bởi loa hoặc màn hình hiển thị. Một thiết lập thành cơng
một kết nối peer, cùng với việc hoàn thành trao đổi một cặp offer/answer sẽ dẫn đến
một kết nối SRTP đƣợc thiết lập giữa các trình duyệt hoặc một trình duyệt và một máy
chủ, và trao đổi thông tin media.
SRTP cung cấp thông tin cần thiết để vận chuyển thành công và dựng hình thơng tin
media: các codec (coder/decoder đƣợc sử dụng để lấy mẫu và nén audio hoặc video),
nguồn của các media (nguồn đồng bộ hóa hoặc SSRC), một dấu thời gian, số thứ tự
(để phát hiện mất các gói dữ liệu), và các thông tin khác cần thiết để phát lại. Đối với
dữ liệu không phải là audio hoặc video, SRTP khơng đƣợc sử dụng. Thay vào đó, một
cuộc gọi đến API RTCDataChannel sẽ dẫn đến một kênh dữ liệu đƣợc mở ra giữa các
trình duyệt cho phép bất kỳ định dạng dữ liệu đƣợc trao đổi.
d) SDP
Mô tả phiên WebRTC đƣợc mô tả bằng cách sử dụng SDP - Session Description
Protocol.

Một

mơ

tả

phiên

SDP

(mã

hóa

nhƣ

là

một

đối

tƣợng

RTCSessionDescription) đƣợc sử dụng để mơ tả các đặc điểm media của kết nối peer
[9]. Có một danh sách dài và phức tạp của thông tin cần phải đƣợc trao đổi giữa hai
đầu của phiên SRTP để chúng có thể giao tiếp. Lời gọi API đến RTCPeerConnection
sẽ cho kết quả là một mô tả phiên SDP, một tập định dạng dữ liệu theo cách đặc biệt,
đƣợc tạo ra bởi các trình duyệt và truy cập bằng cách sử dụng JavaScript bởi các ứng
dụng web. Một ứng dụng muốn có kiểm sốt media chặt chẽ hơn có thể thay đổi các
mơ tả phiên trƣớc khi chia sẻ nó với trình duyệt khác. Khi các thay đổi đƣợc thực hiện
cho một kết nối peer, điều này sẽ dẫn đến thay đổi mô tả phiên mà hai bên sẽ trao đổi.
Điều này đƣợc gọi là một trao đổi offer/answer. Bất kỳ nhà phát triển nào có nhu cầu
kiểm sốt các phiên media chi tiết hơn cần phải hiểu về SDP.
Cả SRTP và SDP là hai giao thức đƣợc chuẩn hóa bởi IETF và đƣợc sử dụng rộng
rãi bởi các thiết bị và dịch vụ truyền thông trên Internet, chẳng hạn nhƣ điện thoại

VoIP, cácgateways, hội nghị truyền hình và các thiết bị hợp tác khác. Kết quả là, thông
tin liên lạc giữa một trong những thiết bị và một WebRTC client là có thể đƣợc. Tuy
nhiên, rất ít các thiết bị VoIP hoặc video hiện nay hỗ trợ đầy đủ các khả năng và các
giao thức của WebRTC. Các thiết bị này sẽ cần phải đƣợc nâng cấp để hỗ trợ các giao
thức mới, hoặc một chức năng gatewayđƣợc sử dụng giữa WebRTC client và VoIP
hoặc video client để làm việc chuyển đổi.

15


e) STUN
STUN - Session Traversal Utilities for NAT - là một giao thức đƣợc sử dụng để
giúp đi qua NAT. 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].
f) TURN
TURN - Traversal Using Relays around NAT - là một mở rộng của giao thức
STUN, nó cung cấp một chuyển tiếp media cho các trƣờng hợp mà ICE "hole
punching" thất bại. Trong WebRTC, các user agent trong trình duyệt sẽ bao gồm một
TURN client, và một máy chủ web sẽ cung cấp một máy chủ TURN. Trình duyệt u
cầu một địa chỉ IP cơng cộng và số cổng nhƣ một địa chỉ chuyển tiếp vận chuyển từ
máy chủ TURN. Địa chỉ này sau đó đƣợc bao gồm nhƣ là một địa chỉ ứng cử viên
trong ICE "hole punching". TURN cũng có thể đƣợc sử dụng để đi qua tƣờng lửa [1].
TURN có thể đƣợc sử dụng để thiết lập địa chỉ vận chuyển chuyển tiếp sử dụng
UDP, TCP, hoặc TLS. Tuy nhiên, thông tin liên lạc giữa các máy chủ TURN và
TURN client (thông qua NAT) luôn luôn là UDP.
g) ICE

ICE - Interactive Communication Establishment - là một giao thức đƣợc tiêu chuẩn
hóa bởi IETF (RFC- 5245) [17]. Giao thức ICE đƣợc dùng để thiết lập phiên media
dựa trên UDP đi qua NAT.
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 đƣờngkết nối hiệu
quả nhất. ICE đầu tiên cố gắng để tạo ra một kết nối 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.
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. Nó cũng đƣợc sử dụng để thiết lập các kênh dữ liệu không media.

16


h) TLS
TLS - Transport Layer Security (các phiên bản cũ đƣợc gọi là SSL - Secure Sockets
Layer), là một lớp chèngiữa TCP và các ứng dụng cung cấp các dịch vụ bảo mật và
xác thực. Bảo mật đƣợc cung cấp bằng cách mã hóa các gói tin "trên dây". Xác thực
đƣợc cung cấp bằng cách sử dụng giấy chứng nhận kỹ thuật số. Duyệt web an toàn
ngày nay (HTTPS) chỉ sử dụng vận chuyển TLS. WebRTC có thể tận dụng lợi thế của
TLS cho báo hiệu và bảo mật giao diện ngƣời dùng. Ngồi ra cịn có một phiên bản
của TLS chạy trên UDP, đƣợc gọi là DTLS - Datagram TLS, và một phiên bản có thể
đƣợc sử dụng để tạo ra các khóa cho SRTP đƣợc gọi là DTLS-SRTP [1].
i) TCP
Giao thức TCP - Transmission Control Protocol - là một giao thức lớp vận chuyển
trong chồng giao thức IP, nó cung cấp vận chuyển đáng tin cậy với kiểm soát tắc
nghẽn và kiểm soát luồng. TCP đƣợc sử dụng để vận chuyển trên web (HTTP), nhƣng
không phù hợp để thực hiện truyền thông thời gian thực nhƣ trong RTP, tại vìviệc

truyền tải lại đƣợc sử dụng để đảm bảo độ tin cậy tạo ra sự chậm trễ quá lâu. Giống
nhƣ trong UDP, TCP sử dụng một khái niệm về cổng, một số nguyên 16-bit, để tách
riêng các luồng và các giao thức. TCP đƣợc cung cấp bởi hệ điều hành ở bên dƣới
trình duyệt [1].
j) DTLS
DTLS - Datagram TLS - là một phiên bản của TLS chạy trên UDP, nó cung cấp
tính bảo mật và xác thực tƣơng tự nhƣ trong TLS. UDP đi qua NAT dễ dàng hơn và có
thể phù hợp hơn cho các ứng dụngpeer-to-peer.
k) UDP
UDP - User Datagram Protocol - là một giao thức lớp vận chuyển trong chồng giao
thức IP cung cấp dịch vụ gói tin khơng đáng tin cậy cho các lớp phía trên. UDP thƣờng
đƣợc sử dụng để vận chuyển trao đổi gói tin nhỏ và ngắn (ví dụ các gói tin DNS) hoặc
để vận chuyển media thời gian thực nhƣ là RTP. UDP đƣợc cung cấp để trao đổi thông
tinrất nhanh và hiệu quả; tuy nhiên, ngƣời sử dụng UDP phải đối phó với khả năng
mất gói tin. Ngồi ra, UDP khơng có kiểm sốt tắc nghẽn, vì vậy ngƣời sử dụng phải
nhạy cảm với việc mất gói tin và tắc nghẽn để tránh làm quá tải các kết nối Internet.
Giống nhƣ TCP, UDP sử dụng khái niệm về cổng, một số nguyên 16-bit, để phân tách
các luồng và các giao thức [1].

17


Hầu hết các ứng dụng Internet sử dụng vận chuyển đáng tin cậynhƣ là TCP, trong
đó các gói dữ liệu bị mất sẽ tự động đƣợc truyền lại. Trình duyệt web, email, và dữ
liệu âm thanh và video sử dụng vận chuyển đáng tin cậy. Gói tin nhận đƣợc đƣợc xác
nhận, và việc thiếu một xác nhận sau một thời gian nhất định sẽ kích hoạt việc truyền
lại của các gói tin cho đến khi nó đƣợc xác nhận. Thơng tin liên lạc thời gian thực
không thể tận dụng lợi thế của loại hình vận chuyển đáng tin cậy này do sự chậm trễ
về thời gian cho việc phát hiện mất gói tin và nhận các gói tin truyền lại. Mất gói tin
khi tải một trang web có thể dẫn đến việc đợi thêm một hoặc hai giây để tải đầy đủ.

Một phiên giao tiếp thời gian thực không thể tạm dừng một hoặc hai giây ở giữa một
cuộc trò chuyện bằng giọng nói, hoặc tạm dừng phát lại video một giây trong khi chờ
đợi truyền lại các thông tin cịn thiếu. Thay vào đó, hệ thống thơng tin liên lạc thời
gian thực chỉ cần làm tốt nhất có thể khi thông tin bị mất. Các kỹ thuật để che đậy việc
mất gói tin hoặc giảm thiểu những tác động của nó đƣợc gọi là PLC - Packet Loss
Conceal.
Sự mất mát gói tin trung bình qua Internet là rất thấp. Mặc dù ít khi xảy ra, việc mất
gói tin lại xảy ra đột ngột, dẫn đến mất gói cao hơn trong khoảng thời gian ngắn. Khả
năng xử lý những sự kiện mất mát trong thời gian ngắn có tác động lớn đến chất lƣợng
cảm nhận của một hệ thống thông tin liên lạc. Các codec tiên tiến, đặc biệt là các
codec âm thanh Opus, đƣợc thiết kế để cung cấp một trải nghiệm ngƣời dùng tốt ngay
cả khi mất gói tin cao. Ngồi ra, thơng tin phản hồi thời gian thực từ ngƣời nhận media
cũng cung cấp khả năng làm giảm băng thơng hay độ phân giải trong q trình tắc
nghẽn gói, cung cấp một trải nghiệm ngƣời dùng tốt hơn và chia sẻ băng thông công
bằng với những ngƣời sử dụng Internet khác. UDP đƣợc cung cấp bởi hệ điều hành
phía dƣới trình duyệt.
l) SCTP
SCTP - Stream Control Transport Protocol –là một tiêu chuẩn của IETF (RFC
4960) [16] nằm ở tầng chuyên vận, nó cung cấp vận chuyển đáng tin cậy hoặc không
đáng tin cậy trên IP cùng với việc kiểm sốt tắc nghẽn và nhiều dịng trong một phiên.
Kiểm soát tắc nghẽn là khả năng của một giao thức để cảm nhận đƣợc khi mất gói tin
Internet và sự chậm trễ, và tự động điều chỉnh tốc độ gửi của mình để giảm thiểu
những tác động. Nhiều dịng trong một phiên cho phép một phiên duy nhất đƣợc phân

18


chia thành một số dịng, mỗi dịng trong số đó có thể chia sẻ băng thơng sẵn có trong
phiên một cách công bằng.
SCTP không đƣợc hỗ trợ phổ biến trong các hệ điều hành, do đó các trình duyệt sẽ

có riêng chồng giao thức SCTP của chúng đƣợc xây dựng sẵn cho kênh dữ liệu.
m) IP
IP - Internet Protocol - là giao thức lớp mạng làm nền tảng cho Internet. IP phiên
bản 4, IPv4, phiên bản hiện tại, đang bị hết địa chỉ định danh duy nhất, đƣợc gọi là địa
chỉ IP. IP phiên bản 6, IPv6 đã đƣợc định nghĩa để mở rộng đáng kể không gian địa
chỉ để cho phép Internet tiếp tục đà tăng trƣởng phi thƣờng của nó trong thế kỷ 21.
Thật khơng may, hỗ trợ và triển khai IPv6 vẫn tiếp tục đƣợc tiến hành chậm chạp mặc
dù mạng xƣơng sống Internet và nhiều dịch vụ và các Website hiện đang hỗ trợ nó.
Ngày nay, không phải tất cả các nhà cung cấp dịch vụ Internet (ISP) hỗ trợ IPv6. Đàm
phán media và dữ liệu truyền tải trên các phiên bản khác nhau của IP có thể đƣợc thực
hiện bằng cách sử dụng ICE [1].

1.4 Các API của WebRTC
Các ứng dụng sử dụng WebRTC thƣờng cần làm những việc sau:
 Lấy các dòng audio, video hoặc dữ liệu khác.
 Lấy thông tin về mạng nhƣ địa chỉ IP và cổng, và trao đổi với khách hàng
WebRTC khác (peer) để cho phép kết nối, thậm chí kết nối qua NAT và
tƣờng lửa.
 Phối hợp tín hiệu thông tin liên lạc để báo lỗi và bắt đầu hoặc kết thúc phiên.
 Trao đổi thông tin về media và khả năng của khách hàng, chẳng hạn nhƣ độ
phân giải và codec.
 Giao tiếp thời gian thực với audio, video và dữ liệu.
Để lấy đƣợc và truyền các dòng dữ liệu, WebRTC thực hiện các API sau đây [5]:
 MediaStream: tiếp cận với dòng dữ liệu, chẳng hạn nhƣ từ máy ảnh và
microphonecủa ngƣời dùng [7].
 RTCPeerConnection: thực hiện các cuộc gọi audio hoặc video, với hỗ trợ
cho việc mã hóa và quản lý băng thơng.

19

 RTCDataChannel: truyền dữ liệu bất kỳ thông qua giao tiếp peer-to-peer (gửi
tin nhắn văn bản, gửi file, trò chơi trực tuyến…).

1.5 Kênh báo hiệu trong WebRTC
WebRTC sử dụng RTCPeerConnection API để giao tiếp các dịng dữ liệu giữa các
trình duyệt (các peer), nhƣng nó cũng cần có một cơ chế phối hợp truyền thông và gửi
các thông báo kiểm sốt, q trình này đƣợc gọi là báo hiệu. Phƣơng pháp và giao thức
báo hiệu không đƣợc quy định bởi WebRTC: báo hiệu không phải là một phần của
RTCPeerConnectionAPI.Thay vào đó, các nhà phát triển ứng dụng WebRTC có thể
chọn bất cứ giao thức báo hiệu nào họ thích, chẳng hạn nhƣ SIP hoặc XMPP, và bất kỳ
kênh truyền thông thích hợp nào khác. Ví dụ EasyRTC framework đƣợc xây dựng sử
dụng Socket.io(trong đó sử dụng WebSocket [14]) trên máy chủ Node.js.
Báo hiệu đƣợc sử dụng để trao đổi ba loại thông tin sau [4]:
 Thông báo quản lý phiên: để khởi tạo hoặc kết thúc phiên và báo lỗi.
 Cấu hình mạng: để trao đổi thơng tin cấu hình mạng với bên ngoài (địa chỉ IP
và cổng).
 Khả năng media của thiết bị: những codec gì và các các độ phân giải có thể
đƣợc hỗ trợ bởi trình duyệt.
Việc trao đổi thông tin qua báo hiệu phải kết thúc thành cơng trƣớc khi các dịng dữ
liệu peer-to-peer có thể bắt đầu.

20


Máy chủ báo hiệu
Báo hiệu

Báo hiệu

Ứng dụng

Ứng dụng

Ứng dụng
Mô tả phiên

Mơ tả phiên

WebRTC

Trình duyệt
Web

Media hoặc dữ liệu

Trình duyệt
Web
Người nhận cuộc gọi

Người gọi
Hình 4: Kênh báo hiệu trong WebRTC.

1.6 Bảo mật trong WebRTC
Có một số ngun nhân chính dẫn đến một ứng dụng thơng tin liên lạc thời gian
thực có thể bị lỗi bảo mật:
 Media hoặc dữ liệu không đƣợc mã hóa có thể bị can thiệp trên đƣờng truyền
giữa các trình duyệt.
 Một ứng dụng có thể ghi lại và phân phối video hoặc audio mà ngƣời sử
dụng không biết.

WebRTC có một số tính năng để tránh những vấn đề bảo mật này [6]:
 WebRTC đƣợc triển khai sử dụng giao thức an toàn nhƣ DTLS và SRTP.
 Mã hóa là bắt buộc đối với tất cả các thành phần WebRTC, bao gồm cả cơ
chế truyền báo hiệu.
 WebRTC khơng phải là một plugin: các thành phần của nó chạy bên trong
trình duyệt và khơng phải trong một tiến trình riêng biệt. Các thành phần
WebRTC khơng u cầu cài đặt riêng biệt và đƣợc cập nhật bất cứ khi nào
trình duyệt đƣợc cập nhật.

21


 Việc truy cập máy ảnh và microphone phải đƣợc cho phép một cách rõ ràng,
và khi máy ảnh hoặc microphone đang chạy, nó đƣợc thể hiện rõ bởi giao
diện ngƣời dùng [18].
Trong chƣơng này chúng tơi đã tìm hiểu đƣợc tổng quan về truyền thông thời gian
thực với WebRTC, kiến trúc, chồng giao thức, các API, kênh báo hiệu và mơ hình bảo
mật trong WebRTC. Chƣơng tiếp theo của luận văn, chúng tơi sẽ tìm hiểu về một
framework đƣợc viết trên WebRTC để hỗ trợ các nhà phát triển phần mềm viết các
ứng dụng sử dụng WebRTC.

22


CHƯƠNG 2: GIỚI THIỆU VỀ EASYRTC FRAMEWORK
WebRTC cung cấp các API ở tầm trung cho các nhà phát triển phần mềm, tức là các
nhà phát triển có thể sử dụng các WebRTC API để kết nối với máy ảnh hoặc liên hệ
với các máy chủ TURN và STUN. Tuy nhiên để hoàn thành một phần mềm sử dụng
WebRTC, các nhà phát triển vẫn phải thực hiện việc truyền các gói tin giữa các trình
duyệt để thực hiện kết nối peer-to-peer. Đây vẫn là một cơng việc phức tạp địi hỏi rất

nhiều cơng sức của các nhà lập trình.
Vì vậy, để hỗ trợ phát triển các ứng dụng sử dụng WebRTC, một số nhà cung cấp
đã phát triển các framework dựa trên WebRTC cho phép các nhà phát triển dễ dàng sử
dụng để tạo ra các sản phẩm phần mềm có sử dụng WebRTC một cách dễ dàng và tốn
ít cơng sức hơn.
Một số WebRTC framework chính đƣợc kể đến là:
 EasyRTC - /> SimpleRTC - /> PeerJS - /> CrocodileRTC - />Trong số các WebRTC framework này, chúng tôi chọn sử dụng EasyRTC
framework vì nó hỗ trợ đầy đủ các tính năng cần thiết của một ứng dụng WebRTC, dễ
dàng sử dụng, có tính mềm dẻo, mã nguồn mở và rất phù hợp để xây dựng ứng dụng
web chat mà chúng tơi đang hƣớng tới.
Phần cịn lại của Chƣơng 2 sẽ giới thiệu về EasyRTC framework và cách sử dụng
để xây dựng một ứng dụng WebRTC.

2.1 Giới thiệu về EasyRTC framework
EasyRTC là một framework đƣợc xây dựng trên WebRTC, một tiêu chuẩn đang nổi
lên của W3C/IETF cho truyền thông thời gian thực của audio, video và dữ liệu giữa
các trình duyệt web. WebRTC hỗ trợ truyềnaudio, video và dữ liệu dựa trên cơ sở
peer-to-peer nên địi hỏi rất ít sự hỗ trợ từ phía các máy chủ.
EasyRTC framework bao gồm một thƣ viện JavaScript phía client và một thƣ viện
JavaScript phía máy chủ đƣợc xây dựng dựa trên nền tảng Node.js. Tại vì các thƣ viện
WebRTC đƣợc xây dựng vào trong mỗi trình duyệt nên nó khơng địi hỏi bất kỳ một
plugin nào cho trình duyệt [20].

23