KHOA CÔNG NGHỆ THÔNG TIN VÀ TRUYỀN THÔNG BÁO CÁO ĐỒ ÁN CƠ SỞ 4ĐỀ TÀI: NGHIÊN CỨU KỸ THUẬT VÀ XÂY DỰNG WEBRTC VIDEOCALL

 Báo cáo Đồ Án cơ sở 4

ĐẠI HỌC ĐÀ NẴNG
KHOA CÔNG NGHỆ THÔNG TIN VÀ TRUYỀN THÔNG

----------

BÁO CÁO ĐỒ ÁN CƠ SỞ 4
ĐỀ TÀI: NGHIÊN CỨU KỸ THUẬT VÀ XÂY DỰNG
WEBRTC VIDEOCALL

Giảng viên hướng dẫn : ThS. Nguyễn Anh Tuấn
Sinh viên thực hiện
: Võ Văn Nhã
Nguyễn Mậu Nhật Tường
Lớp
: 17IT3

Đà nẵng, tháng 1 năm 2020

0


 Báo cáo Đồ Án cơ sở 4

LỜI MỞ ĐẦU
1

Dưới sự phát triển không ngừng của ngành công nghệ thông tin và trong xu
thế tiến đến cuộc cách mạng công nghiệp 4.0. Để đáp ứng nhu cầu việc đơn giản
hóa trong việc giao tiếp, một giải pháp hoàn thiện đem đến cho con người lợi ích

về truyền thơng và liên lạc. Công nghệ WebRTC là một công nghệ đang rất phổ
biến hiện nay. Được sự quan tâm giúp đỡ của các thầy cô giáo viên hướng dẫn là
ThS. Nguyễn Anh Tuấn chúng em xin cảm ơn Khoa Công nghệ thông tin nói
chung và xin cảm ơn thầy Tuấn nói riêng đã tạo điều kiện cho chúng em có cơ hội
tìm hiểu cũng như hoàn thành bản tiểu luận, báo cáo về WebRTC.
Trong giới hạn của một tiểu luận báo cáo kết thúc môn học, nội dung của bản
báo cáo sẽ được trình bày theo yêu cầu Đề tài “xây dựng WebRTC video call”
trong danh mục “Danh sách đề tài đồ án cơ sở 5” của Khoa Công Nghệ Thông
Tin và Truyền Thông - Đại học Đà Nẵng, bao gồm:
Chương 1: Mạng ngang hàng(P2P) và các ứng dụng của nó
Chương 2: WebRTC và xây dựng WebRTC video call
Được sự giúp đỡ tận tình của Thầy giáo hướng dẫn, chúng em đã hoàn thành
được những nhiệm vụ cơ bản đề ra. Tuy nhiên, với thời gian và kiến thức có hạn,
bản báo cáo này chắn chắn còn nhiều khiếm khuyết, em rất mong nhận được góp
ý chân thành của Thầy giáo và các bạn.
Em xin chân thành cảm ơn!
Sinh viên thực hiện

Võ Văn Nhã
Nguyễn Mậu Nhật Tường

1


 Báo cáo Đồ Án cơ sở 4

NHẬN XÉT
……………………………………………………………………………………………………………
……………………………………………………………………………………………………………
……………………………………………………………………………………………………………

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

2


 Báo cáo Đồ Án cơ sở 4
ĐẶT VẤN ĐỀ


Cùng với sự bùng nổ công nghệ, người dùng Internet, nhu cầu giao tiếp, chia
sẻ thông tin, trao đổi dữ liệu ngày càng lớn. Về chia sẻ thông tin và dữ liệu, trên
thế giới đã có rất nhiều hình thức với các công nghệ, giao thức, ứng dụng khác
nhau, từ FTP, Email đến các hình thức chia sẻ P2P (Peer-to-Peer) như Bitorrent,
hoặc ứng dụng dịch vụ cloud như Dropbox, OneDrive, Google Drive…
Về giao tiếp thời gian thực thì đã có những ứng dụng messenger rất thành
công và được người dùng chào đón như Skype, Viber, Whatsapp, Line,
Hangouts…Tuy nhiên, vì nhiều lý do từ tốc độ, bảo mật an tồn thơng tin và đặc
biệt là sự tiện dụng, vẫn tiếp tục có các nghiên cứu để đơn giản hóa việc giao tiếp,
chia sẻ dữ liệu, hỗ trợ người dùng một cách nhanh nhất mà khơng địi hỏi phải
thao tác nhiều hay cài đặt thêm các plugin hoặc ứng dụng trên máy. Cụ thể hơn,
mong muốn sử dụng trình duyệt khơng chỉ để lướt web, check mail mà như là một
công cụ hỗ trợ tất cả nhu cầu từ chia sẻ file đến giao tiếp thời gian thực từ lâu đã
được nhen nhóm và thực sự phát triển mạnh từ năm 2009.
Ý tưởng ban đầu từ Google với dự án mã nguồn mở browser-based real-time
communication, gọi là WebRTC, mục đích chính là tạo khả năng giao tiếp thời
gian thực giữa trình duyệt. Đến nay WebRTC được thiết kế để có thể tích hợp với
các hệ thống truyền thông hiện tại như VoIP, các SIP client khác nhau, thậm chí cả
mạng PSTN. WebRTC đang tiếp tục phát triển, được các tổ chức tiêu chuẩn thế
giới bàn thảo để chuẩn hóa các giao thức, các APIs trong trình duyệt để hỗ trợ
WebRTC. WebRTC cũng được những vendor trình duyệt lớn hỗ trợ trong việc
phát triển, đảm bảo trình duyệt có thể kết nối trực tiếp với nhau và thực hiện được
các yêu cầu về thời gian thực trong giao tiếp. Điều này sẽ mở ra một giai đoạn
mới của Web, thực sự mang Web đến với thế giới viễn thông.

3


 Báo cáo Đồ Án cơ sở 4

CHƯƠNG 1
MẠNG NGANG HÀNG (P2P) VÀ CÁC ỨNG DỤNG
1.1. TỔNG QUAN VỀ MẠNG NGANG HÀNG (P2P)
1.1.1. Giới thiệu
- Mạng ngang hàng (P2P) hay còn gọi là Peer-To-Peer bắt đầu xuất hiện từ
năm 1999 và đã thu hút sự quan tâm của giới công nghệ thông tin trong
những năm gần đây. Đặc biệt, việc áp dụng các mơ hình P2P trong việc
xây dựng những ứng dụng chia sẻ file (file sharing), video call, điện thoại
trên nền tảng Internet (Internet-based telephony) dã đạt được nhiều thành
công.
- Hiện nay, các ứng dụng P2P chiếm khoảng 50% (thậm chí 75%) băng
thơng trên Internet.
- Các ứng dụng của kiểu mạng này như là: Napster,Skype, BitTorrent, v.v..
1.1.2. Định nghĩa
- Mạng ngang hàng là một kiểu mạng được thiết kế cho các thiết bị trong đó
có chức năng và khả năng của các thiết bị là như nhau.
- Mạng P2P khơng có khái niệm trạm (client) hay máy chủ (server) mà chỉ
có khái niệm các nốt (peers) đóng vai trị như cả client và server.

Hình abc. Mơ hình mạng ngang hàng (P2P)

4


 Báo cáo Đồ Án cơ sở 4

- Mạng ngang hàng là một hệ thống phân tán đặc biệt trong tầng ứng dụng,
ở đó mỗi cặp điểm nút có thể giao tiếp với nhau thông qua giao thức định
tuyến trong các tầng mạng ngang hàng. Mỗi điểm nút giữ một đối tượng
dữ liệu nào đó có thể là nhạc, ảnh tài liệu, v.v… Mỗi điểm nút có thể truy

vấn tới đối tượng nó cần từ các điểm nút khác thơng qua kết nối logic
trong tầng mạng ngang hàng.
1.1.3. So sánh mơ hình Client-Server và mơ hình Peer-To-Peer:
a. Ưu điểm:
Client-Server
- Tốc độ truy cập nhanh
- Khả năng mở rộng cao.
- Hoạt động với bất kì loại ứng
dụng nào.
- Sử dụng được với các ứng dụng
chia sẻ CSDL.
- Đáng tin cậy (có server riêng).
Mức độ an tồn cao nhất.

-

-

P2P
Khơng cần Server riêng, các nốt
chia sẻ tài nguyên. Khi mạng càng
mở rộng thì khả năng hoạt động
của hệ thống càng tốt.
Rẻ
Dễ cài đặt và bảo trì.
Thuận lợi cho việc chia sẻ file,
máy in, CD_ROM v.v…

b. Nhược điểm:
Client-Server

- Cần Server riêng (nghẽn cổ chai)
- Đắt
- Phức tạp trong việc bảo trì, duy trì
hoạt động của mạng.

P2P
- Chậm
- Không tốt cho các ứng dụng
CSDL.
- Kém tin cậy

1.1.4. Mục đích và ứng dụng của mạng P2P
a. Mục đích:
Mạng ngang hàng hoạt động chủ yếu dựa vào khả năng tính tính tốn và
băng thơng của các máy tham gia chứ không tập trung vào một số nhỏ các
server trung tâm như các mạng thông thường. Tất cả các máy trong mạng
đều tham gia đóng góp tài nguyên, bao gồm băng thơng, lưu trữ và khả
năng tính tốn nên càng nhiều máy tham gia thì khả năng của mạng càng
mạnh.
b. Ứng dụng:
Sự ra đời của mạng ngang hàng đã tạo ra cách thức quản lí mới cho hàng
loạt các lĩnh vực ứng dụng như: giao tiếp (communication), chia sẻ file (flie
sharing), băng thông (bandwidth), vấn đề lưu trữ (storage), các chu trình xử
lí (processor cycles).
5


 Báo cáo Đồ Án cơ sở 4

CHƯƠNG 2

WEBRTC VÀ XÂY DỰNG WEBRTC VIDEO CALL
2.1. TỔNG QUAN
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ên chú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.
WebRTC (Web Real-Time Communications) là một tập hợp các hàm lập
trình dùng cho việc liên lạc thời gian thực bằng video, âm thanh cũng như các
loại dữ liệu khác. WebRTC có thể giúp chúng ta gọi điện video ngay trong trình
duyệt mà khơng cần đăng kí tài khoản, cũng khơng cần cài thêm plugin gì phức
tạp, ngồi ra chúng còn được xài để phát triển game chơi trực tiếp trong trình
duyệt và rất nhiều loại ứng dụng khác. WebRTC là gì? , người ta đang dùng nó
ra sao và những trở ngại nào đang hiện hữu với chuẩn này.
2.2. SƠ LƯỢC LỊCH SỬ CỦA WEBRTC
Ý tưởng phát triển WebRTC được nhóm kỹ sư chịu trách nhiệm cho Google
Hangouts đưa ra từ tận năm 2009. Vào thời gian đó, để truyền tải video, hình
ảnh trên web thì người ta thường phải xài đến Flash. Nhóm kỹ sơ Hangouts lại
khơng muốn sử dụng công nghệ này, và họ bắt đầu tự làm một chuẩn riêng cho
mình. Đến năm 2010, Google thâu tóm hai cơng ty On2 và Global IP Solutions
(GIPS) để lấy công nghệ truyền dữ liệu thời gian thực làm nền tảng cho
WebRTC về sau.
Vào tháng 5/2011, Google ra mắt một dự án nguồn mở dành cho việc giao
tiếp thời gian thực giữa trình duyệt với nhau, và từ lúc này dự án mang tên
WebRTC.
Đến 27/10/2011, W3C ra mắt bản nháp đầu tiên của WebRTC. Tháng

11/2011, Chrome 23 ra mắt, trở thành trình duyệt đầu tiên có tích hợp WebRTC
ngay từ bên trong. WebRTC vẫn còn đang tiếp tục được phát triển chứ chưa
hồn thiện một cách chính thức.

6


 Báo cáo Đồ Án cơ sở 4

2.3. KHÁI NIỆM WEBRTC
WebRTC không chỉ là một sản phẩm hay một hàm API duy nhất. Nó là cả một
tập hợp rất nhiều các hàm có thể được lập trình viên sử dụng cho nhiều mục đích
khác nhau. Có hàm chỉ để làm những việc đơn giản như đòi quyền truy cập vào
webcam và microphone của máy tính, có hàm phức tạp hơn thì để thiết lập kết
nối giữa hai người dùng với nhau, có hàm cịn dùng để chia sẻ màn hình với
người khác. Và rồi có hàm để hai người gọi video cho nhau, cũng là chức năng
"nổi tiếng" nhất của WebRTC tính đến thời điểm hiện tại.
Tuy nhiên, tất cả mọi hàm lập trình nằm trong bộ API có một điểm chung vô
cùng quan trọng: chúng thực thi hầu hết các tác vụ theo thời gian thực. Đó là lý
do vì sao chữ Real-Time xuất hiện trong cái tên của bộ hàm này. Và nó khơng chỉ
được dùng cho việc gọi video giữa hai trình duyệt mà người ta cịn có thể làm
nhiều chuyện khác, miễn là chuyện đó có liên quan đến việc làm cho hai hoặc
nhiều người dùng liên lạc với nhau.
Trên trang web của mình, WebRTC cho biết họ được hỗ trợ chính thức bởi
Google, Mozilla, Opera cùng nhiều đơn vị khác. Mục đích cuối cùng của dự án
này là nhằm "mang lại các ứng dụng phong phú, chất lượng cao và chạy theo thời
gian thực có thể được phát triển bởi lập trình viên cho các trình duyệt, nền tảng di
động, thiết bị Internet of Things, và cho phép tất cả bọn chúng liên lạc với nhau
thông qua một bộ các giao thức chung".
Để sử dụng các hàm lập trình WebRTC, các lập trình viên có thể xài rất nhiều

loại ngơn ngữ lập trình quen thuộc: nếu như viết trang web thì họ được quyền xài
JavaScript, nếu làm app cho Android thì dùng Java, viết cho iOS thì dùng
Objective-C, cịn viết app cho Windows thì dùng C++.
Gọi điện cho nhau bằng trình duyệt Chrome trên Android, khơng cần cài thêm
gì cả. Bên cạnh đó, CU-RTC-Web là một phần mở rộng được Microsoft "cống
hiến" cho WebRTC. Nó viết tắt cho cụm từ Customizable, Ubiquitous Real Time
Communication over the Web. Giải thích thêm về đóng góp của mình, Microsoft
cho biết tính "tùy biến" của nó nằm ở chỗ các ứng dụng có thể phản hồi theo thời
gian thực với chất lượng của đường truyền. Ví dụ, khi tốc độ mạng bị giảm đi,
lập trình viên có thể ra lệnh cho ứng dụng nền web của mình chuyển sang dùng
kênh âm thanh thay cho kênh hình ảnh, thậm chí ngừng hoạt động đến khi tín
hiệu tốt trở lại. Cịn thuộc tính "mọi lúc mọi nơi" (Ubiquitous) có nghĩa là người
dùng sẽ giao tiếp được với bạn bè của mình mặc cho trình duyệt và thiết bị sử
dụng khác nhau. CU-RTC-Web sẽ hoạt động tốt trên cơ sở hạ tầng mạng hiện tại
để đảm bảo tính tương thích cao.

7


 Báo cáo Đồ Án cơ sở 4

2.4. KIẾN TRÚC CỦA WEBRTC
Kiến trúc tổng quan của webRTC như sau:

Hình 2.1 Kiến trúc của WebRTC
Có 2 lớp riêng biệt (distinct layers):


Browser developers sẽ quan tâm đến WebRTC C++ API và các thành phần
cốt lõi sâu hơn của nó như Voice Engine, Video Engine, Transform. Hay dễ

hiểu hơn đó là âm thanh, video và kết nối mạng.



Web App developers sẽ quan tâm tới Web API.

8


 Báo cáo Đồ Án cơ sở 4

2.5. THÀNH PHẦN TRONG CẤU TRÚC WEBRTC
2.5.1. Your web App
 Một ứng dụng phát triển bởi các developer bên thứ 3 với video và audio
chat, xây dựng dựa trên Web API để kết nối thời gian thực.
2.5.2. Web API
 Một API được sử dụng bởi các developer bên thứ 3, để phát triển web video.
2.5.3. WebRTC Native C++ API
 Một tầng API cho phép trình duyệt dễ dàng thực thi Web API.
2.5.4. Transport / Session
 Các session componnent được xây dựng bời việc sử dụng lại các
component từ libjingle, không yêu cầu hoặc sử dụng giao thức xmpp/jingle .
 Transport: cung 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: đóng vai trị điều khiển hoạt động của ứng dụng.
2.5.5. RTP Stack
 Một network stack cho RTP (Real Time Protocol)
2.5.6. STUN/ICE
 Một thành phần cho phép các cuộc gọi sử dụng STUN và ICE để thiết lập
kết nối thông qua các loại mạng khác nhau.

2.5.7. Session Management
 Một lớp session trừu tượng (abstracted session layer) cho phép thiết lập
cuộc gọi và lớp quản lý.
2.5.8. VoiceEngine
 VoiceEngine là một framework cho audio media chain, từ card âm thanh tới
mạng.

9


 Báo cáo Đồ Án cơ sở 4

2.5.9. iSAC / iLBC / Opus
 iSAC: Một băng tần rộng (wideband) và băng tần siêu rộng (super
wideband) audio codec cho VoIP và streaming audio. iSAC sử dụng tần số
16 kHz hoặc 32 kHz ví dụ thương xuyên với một adaptive và biến bitrate
của 12 - 52kbps. Codec là một thiết bị hoặc một chương trình máy tính có
khả năng mã hóa và giải mã một dịng dữ liệu hoặc tín hiệu. Từ "codec" là
từ kết hợp của bất kỳ những cụm từ sau: 'Compressor-Decompressor',
'Coder-Decoder', hoặc 'Compression/Decompression algorithm'. Các codec
mã hóa một dịng dữ liệu hoặc tín hiệu để truyền tải, lưu trữ, hoặc bảo mật
và giải mã nó để xem hoặc sửa đổi. Các codec thường được sử dụng trong
các giải pháp hội nghị truyền hình và streaming media. Một máy quay biến
đổi tín hiệu tuần tự sang tín hiệu số, sau đó sẽ chuyển qua một bộ nén video
để truyền tải tín hiệu số. Một thiết bị nhận sẽ chuyển tín hiệu qua một bộ
giải nén video, sau đó một thiết bị biến đổi từ tín hiệu số sang tín hiệu tuần
tự để thể hiện nội dung. Một bộ giải nén âm thanh sẽ biến đổi tín hiệu âm
thanh tuần tự sang tín hiệu số để truyền tải. Một thiết bị nhận sẽ biến đổ tín
hiệu số trở lại tín hiệu tuần tự thông qua một bộ giải nén âm thanh để phát
lại nội dung.

 iLBC: Một narrowband speech codec cho VoIP và streaming audio. Sử
dụng tần số 8 kHz với một bitrate of 15.2 kbps cho 20ms khung và 13.33
kbps cho 30ms khung. Định nghĩa bởi IETF RFCs 3951 và 3952.
 Opus: hỗ trợ hằng và biến bitrate mã hóa từ 6 kbit/s tới 510 kbit/s, khung
size từ 2.5 ms tới 60 ms. Được định nghĩa bởi IETF RFC 6176. NetEQ cho
Voice.

10


 Báo cáo Đồ Án cơ sở 4

2.5.10. NetEQ
 Một bộ đệm jitter động và thuật toán che giấu lỗi được sử dụng để che giấu
các tác động tiêu cực của jitter mạng và mất gói. Giữ độ trễ càng thấp càng
tốt trong khi vẫn duy trì chất lượng giọng nói cao nhất.
2.5.11. Acoustic Echo Canceler (AEC)
 The Acoustic Echo Canceler là một phần mềm dựa trên các thành phẫn xử
lý tín hiệu đã được xóa. Trong real time, acoustic cho kết quả từ voice được
chạy tới mircrophone đang hoạt động.
2.5.12. Noise Reduction (NR)
 Noise Reduction component là một phần mềm dựa trên các thành phần xử lý
tín hiệu, nhằm loại bỏ các loại tiếng ồn kết hợp với VoIP. (Hiss, fan noise,
etc…).
2.5.13. VideoEngine
 VideoEngine là một framework video media chain cho video, từ camera tới
mạng, và từ mạng tới màn hình.
2.5.14. VP8
 Video codec từ dự án WebM. Nó phù hợp với RTC như một thiết kế cho độ
trễ thấp (low latency)

2.5.15. Video Jitter Buffer
 Jitter Buffer động cho video. Giúp che giấu ảnh hưởng của jitter và packet
bị mất trong tồn bộ chất lượng video.
2.5.16. Image enhancements
 Ví dụ như xóa tiếng ồn video từ ảnh quay bởi webcam

11


 Báo cáo Đồ Án cơ sở 4

2.6. CÁC THÀNH PHẦN KẾT NỐI TRONG WEBRTC

Hình 2.3 Kết nối trong webRTC

1. Firewall: là 1 hệ thống an ninh mạng, có thể dựa trên phần cứng hoặc
phần mềm, sử dụng các quy tắc để kiểm soát traffic vào, ra khỏi hệ thống,
kiểm sốt các truy cập đến nguồn lực của mạng thơng qua một mơ hình
kiểm sốt chủ động. Nó hoạt động như một rào chắn giữa mạng an tồn và
mạng khơng an toàn.
2. NAT (Network Address Translation): thường thay đổi địa chỉ thường là
địa chỉ cục bộ (IP Private) của một kết nối mạng thành địa chỉ công cộng
(IP Public) do các máy trong mạng LAN được đặt IP Private và IP private
khơng tồn tại ngồi Internet.

12


 Báo cáo Đồ Án cơ sở 4

3.
STUN (Simple Traversal Of UDP Through NAT): khi một máy chủ
bất kì xài NAT (behind NAT) thì STUN server sẽ giúp cho client đó biết
được địa chỉ IP và Port mà thiết bị NAT sử dụng. Từ đó, giúp cho các peer
có thể lấy được địa chỉ của peer khác (IP nào, cổng mấy, NAT loại gì).
Port ở đây là các cổng ứng dụng nằm trên Firewall hay router. 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 FRC 5389 (FRC
5389 cung cấp phương tiện cho điểm cuối để xác định địa chỉ IP và cổng
được phân bố bởi NAT tương ứng với địa chỉ IP, có tác dụng kiểm tra kết
nối hoặc chuyển tiếp các gói giữa hai điểm cuối).
- Nhược điểm: nó khơng support Symmetric NAT (NAT có nhiều loại) -

Symmetric NAT sẽ NAT cả port đối với mỗi kết nối đến một địa chỉ đích
khác nhau.
4.
TURN (Traversal Using NAT Relay): giống STUN tuy nhiên
TURN hỗi trợ cả giao thức TCP làm giao thức truyền tải, nó bổ sung cho
nhược điểm của STUN. 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.
- Ưu điểm:
+ Nâng cao chất lượng dịch vụ.
+ Đảm bảo an tồn thơng tin khi truyền dẫn.
- Nhược điểm:
+ Chi phí sử dụng lớn vì sử dụng lưu lượng băng thông lớn. (chất lượng
full HD hay video HD).
5.
ICE (Interactive Communication Establishment): Là một giao
thức đượ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.
- ICE sẽ tìm đường tốt nhất để kết nối giữa các peer, nó thử tất cả khả năng
có thể kết nối một cách song song và lựa chọn con đường hiệu quả nhất.
- Đầu tiên nó sẽ 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 nó sẽ lấy địa
chỉ IP public thông qua STUN server. Nếu vẫn thất bại, lưu lượng được
gửi thông qua TURN server

13


 Báo cáo Đồ Án cơ sở 4

2.7. CÁC API TRONG WEBRTC VÀ GIAO TIẾP P2P
 Do các đặc điểm cần thời gian thực cao hơn tính tin cậy, nên WebRTC sử
dụng các luồng dựa trên UDP.
 getUserMedia: truy cập vào camera và microphone của người dùng
 peerConnection: cung cấp cho người tham gia tạo kết nối trực tiếp với các
peer khác mà khơng cần máy chủ trung gian (ngồi tín hiệu), có cơng dụng
gửi và nhận dữ liệu hình ảnh, giọng nói với khả năng cấu hình của giao thức
SRTP(Secure Real Time Protocol), đối với audio và video. Nó cũng cung cấp
các phương thức để kết nối đến 1 peer từ xa, duy trì và kiểm sốt kết nối &
đóng kết nối một khi ta khơng cần đến nó nữa.
 dataChannels: cho phép chia sẻ dữ liệu trực tiếp giữa các peers với khả năng
cấu hình của giao thức SCTP (Stream Control Transmission Protocol), đối với
non-audio và video.
 Signalling là tên gọi của một phương thức, một protocol giúp cho ta tạo được
liên hệ giữa các peer với nhau. Nó cho phép hai điểm cuối (người gửi, người
nhận hoặc cả hai) trao đổi siêu dữ liệu (metadata), giúp phối hợp liên lạc để
thiết lập cuộc gọi.

 Công dụng của Signalling:
o Session Control Messages: khởi tạo và chấm dứt một kết nối.
o Network Configuration: lấy địa chỉ Public IP và Port.
o Media Capabilities: các loại codecs và resolutions cần thiết.
 WebRTC đã bắt buộc ba codec âm thanh và hai codec video:
o Âm thanh - PCMU (G.711μ), 8.000Hz với một kênh (đơn âm).
o Âm thanh - PCMA (G.711a), 8.000Hz với một kênh (đơn âm).
o Âm thanh - Opus chạy ở 48.000Hz với hai kênh (âm thanh nổi).
o Video - VP8.
o Video - H.264 / AVC sử dụng Cấu hình đường cơ sở ràng buộc.
 Để có thể giao tiếp lẫn nhau thơng qua trình duyệt web, mỗi trình duyệt của
user phải thực hiện những bước sau đây:
1.
2.
3.
4.

Đồng ý để bắt đầu giao tiếp.
Biết cách xác định vị trí của đối tượng.
Vượt qua an ninh và tưởng lửa bảo vệ.
Chuyển giao tất cả các giao tiếp đa phương tiện theo real-time.
14


 Báo cáo Đồ Án cơ sở 4

2.8. SIGNALLING, SESSION, PROTOCOL
 Signalling dựa trên tiêu chuẩn JSEP (Javascript Session Establishment
Protocol - Giao thức thiết lập phiên của Javascript).
 Signalling bao gồm:

o Khám phá mạng (Network discovery)
o NAT Traversal
o Tạo và quản lí phiên
o Bảo mật giao tiếp
o Siêu dữ liệu (metadata) và phối hợp khả năng của media
o Xử lí lỗi
 Để kết nối có thể hoạt động, peer thu được những điều kiện về local media
cho metadata (ví dụ: những khả năng về kích thước và kiểu codec) và gom
góp các địa chỉ mạng có thể có cho host của ứng dụng. Cơ chế signaling dùng
để truyền tới/lui những thông tin quan trọng này không được định nghĩa trong
API của WebRTC.
 Sau khi xác định được địa chỉ IP Public bằng cách sử dụn STUN hoặc TURN
Server, bước tiếp theo sẽ thiết lập một phiên kết nối hoặc phần đàm phán của
các peer.
 Phần đàm phán và thiết lập khởi tạo phiên xảy ra khi dùng 1 giao thức
signaling/giao tiếp được đặc tả trong các giao tiếp đa phương tiện. Giao thức
này cũng chịu trách nhiệm cho việc điều hành các quy định, trong đó có phiên
được quản lý và hủy bỏ.
 Giao thức signaling được chọn phải hoạt động với 1 giao thức ở tầng ứng
dụng gọi là Session Description Protocol (SDP - Giao thức mô tả phiên), giao
thức này được sử dụng trong trường hợp của WebRTC. Tất cả các metadata đa
phương tiện cụ thể được truyền đi bằng giao thức SDP này.
 Bất kỳ peer nào (ví dụ: app tận dụng WebRTC) thử giao tiếp với 1 peer khác
đều sinh ra 1 tập các ứng viên giao thức Interactive Connectivity
Establishment (ICE - Thiết lập kết nối tương tác). Những ứng viên này biểu
diễn 1 bộ kết hợp của địa chỉ IP, port, giao thức giao vận được dùng. Lưu ý
rằng 1 máy tính có thể có nhiều giao diện mạng (khơng dây, có dây, vân vân),
vì thế có thể được gán nhiều địa chỉ IP cho mỗi giao diện.

15

 Báo cáo Đồ Án cơ sở 4

2.9. CÁC ĐỊNH DẠNG GĨI TIN
2.9.1. SESSION DESCRIPTION
 là một chuẩn mơ tả các thông số của mỗi kết nối như là độ phân giải, định
dạng, codecs, mã hóa… Điều này làm cho mỗi peer có thể hiểu nhau khi dữ
liệu được truyền. Đây thực chất là meta-data miêu tả nội dung chứ khơng phải
là dữ liệu media.
 Khi bắt đầu q trình truyền tín hiệu, thơng điệp “offer” được tạo bởi người
bắt đầu cuộc gọi. Thông điệp “offer” bao gồm định dạng SDP (Giao thức mô
tả phiên - là tiêu chuẩn mô tả kết nối ngang hàng. SDP chứa codec , địa chỉ
nguồn và thông tin thời gian của âm thanh và video) và chuyển nó đến người
nhận. Người nhận sẽ trả về “offer” một thông điệp là “answer”, cũng bao gồm
định dạng SDP.
 Trường dữ liệu trong SDP:
1. Type: Loại tin nhắn (“video-offer” hoặc “video-answer”).
2. Name: Tên người dùng của người gửi.
3. Target: Tên người dùng của người nhận mô tả (nếu người gọi đang gửi tin
nhắn, điều này chỉ định callee và ngược lại).
4. SDP: Chuỗi SDP (Giao thức mô tả phiên) mô tả đầu cuối cục bộ của kết
nối theo quan điểm của người gửi (hoặc đầu cuối của kết nối từ quan điểm của
người nhận).
2.9.2. ICE CANDIDATES
 là một chuẩn được sử dụng để thiết lập kết nối giữa các các peer trên internet.
Mặc dù WebRTC là kết nối trực tiếp Peer-to-Peer, nhưng thực tế nó vẫn gặp
phải vấn đề NAT (Network Address Translation) gây khó khăn khi kết nối.
ICE sẽ cố gắng thiết lập kết nối bằng cách tìm đường đi tốt nhất cho việc kết
nối.

 Mơ tả phương thức mà peer gửi đến để có thể sử dụng trong giao tiếp. Mỗi
peer gửi ICE candicates theo thứ tự được phát hiện và tiếp tục gửi cho đến hết
đề xuất, ngay cả khi phương tiện bắt đầu streaming. Mỗi thông điệp ICE
candicates bao gồm các trường sau:
1. Type: Loại tin nhắn (ví dụ: “new-ice-candidate”).
2. Target: Tên người dùng (máy chủ sẽ gửi tin nhắn cho người dùng).
3. Candicate: Chuỗi SDP candicates, mô tả phương thức kết nối được đề
xuất.

16


 Báo cáo Đồ Án cơ sở 4

2.10. CÁC BƯỚC TẠO WEBRTC
I. Kết nối trong WEBRTC:

Hình 2.2 Kết nối trong WebRTC
II. Các bước kết nối trong WebRTC:
1. Sử dụng getUserMedia API để truy cập vào camera và microphone
2. Lấy thông tin network như địa chỉ IP, ports và trao đổi thơng tin đó với các
peer khác (những peer mà mình muốn connect tới) để tạo connection (kết
nối) dù cho có bị ngăn cản bởi NATs hay firewalls.
3. Sau đó thì dùng RTCPeerConnection và RTCDataChannel để voice call/
video call hoặc chia sẻ dữ liệu sau khi đã có kết nối peer-to-peer.

17


 Báo cáo Đồ Án cơ sở 4

2.11. CƠ CHẾ GỌI VIDEO CALL TRONG WEBRTC
2.11.1. CƠ CHẾ GỌI WEBRTC
Mỗi peer đầu tiên phải thiết lập địa chỉ IP public. “Kênh” (channel) dữ liệu
signaling được tự động tạo ra để xác định các peer và hỗ trợ đàm phán peer-topeer và thiết lập phiên (do sự linh động của WebRTC và cũng bởi tiến trình
signaling khơng được cụ thể hóa trong các tiêu chuẩn, một vài giao thức không
cần đến cơ chế “kênh” mà vẫn có thể giao tiếp được).
Một khi 2 hoặc nhiều peer đã cùng kết nối vào 1 “kênh” thì những peer đã
có thể giao tiếp và trao đổi thông tin phiên. Về cơ bản, peer khởi tạo ban đầu sẽ
gửi 1 “lời đề nghị” (offer) sử dụng 1 giao thức signaling chẳng hạn như Session
Initiation Protocol (SIP - Giao thức khởi tạo phiên) và SDP. Người khởi tạo sẽ
chờ để nhận được “câu trả lời” (answer) từ bất kỳ người nhận nào đã kết nối với
“kênh”.
Khi đã nhận được câu trả lời, 1 tiến trình diễn ra để xác định và trao đổi giao
thức ứng viên ICE tốt nhất (Interactive Connectivity Establishment - Thiết lập
kết nối tương tác) mà mỗi peer thu thập được. Một khi chọn được ứng viên ICE
tối ưu thì về cơ bản sẽ có nhiều thứ theo sau đó được chấp nhận, bao gồm:
những metadata cần thiết, các định tuyến mạng (địa chỉ IP và port) và các thông
tin media thường dùng để giao tiếp với mỗi peer. Phiên mạng socket mạng giữa
những peer sau đó được thiết lập hồn chỉnh và kích hoạt.
Tiếp đó, các luồng dữ liệu local và các endpoint kênh dữ liệu được tạo ra bởi
mỗi peer, dữ liệu đa phương tiện cuối cùng được chuyển đi theo cả 2 đường sử
dụng bất kỳ công nghệ giao tiếp 2 chiều nào.
Nếu như tiến trình đồng ý chấp nhận ứng viên ICE tốt nhất bị thất bại, thỉnh
thoảng nguyên nhân là do tường lửa hoặc kỹ thuật NAT đang dùng, thì giải
pháp dự phịng sau đó là sử dụng 1 server TURN dưới dạng 1 điểm chuyển tiếp
thay thế. Tiến trình này về cơ bản sẽ dùng 1 server hoạt động như người trung
gian và nó chuyển tiếp bất kỳ dữ liệu nào truyền qua lại giữa các peer. Lưu ý
rằng đây không phải là giao tiếp peer-to-peer thực thụ trong đó các peer truyền
dữ liệu 2 chiều trực tiếp đến với nhau.

Khi sử dụng giải pháp dự phòng TURN để giao tiếp, mỗi peer sẽ không cần
phải biết làm thế nào để liên lạc và truyền dữ liệu đến bên kia. Thay vào đó, nó
cần biết server TURN public nào để gửi và nhận dữ liệu đa phương tiện theo
thời gian thực xuyên suốt phiên giao tiếp (Các server TURN cần phải khá vững
chắc, có băng thơng rộng, khả năng xử lý và có thể xử lý 1 lượng lớn dữ liệu
tiềm tàng).
18


 Báo cáo Đồ Án cơ sở 4

2.11.2. VÍ DỤ

Hình 2.4 Cơ chế gọi video call trong WebRTC
 Cơ chế gọi video call của WebRTC được mô tả như sau:
1.
2.
3.
4.
5.
6.

Đầu tiên, chúng ta có một signalling server.
A và B biết số IP của nhau.
A khởi tạo mediaStream và gửi message tới Signalling Server.
Signalling Server transfer message đó và gửi đến B.
B nhận được message thì khởi tạo local mediaStream.
B gửi trả về một message cho Signalling Server và server sau khi transfer
nó thì gửi đến A.
7. Sau đó, A khởi tạo đối tượng RTCPeerConnection và tạo một createOffer.

Khi tạo thành công, A sẽ nhận được thông tin trả của
RTCSessionDescription.
8. Trong hàm trả về, A sẽ gọi setLocalDescription và sau đó gửi session này
cho B thông qua Signalling Server, loại session là “OFFER”.
9. B nhận được message, tạo một RTCPeerConnection và gọi hàm
setRemoteDescription với thơng tin của A. Sau đó, gọi createAnswer.
10.Hàm createAnswer trả về thông tin của RTCSessionDescription của B, sau
đó gọi hàm setLocalDescription và gửi message answer cho A.
11.Khi nhận được SessionDescription của B thì A cũng làm tương tự như B,
setRemoteDecription.
12. Hoàn thành thiết lập kết nối Peer-To-Peer.

19


 Báo cáo Đồ Án cơ sở 4

2.12. CÔNG DỤNG CỦA WEBRTC

Một trong những trang web được biết đến khá nhiều trong giới lập trình viên
WebRTC đó là Appear.in ra mắt hồi năm 2012. Dịch vụ này hỗ trợ người dùng
tạo một phịng chat video cực kì nhanh chóng chỉ bằng cách dùng Chrome hoặc
Firefox gốc, không cần phải cài thêm bất kì một plugin nào. Thậm chí người ta
cịn không cần phải đăng nhập hay tạo tài khoản như các app chat video hiện nay.
Và khơng chỉ có Appear.in mới xài WebRTC. Skype for Web, Facebook
Messenger cũng sử dụng bộ hàm này để hoạt động, cịn Citrix thì phát triển các
giải pháp GoToMeeting để người dùng cũng như các doanh nghiệp có thể ứng
dụng việc gọi video vào cơng việc hằng ngày của mình một cách dễ dàng hơn.
WebRTC cũng được xài để tạo ra các game nhiều người chơi mà khơng cần
cài gì thêm, người ta chỉ cần xài trình duyệt có hỗ trợ WebRTC là đủ. Hầu hết

những trị đó đều chỉ là các tựa game giải trí nhẹ nhàng thơi, nhưng cũng có vài
cái tên nổi bật như The Hobbit: The Battle for Five Armies ra mắt cuối năm
ngoái.
Bằng cách dùng WebRTC kết hợp với một bộ hàm nữa là WebGL chuyên
dùng xử lý đồ họa, nhà phát triển game The Hobbit nói trên có thể tạo ra một
không gian thời trung cổ để người chơi đánh nhau với những người khác, không
thua kém mấy so với những game online hạng nhẹ hiện tại.
Nói tóm lại, WebRTC có thể được sử dụng cho nhiều mục đích, từ việc truyền
tải video, âm thanh cho đến gửi dữ liệu theo thời gian thực giữa hai hoặc nhiều
thiết bị với nhau mà không nhất thiết phải đi qua server trung gian. Điều này giúp
giảm độ trễ trong việc truyền tải, giảm độ phức tạp khi phát triển ứng dụng cũng
như giảm chi phí vận hành (vì khơng phải trả tiền thuê server, tiền điện, tiền bảo
dưỡng...), kéo theo đó giá bán dịch vụ nếu có thì cũng sẽ thấp hơn.

20


 Báo cáo Đồ Án cơ sở 4

2.13. SỰ HỖ TRỢ TỪ TRÌNH DUYỆT
Chrome và Firefox là hai trình duyệt hỗ trợ mạnh nhất cho WebRTC, khơng
có gì lạ khi mà WebRTC được ủng hộ rất mạnh mẽ bởi Google và Mozilla.
Opera cũng cho phép chạy hầu hết các tính năng quan trọng nhưng bạn sẽ không
thể chia sẻ màn hình cho người khác được. Đứng cuối bảng có lẽ là IE và Safari
với việc hỗ trợ cho WebRTC rất kém. Nhưng nói tóm lại thì bộ hàm này vẫn
chưa được hỗ trợ một cách đầy đủ từ các hãng trình duyệt, bởi ngay cả Chrome
từ Google cũng khơng thể tương thích 100% các hàm API có trong WebRTC.
Nhưng hãng khơng hỗ trợ khơng có nghĩa là chúng ta hồn tồn khơng thể
xài được WebRTC. Vẫn có những plugin cài thêm từ bên ngồi vào để giúp trình
duyệt tương thích tốt hơn, nhưng lúc đó thì sự thuận lợi sẽ khơng cịn nữa. Điểm

tuyệt vời của WebRTC là phải được hỗ trợ sẵn từ trong trình duyệt để người ta
khơng cần cài thêm plugin gì cơ mà.
Tóm lại, những trình duyệt lớn sau là có hỗ trợ WebRTC. Phiên bản ghi
trong bài là phiên bản đầu tiên được triển khai WebRTC, cịn hiện tại thì chúng
đã được update lên mới hơn.
 PC







o Google Chrome 23
o Mozilla Firefox 22
o Opera 18
Android
o Google Chrome 28 (Enabled by default since 29)
o Mozilla Firefox 24
o Opera Mobile 12
Chrome OS
Firefox OS
Ios
o Bowser

21


 Báo cáo Đồ Án cơ sở 4

2.14. SỰ AN TOÀN CỦA WEBRTC
WebRTC được xem như một bước tiếp nối cho Adobe Flash, vốn cũng từng
được xài để giao tiếp theo thời gian thực trên trình duyệt. Flash thì đã quá nổi
tiếng vì các lỗ hổng bảo mật của mình khiến người dùng dễ bị tấn công bởi
hacker hay malware. Đây cũng là một trong những lý do mà Steve Jobs đã từng
nhắc đến khi kể về quyết định không mang Flash lên iPhone.
May mắn là WebRTC ít bị những vấn đề như thế, bởi vì nó khơng phải là một
phần mềm cài thêm từ bên ngoài. Flash là một plugin, nhưng WebRTC thì khơng.
Nó là một tập hợp các hàm API được lập trình viên sử dụng mà thơi nên sẽ khó bị
khai thác hơn là Flash.
Nhưng nói như vậy khơng có nghĩa là WebRTC sẽ khơng gặp vấn đề về bảo
mật. Hồi cuối năm ngoái người ta phát hiện ra rằng họ có thể tìm thấy địa chỉ IP
thực của một người dùng VPN chỉ bằng cách tận dụng vài đoạn mã JavaScript có
xài hàm API WebRTC. Người ta xài VPN thường là với mục đích khơng để lộ IP
thực cơ mà. Hiện vẫn chưa có cập nhật mới hơn gì về vụ việc này, ngồi trừ lời
khun tắt WebRTC đi.

22


 Báo cáo Đồ Án cơ sở 4

2.15. TRỞ NGẠI CỦA WEBRTC
Như đã nói ở trên, hiện tại WebRTC chỉ mới được phát triển ở giai đoạn nháp
chứ chưa được hồn tất nên việc hỗ trợ cho lập trình viên khi cần giúp đỡ cũng
cịn nhiều khó khăn, trong khi tài liệu thì chưa có một cách đầy đủ.
Ngồi ra, các hãng trình duyệt cũng chưa thống nhất với nhau là chuẩn video
nào sẽ được dùng cho WebRTC. Google và Mozilla thì muốn xài VP8 hoặc VP9,
một codec video do chính Google phát triển theo mơ hình mã nguồn mở và ai
cũng có thể xài được mà khơng phải đồng nào. Trong khi đó, Microsoft và một số

cơng ty khác thì muốn đề xuất xài H.264 hoặc H.265 cho WebRTC, vốn đang là
codec được xài phổ biến nhất hiện nay trên thế giới Internet. Tuy nhiên, H.264 lại
thuộc quyền sở hữu của hiệp hội MPEG LA và phải trả phí bản quyền để sử
dụng.
Thực chất thì nhóm chịu trách nhiệm xây dựng WebRTC muốn xài VP8 hoặc
VP9 hơn so với H.26x bởi họ muốn né các vấn đề về bản quyền. Tuy nhiên, để có
được hiệu quả và chất lượng giao tiếp theo thời gian thực tốt nhất thì thiết bị, nhất
là thiết bị di động, sẽ phải cần đến tăng tốc phần cứng. Tính đến thời điểm hiện
tại thì chỉ có H.264 là được hỗ trợ tăng tốc phần cứng một cách rộng rãi mà thôi.
Vấn đề cuối cùng đó là sự khác biệt về số lượng hàm API WebRTC được hỗ
trợ trong các trình duyệt rất khác nhau. Vấn đề này thì mình đã nói cho các bạn
nghe ở trên rồi. Điều này làm giảm đi khả năng hoạt động của các ứng dụng
WebRTC, thế nên lập trình viên sẽ phải dành nhiều công sức hơn để tinh chỉnh lại
trang web hoặc app của mình cho phù hợp với từng trình duyệt, phần nào giảm đi
lợi ích cốt lõi của WebRTC, chưa kể đến rủi ro phát sinh lỗi cao hơn.

23


 Báo cáo Đồ Án cơ sở 4

CHƯƠNG 3XÂY DỰNG TRANG WEB VÀ DEMO
3.1. MỘT SỐ TRANG TRONG WEB
a. Trang index.html:
i.
Giới thiệu trang web.
ii.Khởi tạo phòng với một mã id, mã id này do người dùng tự đặt hoặc
random.
b. Trang call.html:
i.

Chạy camera.
ii.
Kết nối peer to peer.
iii.
Chức năng coppy đường link trang web.
iv.
Thực hiện gọi thoại.
3.2. MỘT SỐ HÀM VÀ CÁC CHỨC NĂNG TRONG WEBRTC
a. Hàm startWebRTC:
i.
ii.
iii.
iv.
v.
vi.

Hiển thị video của người dùng.
Bắt đầu gọi webRTC
Gửi message đến các peer khác
Nếu là người dùng đầu tiên kết nối thì sẽ tạo createOffer
Nhận message “offer” từ peer khác và tạo createAnswer
Hiển thị video stream của người nhận.

b. Hàm chuyển địa chỉ theo mã id: Ramdom mã hoặc được đặt bởi người dùng
c. Nút coppy:
i.
ii.

Hiển thị đường link của page với một mã id phịng được tạo.
Coppy và hiển thị alert coppy thành cơng.

24