Voip

Chuyên Đề: VoIP
(Voice over Internet Protocol)
Giảng viên: Phan Thanh Hiền
Tài Liệu Tham khảo:
Kỹ thuật điện thoại qua IP và Internet (Nguyễn Hồng Sơn)
Điện thoại IP (Tổng công ty Bưu chính viễn thông VN).
Kỹ thuật truyền số liệu (Nguyễn Hồng Sơn)
Mạng máy tính và hệ thông mở (Nguyễn Thúc Hải)
TCP/IP (Transmision Control Protocol/Internet Protocol)
.
Yêu cầu môn học
CÇn cã kiÕn thøc tèt vÒ c¸c m«n häc: Kü thuËt truyÒn dÉn, Kü thuËt chuyÓn m¹ch vµ tæng ®µi, C¬ së th«ng tin sè.
KÕt thóc m«n häc: Sinh viªn ph¶i tham dù ®Çy ®ñ c¸c buæi lªn líp (theo ®óng qui chÕ), c¸c bµi kiÓm tra.
KiÓm tra cuèi kú: Thi viÕt
(C¸c b¹n cã thÓ ®¨ng ký lµm chuyªn ®Ò tuú chän. NÕu b¶o vÖ tèt sÏ ®­îc céng ®iÓm)
Nội Dung Chương Trình
(Số tiết lý thuyết: 45)
Chương 1: Tổng quan về VoIP
Khái Niệm VoIP
Đặc điểm của VoIP
Mô hình dịch vụ VoIP
Chương 2: Giao Thức TCP/IP và Giải pháp xử lý tín hiệu thời gian thực trong mạng gói
Giao thức TCP/IP
Giải pháp xử lý tín hiệu thực trong mạng gói
Chương 3: Báo hiệu cuộc gọi trong mạng IP
Giới thiệu chuẩn H.323
Các thành phần trong hệ thống H.323
Các thủ tục báo hiệu cuộc gọi
Nội Dung Chương Trình (tiếp)
Chương 4: Chất lượng dịch vụ trong VoIP
Các yếu tố ảnh hưởng đến QoS
Các cơ chế điều khiển chất lượng dịch vụ trong mỗi phần tử mạng.
Chương 5: Triển khai dịch vụ VoIP trên mạng Internet Việt Nam
Chương 1: Tổng quan về VoIP
Khái niệm:
VoIP (Voice over Internet Protocol) là dịch vụ chuyền thoại sự dụng công nghệ mạng IP.
Dữ liệu và báo hiệu được truyền đi dưới dạng các gói IP trên mạng IP
Công nghệ VoIP lần đầu tiên được đưa vào mạng công cộng vào năm 1998 và đến đầu năm 1999 và 2000 nó đã trở nên phổ biến trên mạng công cộng và mạng cơ quan trên khắp thế giới.

Các trường hợp kết nối
đầu cuối - đầu cuối
Cuộc gọi PSTN
64 kb/s
Báo hiệu C7
Tín hiệu thoại được truyền đi trên kênh vật lý được thiết lập dành riêng cho cuộc nối ở dạng dòng bit liên tục
Tổng đài
Tổng đài
Điên thoại
Điên thoại
PSTN (Public Switched Telephone Network):
Mạng chuyển mạch kênh
Một kênh truyền dẫn "dành riêng" được thiết lập giữa 2 thiết bị đầu cuối thông qua một hoặc nhiều nút chuyển mạch trung gian.
Dòng thông tin là dòng liên tục
Băng thông của kênh được đảm bảo, cố định 64kbs
Độ trễ thông tin là rất nhỏ (cỡ thời gian truyền thông tin)
Cấu hình mạng PSTN
Mạng chuyển mạch gói - Internet
(Packet Switching Network)
Sử dụng hệ thống lưu trữ rồi chuyền (Store and forward system) tại các nút mạng.
Thông tin được chia thành các gói, mỗi gói được thêm gắn thêm các thông tin điều khiển cần thiết cho quá trình truyền (địa chỉ nơi gửi/nhận,.)
Tại các nút mạng các gói tin được xử lý và truyền đến các nút tiếp theo (thông qua các thuật toán tìm đường)
Không có một kênh "dành riêng" nào được thiết lập, băng thông giữa hai thiết bị đầu cuối không cố định.
Độ trễ thông tin là rất lớn (so với chuyển mạch kênh).
Cuộc gọi VoIP
64 kb/s
64 kb/s
8 kb/s
H.323
Tín hiệu thoại được truyền đi trên ảo dưới dạng các gói dữ liệu (IP) chứ không phải dòng bit liên tục
Tổng đài
Điên thoại
Tổng đài
Điên thoại
Gateway
Gateway
Mô hình chuyển mạch khênh - chuyển mạch gói
Tại sao sử dụng VoIP ?
Giá thành cuộc gọi trong mạng PSTN tương đối lớn:
Chuyển mạch kênh dẫn đến lãng phí tài nguyên, theo đánh giá của giới chuyên môn thì 70-80% dung lượng truyền dẫn thường rảnh rỗi
Đầu tư cho mạng PSTN lớn, giá thiết bị cao, chi phí vận hành mạng lớn, không linh hoạt trong việc mở rộng hệ thống.
Một cuộc gọi thoại yêu cầu trung kế 64 kb/s, bất kể có đàm thoại thật sự hay không và đường truyền bị chiếm trong suốt thời gian diễm ra cuộc gọi
Khó khăn trong việc tổ hợp với các dịch vụ khác
Tại sao sử dụng VoIP ?
Cuộc gọi thoại qua IP có giá thành thấp:
Cho phép sử dụng hiệu quả đường truyền, do có thể dùng chung cho các dịch vụ cả thoại và dữ liệu. Quản lý dải thông hiệu quả
Trung kế ảo thực tế chỉ xấp xỉ 8 kb/s (G.723.1: 5,3 hoặc 6,3kb/s). RTP cho phép triệt khoảng lặng trong khi đàm thoại (40%).
Giá thành thiết bị mạng IP thấp, chi phí vận hành mạng thấp
Dễ dàng triển khai các dịch vụ thông minh, dịch vụ giá trị gia tăng. VoIP là giải pháp tuyệt vời để cung cấp các dịch vụ thông minh.
Tại sao sử dụng VoIP?
Đối với doanh nghiệp có nhiều trụ sở nằm rải rác nhiều nơi, kể cả ở nước ngoài, VoIP là giải pháp rất kinh tế:
Tiết kiệm chi phí thoại đường dài, thoại quốc tế
Sử dụng một đường truyền dẫn cho tất cả các dịch vụ: thoại, fax (FoIP), bản tin thống nhất, thư điện tử, truyền dữ liệu...
Đối với người hay di chuyển nơi làm việc thì VoIP rất tốt vì việc khai báo di chuyển máy điện thoại dễ dàng
Khi nào cần triển khai VoIP?
Đối với nhà cung cấp dịch vụ:
Khi mạng điện thoại đường dài đã có dấu hiệu tắc nghẽn
Khi cần triển khai dịch vụ điện thoại đường dài trên tuyến mới
Khi cần cung cấp một số dịch vụ thông minh
Khi có chính sách
VoIP và Thoại Internet
VoIP là thoại dựa trên giao thức IP, do đó có thể thực hiện trong mạng LAN, WAN hay mạng IP công cộng, chứ không nhất thiết phải là mạng Internet
Điện thoại Internet là cũng là thoại qua giao thức IP, nhưng cuộc gọi được thực hiện trong mạng Internet, thí dụ như cuộc gọi giữa máy trạm và máy điện thoại thường
Đối với dịch vụ VoIP người ta dành riêng các đường truyền, do vậy chất lượng dịch vụ tốt hơn. Chất lượng thoại Internet không kiểm soát được
Ưu điểm của VoIP
Giảm chi phí cuộc gọi (các cuội gọi đường dài liên tỉnh và quốc tế).
Tích hợp mạng thoại, mạng số liệu và mạng báo hiệu
Khả năng mở rộng
Không cần thông tin điều khiển để thiết lập các kênh truyền vật lý
Quản lý băng thông tốt
Nhiều tính năng dịch vụ mới
Khẳ năng multimedia

Các loại dịch vụ thoại VoIP
EP to EP: tức là từ điểm cuối nọ đến điểm cuối kia trong mạng IP sử dụng các phần mềm như NetMeeting...
EP to phone: Cuộc gọi từ điểm cuối trong mạng IP tới máy điện thoại thông thường ở mạng bên ngoài qua Gateway
Phone to phone: Cuộc gọi từ hai máy điện thoại thông thường qua mạng IP.
What Is VoIP?
Câu hình mạng VoIP qui mô nhà cung cấp dịch vụ
Trong đó:
Media Gateway:
Chuyển đổi khuân dạng thồng tin (PSTN - IP)
Thực hiện quá trình xử tín hiệu thoại (Nén tin hiẹu thoại, nén khoảng lặng, triệt tiếng vọng)
Cung cấp các giao diện vật lý cần thiết cho kết nối.
Signlling Gateway: Báo hiệu giữa các đầu cuối trong mạng chuyển mạch kênh và các đầu cuối trong mạng IP
Call Control Centrer:
Hướng dẫn Media Gateway các thiết lập, xử lý và kết thúc dòng thông tin media phục vụ cuộc gọi
Xử lý thông tin báo hiệu
Theo dõi trạng thái của tất cả các dòng media đang truyền trong hệ thống.
Thực hiện nhiều dịch vụ của hệ thống: tính cước, .
Các thành phần khác: Bao gồm các terminal, .
Mô Hình VoIP giải pháp cho các doanh nghiệp
Chương 2:
Giao thức TCP/IP -
Giải pháp xử lý tín hiệu thời gian thực trong mạng gói
Bộ giao thức TCP/IP
Lịch sử phát triển
Giao vận
Mạng
ứng dụng
Giao diện mạng
Chồng giao thức TCP/IP
TCP/IP và mô hình OSI
Ví dụ như việc trao đổi hàng giữa 2 kho
Các tầng của bộ giao thức TCP/IP
Quá trình truyền dữ liệu End to End
 

 

Lớp ứng dụng
Lớp ứng dụng
Lớp ứng dụng (tiếp)
Một ứng dụng có thể sử dụng nhiều giao thức tầng
ứng dụng
Chuyển các gói dữ liệu nhận được từ tầng mạng (IP) tới đúng ứng dụng
Cung cấp các kiểu truyền thông khác nhau cho các ứng dụng (kết nối hay phi kết nối)
Lớp giao vận
Cổng (port)
Phân bố dữ liệu dựa trên cổng
Dã y cổng
0 1023 1024 49,151 49152 65535
Cố định
Đăng ký Phân bổ ngẫu nhiên
Dã y cổng
Cố định
Đăng ký Phân bổ ngẫu nhiên
Socket
Hỗ trợ nhiều ứng dụng
Một giao thức tầng giao vận có thể hỗ trợ truyền
thông cho nhiều ứng dụng cùng lúc
Các giao thức lớp giao vận
Các kiểu truyền thông
Truyền thông có kết nối
Đảm bảo tin cậy
Truyền thông không kết nối
Lựa chọn kiểu truyền thông
TCP - Transmission Control Protocol
Đặc điểm của TCP
Hướng kết nối
Tin cậy
- Sử dụng cơ chế báo nhận
Hoàn toàn song công
- Dữ liệu được gửi 2 chiều cũng lúc
Stream data
- Bên gửi: Nhận luồng ký tự từ chương trình ứng dụng gửi, tạo
các gói (segment) và gửi chúng qua mạng
- Bên nhận: Nhận các segment, sắp xếp lại thứ tự, trích phần
data và gửi dữ liệu dưới dạng luồng ký tự tới ứng dụng
Cấu trúc TCP header
Port number
Port number
Các cổng TCP điển hình
Port number
Data
Source Port Number
Destination Port Number
Acknowledge Number
Header
Length
Reserved
Flags
Window
Checksum
Urgent Pointer
Option
Sequence Number
Xác định vị trí của dữ liệu được gửi bởi trạm nguồn
? Số hiệu của byte đầu tiên của phần dữ liệu
Sequence number
Acknowlegde Number / Window
Flags - URG
Flags - ACK
Flags - PSH/RST
Flags - SYN/FIN
Header length
urgent pointer / checksum
Options
Các loại Option
Options
Single-byte
Multiple-byte
End of option
No Operation
Maximum segment size
Window Scale factor
Timestamp
Tóm tắt các trường trong TCP header
Điều khiển luồng (Flow control)
Định nghĩa lượng dữ liệu nguồn có thể gửi trước khi nhận một báo nhận từ đích
Gửi tất dữ liệu ? trạm đích không xử lý kịp
TCP định nghĩa một cửa sổ và dữ liệu chỉ được gửi theo kích thước của sổ
Không thể xử lý
Gửi !! Gửi !!
Gửi cho tôi 100kg
OK
Dò tìm và sửa lỗi
TCP sử dụng 3 công cụ phát hiện lỗi
- Checksum
- Acknowlegment
Sửa lỗi
- Truyền lại
Thiết lập kết nối TCP
Tôi đã nhận dữ liệu có sequence number 200. OK. Hãy tạo kết nối. Tôi bắt đầu từ sequence number 100. Tôi gửi trả lời kết nối.
Kết nối đã được thiết lập thành công. Chúng ta có thể trao đổi thông tin.
Tôi có dữ liệu để gửi. Hãy thiết lập kết nối. Tôi bắt đầu từ sequence number 200.
Tôi đã nhận được dự liệu có sequence number 100. Kết nối đã được thiết lập thành công. Chúng ta có thể trao đổi thông tin.
SEQ=200
SEQ=201
SEQ=100
SEQ=200
SEQ=100 ACK=201
SEQ=201 ACK=101
Host A
Host B
Connection
request
Connection
response
Confirmation
response
Connection establishment
3-way handshake
Host A
Host B
Connection
request
Connection
response
Confirmation
response
Connection establishment
SYN
ACK,SYN
ACK
Three-way handshake
Kết thúc kênh truyền

Không còn dữ liệu để gửi. Tôi đóng
kết nối
Không còn dữ liệu
Ok. Tôi sẽ đóng kết nối.
Flag
ACK=1
Fin=1
Tôi đã nhận dữ liệu thành công
Flag
ACK=1
SEQ=601;ACK=201
Flag
ACK=1
SEQ=602;ACK=301
Tôi vẫn tiếp tục gửi 100 byte.
SEQ=201;ACK=602
Flag
ACK=1
SEQ=201;ACK=602

DATA;100oct
Flag
ACK=1
Fin=1
SEQ=301;ACK=602
Flag
ACK=1
SEQ=602;ACK=302
Host A
Host B
OK. Tôi đã biết
Bốn bước giải toả cuộc nối
Host A
Host B
Disconnection
request
Disconnection
response
Confirmation
response
Disconnection
ACK, FIN
ACK
ACK
ACK, FIN
Các cổng UDP điển hình
Cấu trúc UDP header
TCP header
0
4
10
16
31
UDP header
Source port number: Số cổng nguồn
Destination port number: Số cổng đích
Message length: Chiều dài bản tin UDP (đơn vị 4 byte)
Checksum: Mã CRC
Virtual circuits
IP broadcast
TCP
UDP
Simultaneous communication
Truyền thông với nhiều host
Mô hình TCP/IP
Liên mạng
Tầng liên mạng
IP - Internet Protocol
Chuyển gói không kết nối (các gói được xử lý
riêng lẻ)
Không tin cậy (không xác nhận và gửi lại).
Fragmentation / Reassembly
Định tuyến
Kiểm tra lỗi
Cấu trúc IP header
VERS
HL
Fragmentation
Total IP Length
Prc
Datagram ID
TTL
Protocol
Header Checksum
Source Address
Destination Address
Options (if any)
Data
1 byte
1 byte
1 byte
1 byte
TOS
IP Version Number (4 bit)
VERS = 4 (IPv4)
6 (IPv6)
VERS
HL
Fragmentation
Total IP Length
Prc
Datagram ID
TTL
Protocol
Header Checksum
Source Address
Destination Address
Options (if any)
Data
1 byte
1 byte
1 byte
1 byte
TOS
IP header length (4 bit)
HL = 5 (20 byte là chuẩn)
HL > 5 (có thêm phần options)
VERS
HL
Fragmentation
Total IP Length
Prc
Datagram ID
TTL
Protocol
Header Checksum
Source Address
Destination Address
Options (if any)
Data
1 byte
1 byte
1 byte
1 byte
TOS
Type of service (5 bit)
Precedence Type of service
0 0 0 X C R T D
X - Dự phòng
C (Cost) - chọn kênh có giá nhỏ
R (Reliability) - Chọn kênh có độ tin cậy cao
T (Throughput) - Chọn kênh có thông lượng cao
D (Delay) - Chọn kênh có độ trễ thấp
Chú ý: Chỉ có thể dùng 1 dịch vụ tại một thời điểm
Các loại dịch vụ mặc định
Giao thức
TOS
ý nghĩa
ICMP
0000
Bình thường
BOOTP
0000
Bình thường
IGP
0010
Độ tin cậy tối đa
SNMP
0010
Độ tin cậy tối đa
TELNET
1000
Độ trễ tối thiểu
FTP
0100
Thông lượng cao nhất
SMTP (command)
1000
Độ trễ tối thiểu
SMTP (data)
0100
Thông lượng tối đa
DNS (UDP query)
1000
Độ trễ tối thiểu
DNS (TCP query)
0000
Bình thường
VERS
HL
Fragmentation
Total IP Length
Prc
Datagram ID
TTL
Protocol
Header Checksum
Source Address
Destination Address
Options (if any)
Data
1 byte
1 byte
1 byte
1 byte
TOS
Total IP length và datagram ID
Datagram ID: 0-65535
Total IP length: Số byte của datagram ? 20
Fragmentation
Fragmentation Offset
0 0 1 0 0 1 0 1 0 0 1 1 0 0 1 1
X DF S
X - Dự phòng
DF (Don`t Fragment) = 0 (có thể phân đoạn)
= 1 (không phân đoạn)
S (fragment Status) = 0 (Phân đoạn cuối cùng)
= 1 (Còn phân đoạn)
Fragmentation Offset - Vị trí của phân đoạn
Send
/Receive packet
Send
/Receive packet
Send
/Receive packet
Giao diện mạng
IP packet (1)
IP packet (2)
IP packet (3)
Liên mạng
TCP Packet (Datagram)
(Fragment/reassemble)
Giao vận
Fragmentation và Reassembly
MTU - Maximum Transfer Unit
MTU của các mạng khác nhau
Ví dụ về phân đoạn (1)
Byte 0000
Byte 3,999
offset = 0000/8=0
Byte 0000
Byte 1,399
Byte 1,400
Byte 2,799
Byte 2,800
Byte 3,999
offset = 0000/8=0
offset = 1400/8=175
offset = 2800/8=350
4,000
000
14,567
0
Byte 0000 - 3,999
1,400
000
14,567
1
Byte 0000 - 1,399
1,400
175
14,567
1
Byte 1,400 - 2,799
1,200
350
14,567
0
Byte 2,800 - 3,999
800
175
14,567
1
Byte 1,400 - 2,199
600
275
14,567
1
Byte 2,200 - 2,799
Datagram nguồn
Phân đoạn 1
Phân đoạn 2
Phân đoạn 3
Phân đoạn 2.1
Phân đoạn 2.2
Ví dụ về phân đoạn (2)
Time to live & Header checksum
VERS
HL
Fragmentation
Total IP Length
Prc
Datagram ID
TTL
Protocol
Header Checksum
Source Address
Destination Address
Options (if any)
Data
1 byte
1 byte
1 byte
1 byte
TOS
Header checksum: Kiểm soát lỗi cho phần header
Time to live: Số giây datagram trên liên mạng
Protocol (16 bit)
Giao thức tầng trên
Protocol Number Description
ICMP 1 Internet Control Message Protocol
TCP 6 Transmission Control Protocol
BGP 8 Border Gateway Protocol
UDP 17 User Datagram Protocol
0SPF 89 Open Shortest Path First
VERS
HL
Fragmentation
Total IP Length
Prc
Datagram ID
TTL
Protocol
Header Checksum
Source Address
Destination Address
Options (if any)
Data
1 byte
1 byte
1 byte
1 byte
TOS
Address
Cấu trúc địa chỉ IP
NetID
HostID
Class
type
32 bít
NetID - Xác định mạng trong liên mạng
HostID - Xác định trạm trong mạng
Class type - Xác định loại địa chỉ
Ký pháp thập phân dấu chấm
10000000 00001011 00000011 00011111
128.11.3.31
Các lớp địa chỉ IP
0 NetID
HostID
Byte 1
Byte 2
Byte 3
Byte 4
HostID
10 NetID
HostID
110 NetID
1110 Multicast address
1111 Reserved
Lớp A
Lớp B
Lớp C
Lớp D
Lớp E
Xác định lớp sử dụng ký pháp thập phân
Lớp A
Lớp B
Lớp C
Lớp D
Lớp E
0 . 0 . 0 . 0
0
0 . 255. 255. 255
127
0 . 0 . 0 . 0
128 . 0
0 . 255. 255. 255
191.255
0 . 0 . 0 . 0
192 . 0 .0
0 . 255. 255 . 255
223. 255. 255
224 . 0 . 0 . 0
239. 255. 255. 255
240 . 0 . 0 . 0
255. 255. 255. 255
Từ
Tới
NetID HostID
NetID HostID
NetID HostID
NetID HostID
NetID HostID
NetID HostID
Multicast
Multicast
Reserved
Reserved
Số mạng và trạm trên mỗi lớp
Địa chỉ lớp A và B đã dùng hết. Địa chỉ lớp C xắp hết, còn địa chỉ lớp D và E dành riêng không phân
Ví dụ về địa chỉ mạng
Cụ thể
Tất cả 0
NetID
HostID
Các loại Option
Options
Single-byte
Multiple-byte
End of option
No Operation
Record route
Strict source route
Loose source route
Timestamp
ICMP - Internet Control Massage Protocol
IP sử dụng ICMP để gửi các thông báo quản lý:
- Thông báo lỗi (error reporting)
- Hỏi (Query)
Bit
0-3
Bit
4-7
Bit
8-11
Bit
12-15
Bit
16-19
Bit
20-23
Bit
24-27
Bit
28-31
Type
Code
Checksum
Định dạng thông báo ICMP
Rest of the header
Data
Các thông báo ICMP
ARP - Address Resolution Protocol
Link/MAC
IP
TCP
UDP
ARP
RARP
Chuyển đổi địa chỉ IP thành địa chỉ tầng Data
link (địa chỉ MAC)
Ethernet LAN
144.78.12.34
144.78.0.0
144.78.12.0
IP: 144.78.12.34
Ethernet?
Nguồn và đích thuộc cùng mạng
Router
Broadcast:
Who has IP
144.78.12.34?
That’s me!
B7.a4.e1.10.91.0a
Put in Eth. head:
B7.a4.e1.10.91.0a,
and send
144.78.12.34
is
B7.a4.e1.10.91.0a
Hoạt động của ARP
Nguồn và đích khác mạng
Router
To Internet
Backbone
IP: 144.78.12.0,
Eth: e4:70:0:0:0:1
Send to:
153.23.10.95
Hoạt động của ARP
Router
To Internet
Backbone
IP: 144.78.12.0,
Eth: e4:70:0:0:0:1
Broadcast:
Who has IP
153.23.10.95?
That’s a remote
Address!
That’s me
E4:70:0:0:0:1
Send: Eth dest.:
E4:70:0:0:0:1,
IP dest.
153.23.10.95
Tối ưu ARP
ARP có thể giảm số lượng request gửi đi bằng cách:
Lưu trữ ánh xạ địa chỉ MAC
Các máy tính có thể thông báo địa chỉ MAC khi khởi động và các máy khác lưu lại.
Các mục được lưu trữ trong một khoảng thời gian nhất định
RARP - Reverse Address Resolution Protocol
Link/MAC
IP
TCP
UDP
ARP
RARP
Chuyển đổi địa chỉ MAC thành địa chỉ IP
Hữu ích cho các máy không có đĩa khởi động
HEY - Everyone please listen!
My Ethernet address is22:BC:66:17:01:75.
Does anyone know my IP address ?
not me
Hi Red ! Your IP address is 128.213.1.17.
Hoạt động của RARP
DHCP - Dynamic Host Configuration Protocol
DHCP
Server
Broadcast:
My hardware address is this. Who am I?
Your IP is that
Relay
Agent
Request IP for Eth
address this
IP address
Sử dụng ARP để gán địa chỉ IP cho các trạm
Tầng giao diện mạng
Ethernet
Tầng liên mạng
Tầng giao diện mạng
ARP
IP
FDDI
PPP
ISDN
ATM
Frame relay
MPLS
Các giao thức chạy dưới IP
Giải pháp xử lý tín hiệu thời gian thực trong mạng gói
Kích thước gói thoại
Các yếu tố giới hạn kích thước gói thoại:
Khả năng mất gói
Trễ đóng gói
VD:

Như vậy kích thước gói thoại là yếu tố quyết định đến chất lượng. Kích thước gói thoại cần được giới hạn để đảm bảo yêu cầu thời gian thực và không quá nhỏ để việc truyền thông tin đạt hiệu quả cao.
Mã hoá tín hiệu thoại
Quá trình mã hoá tín hiệu thoại trong hệ thống VoIP:
Số hoá: Tín hiệu tương tự được lấy mẫu ở tần số 8khz sau đó được mã hoá tuyến tính
Nén tín hiệu: Dòng tín hiệu thoại được nén xuống tốc độ bít thấp theo các tiêu chuẩn nén khác nhau như: G.711(PCM 64Kb/s); G.726(ADPCM 32 Kb/s); G.728; G.729;.
Quá trình mã hoá tín hiệu thoại được tích hợp trong bộ giao tiếp với mạng chuyển mạch khênh Gateway`
Các tiêu chuẩn đánh giá phương pháp nén
Tốc độ bit: Đây là đặc tính đầu tiên của một phương pháp nén thoại, nó thể hiện mức độ nén của phương pháp
Độ trễ: Đây là một đặc điểm quan trọng với ứng dụng thời gian thực. Phụ thuộc chủ yếu vào tốc độ bit
Độ phức tạp: Độ phức tạp thể hiện ở số phép tính và số lượng bộ nhớ cần thiết cho thuật toán nén
Chất lượng tín hiệu: Liên quan đến các tỷ số S/N của tín hiệu tương tự hay hệ số BER của dòng thoại số.
Một số tiêu chuẩn nén thoại
Giao thức RTP/RTCP
Giới thiệu
Các ứng dụng multimedia thời gian thực là gì ?
Điện thoại IP.....
Video hội nghị hay Tele-education
Đặc điểm của ứng dụng loại này
Lưu lượng thời gian thực, dữ liệu truyền đi phải đảm bảo đúng trình tự tại bên nhận không bị trùng lặp
ứng dụng loại này rất nhạy cảm với độ trễ cả trễ jitter
Đồng bộ bên trong mỗi luồng media
Đồng bộ giữa các luồng thông tin media ví dụ khi truyền cả thoại và video
Giới thiệu
Vấn đề đặt ra khi triển khai ứng dụng mutimedia
Khi mạng có dung lượng đường truyền giới hạn được chia sẻ bởi nhiều người sử dụng
Trễ truyền gói không dự báo trước được (best effort)
Các gói tin được truyền đi bình đẳng không phân biệt
Tầng giao vận không thể cung cấp các dịch vụ thời gian thực, vì vậy chức năng này phải được thực hiện ở tầng phía trên - Giao thức RTP
Thường được sử dụng phía trên UDP nhưng được thiết kế để hoạt động độc lập với tầng giao vận
Khoảng lặng
Trong thông tin thời gian thực như thoại, khoảng lặng (hay vùng trắng trong tín hiệu video) chiếm một tỷ trọng khá lớn
Khi hai bên nói truyện với nhau thì thường chỉ có một người nói và một người nghe nên nếu cuộc thoại chiếm cố định cả hai kênh đi và về thì thật lãng phí băng thông
Người ta ước tính khoảng 60% thời gian hội thoại là khoảng lặng
Khoảng lặng
Trong VoIP, nhờ ưu điểm của công nghệ thoại gói và kỹ thuật mã hoá nguồn, bạn có thể chỉ truyền thông tin thoại "hữu thanh" mà không truyền thông tin thoại trong các khoảng im lặng.
Sử dụng thuật toán phát hiện tình trạng tín hiệu (voice activity detection - VAD)
Khi VAD phát hiện sự sụt giảm biên độ tín hiệu thoại, nó sẽ đợi một khoảng thời gian nhất định trước khi dừng việc chèn các khung thoại vào trong gói. Khoảng thời gian này được gọi là hangover và thường là 200ms.
Khoảng lặng
Trình tự các gói tin
Đồng bộ Inter-media
Nhận dạng Payload
Chỉ thị khung
Multicast-friendly
Đặc thù của mỗi loại thông tin Media
Mixer và translator
QoS feedback
Điều khiển hờ các phiên (Loose Session Control)
Mã hoá bảo mật (Encryption)
Yêu cầu dich vụ thời gian thực
RTP-Realtime Transport Protocol
Nhóm nghiên cứu mạng của phòng thí nghiệm quốc gia Lawrence
Berkeley đưa ra chuẩn vat. Sau đó được gọi là RTP version 0
Tháng 12/1992, RTP version 1 được xuất bản,
trải qua một số giai đoạn phát triển Internet và đã được nhìn nhận
như là chuẩn RTP version 2 vào 22/11/1995 (RFC 1889 và 1890)
RTP là một giao thức được phát triển nhằm hỗ trợ khả năng truyền
các dữ liệu thời gian thực như video, audio
Các dịch vụ mà nó cung cấp: định thời, xác định gói tin bị mất, và
nhận dạng nội dung
RTP
Được thiết kế cho các ứng dụng truyền đa điểm, nhưng cũng được áp dụng cho truyền đơn điểm -- Conference
Có thể được sử dụng để truyền dữ liệu một chiều chẳng hạn như ứng dụng VoD (video on demand), cũng có thể truyền hai chiều như ứng dụng trong điện thoại Internet, video hội nghị
Hoạt động với giao thức điều khiển kèm theo là RCTP
Phiên RTP
Là khoảng thời gian một số thành viên trao đổi thông tin với nhau qua RTP
Mỗi thành viên tham gia được xác định nhờ một cặp địa chỉ giao vận đích (1 địa chỉ mạng (IP) và 2 cổng cho RTP và RTCP(UDP))
Trong trường hợp sử dụng cơ chế multicast thì địa chỉ đích của tất cả các thành viên là giống nhau
Phiên RTP
Trong trường hợp sử dụng cơ chế truyền unicast thì mỗi thành viên sẽ có một địa chỉ
Trong 1 phiên multimedia thì mỗi loại thông tin sẽ được truyền trong một phiên RTP ứng với các bản tin RTCP của nó
Các phiên RTP được phân biệt với nhau bởi địa chỉ cổng hoặc địa chỉ multicast
RTP trong H323
RTP trên UDP
Mặc dù RTP được thiết kế để có thể hoạt động trên bất cứ tầng giao vận nào, nhưng nó thường hoạt động trên tầng UDP
Lý do là:
RTP được thiết kế với mục đích chính là hỗ trợ truyền đa điểm chứ không phải đơn điểm
Đối với dữ liệu thời gian thực thì độ tin cậy không quan trọng bằng việc truyền tin đúng thời hạn. TCP sử dụng cơ chế truyền lại khi bị mất gói, dẫn đến trễ lớn
Đóng gói các gói tin RTP
RTP cung cấp các thông tin cho phép tầng ứng dụng ở trên có thể cung cấp dịch vụ thời gian thực, hồi phục gói tin bị mất, đồng bộ luồng dữ liệu hay điều khiển tắc nghẽn
Kích thước Header các lớp 2 khác nhau

Media

Ethernet

PPP

Frame Relay

ATM

Link Layer
Header Size
14 bytes

6 bytes

4 Bytes

5 Bytes Per Cell

Bit Rate

29.6kbps

26.4kbps

25.6kbps

42.4kbps
Ví dụ - G.729 với gói 60 byte (tính từ IP Header)
(Chưa nén RTP Header)
Chú ý - Đối với ATM, 60byte packet đòi hỏi 2tế bào 53 Byte
Ví dụ
Lấy ví dụ minh họa một cuộc gọi audio hội nghị
Phần mào đầu gói tin RTP sẽ chứa các thông tin về nhãn thời gian, thông tin về phương thức mã hoá (e.g., G.729, G.723..), và số thứ tự của gói tin
Gói tin RCTP được dùng để xác định số lượng người nhận và chất lượng thông tin bên nhận nhận được
Dựa vào các thông tin chất lượng nhận được, bên gửi có thể thay đổi phương thức mã hoá thích hợp hơn
Ví dụ
Trong một cuộc nối có cả video và audio, phải có 2 phiên RTP riêng cho audio và video vì:
Mỗi loại thông tin sử dụng một phương thức mã hoá khác nhau
Bên nhận có thể lựa chọn để chỉ nhận thông tin audio trong trường hợp mạng bị nghẽn
Lúc này cần phải đồng bộ giữa hai luồng thông tin
Giải pháp cRTP của Cisco
Gói tin RTP bao gồm 20 byte IP header, 8 byte UDP header, 12 byte RTP header (tổng cộng 40 byte) và thông tin payload
Để tiết kiệm băng thông nâng cao chất lượng dịch vụ người ta sử dụng kiểu nén 40 byte tiêu đề thành 2 hoặc 4 byte
cRTP
Mixer
Sử dung cho truyền thông đa điểm (hội nghị) khi các tín hiệu từ nhiều nguồn cùng gửi đến môt đích
Trong trường hợp nếu có một số người kết nối bằng đường tốc độ thấp, trong khi một số người kết nối bằng đường tốc độ cao không thể bắt mọi người sử dụng cùng một khuôn dạng dữ liệu
Thay vì bắt buộc mọi người phải sử dụng phương thức mã hoá có chất lượng thấp tiết kiệm băng thông, chúng ta sử dụng bộ trộn mixer.
Mixer (tiếp)
Mixer có chức năng nhận thông tin đến từ nhiều nguồn, có thể thay đổi khuôn dạng dữ liệu, ghép các luồng này lại thành một luồng duy nhất và chuyển tiếp đến đích
Mixer phải đồng bộ các luồng tín hiệu đầu vào, sau đó phát ra thông tin định thời cho luồng thông tin kết hợp
Translator
Có thể có các thành viên kết nối bằng đường tốc độ cao, nhưng lại bị chặn bởi filewall lúc này cần sử dụng các translator
Hoặc giữa hai mạng có tầng giao vận khác nhau, phải sử dụng translator để chuyển đổi khuôn dạng gói tin
Translator cũng có thể chuyển đổi từ multicast sang unicast
Mixer và translator
Hai thiết bị này không phải là phần tử trong mạng H323
Các thành phần trong mạng H323 (MCU và Gateway) có một số chức năng như mixer và translator
Gateway kết nối giữa hai mạng chuyển mạch gói hoạt động như một translator
Nhãn tiêu đề RTP
Phần mào đầu gói tin RTP
Version (V) 2 bit: RTP version (mới nhất hiện nay là 2)
Padding (P) 1 bit: Nếu bít này được thiết lập, gói tin chứa phần thông tin chèn thêm. Byte cuối cùng của phần chèn thêm cho biết số lượng byte được chèn thêm vào gói tin
Extension (X) 1 bit: Nếu được thiết lập, phần mào đầu của gói tin RTP sẽ có thêm phần mở rộng
Phần mào đầu gói tin RTP
CSRC count (CC) 4 bit: Số lượng các nguồn tham gia (CSRC) nằm trong phần mào đầu gói tin, số lượng này lớn hơn 1 nếu các gói tin RTP đến từ nhiều nguồn
Marker (M) 1 bit: dành cho lớp ứng dụng, chẳng hạn như khi đóng gói gói tin thoại sử dụng triệt khoảng lặng, bít này được dùng để đánh dấu gói tin bắt đầu có tín hiệu thoại (sau khoảng lặng)
Nhận dạng kiểu tải tin
Payload type (PT) 7 bit: Xác định loại tải trong gói RTP, dạng dữ liệu cũng như phương thức mã hoá/nén được sử dụng, nhờ đó bên nhận biết được phương thức giải mã và xử lý thông tin
Giá trị mặc định của các kiểu tải tin này được xác định trong RFC1890 bao gồm: PCM, MPEG1/MPEG2 audio and video, JPEG video, Sun CellB video, H.261 video streams, vv...
Tại bất kỳ thời điểm truyền tin nào, bên gửi chỉ có thể gửi một loại tải tin duy nhất, mặc dù kiểu tải tin có thể thay đổi trong suốt quá trình truyền tin
Phần mào đầu gói tin RTP
SSRC 32 bit: Được chọn ngẫu nhiên, được sử dụng để phân biệt giữa các nguồn phát trong cùng một phiên RTP. Nó xác định dữ liệu đến từ đâu (nếu chỉ có một nguồn phát) hoặc nó được ghép lại ở đâu (mixer) nếu có nhiều nguồn phát
CSRC list: 0 đến 15 giá trị CSRC, mỗi giá trị có kích thước 32 bít. Số lượng các giá trị này được xác định trong trường CC (nói ở trên). Cho biết gói tin được tạo thành từ các nguồn thông tin nào.
Số thứ tự các gói tin
Sequence number (SN)-16 bit: Giá trị này được tăng dần theo gói tin gửi đi.
Nó được bên nhận dùng để sắp xếp các gói tin theo đúng thứ tự và phát hiện ra gói tin bị mất
Trong một số luồng thông tin video, một khung video sẽ được chia nhỏ để đút vào một số các gói tin RTP, vì thế chúng sẽ có cùng một giá trị nhãn thời gian. Vì thế, chỉ có nhãn thời gian sẽ không đủ để sắp xếp các gói tin theo đúng thứ tự, cần phải có SN
Nhãn thời gian
Timestamp 32 bit: Bên gửi thiết lập nhãn thời gian khi byte đầu tiên của gói tin được lấy mẫu và giá trị của nó được tăng dần. Nó được sử dụng để đồng bộ và tính toán jitter .
Thang thời gian phụ thuộc vào tần số lấy mẫu của bộ CODEC
Nhãn thời gian
Bên nhận dựa vào nhãn này để định thời các gói tin nhận được và phát dữ liệu ra theo đúng tốc độ ban đầu.
Nhãn thời gian còn được sử dụng để đồng bộ các luồng thông tin khác nhau như audio và video
Thang thời gian phải đủ nhỏ để đồng bộ chính xác và đảm bảo để tính toán độ trễ jitter
Xác định nguồn
Mục đích : Cho phép bên nhận biết dữ liệu đến từ đâu
Ví dụ trong cuộc gọi audio hội nghị, bên nhận có thể biết được ai đang nói
Có 2 thông tin để nhận dạng nguồn là:
SSRC : Synchronization Source
CSRC : Contributing Source
SSRC
Tất cả các gói tin RTP xuất phát từ cùng một nguồn sẽ có cùng giá trị SSRC
Các gói tin xuất phát từ cùng một nguồn (có cùng SSRC) sẽ được đánh số thứ tự (sequence number), vì thế, tại đầu thu, các gói tin sẽ được nhóm lại theo SSRC theo đúng thứ tự rồi giải mã
SSRC (tiếp)
Giá trị SSRC được cấp phát ngẫu nhiên
Trong một phiên RTP, giá trị SSRC phải khác nhau (hoàn toàn)
Bởi vậy sẽ có khả năng xảy ra xung đột (SSRC trùng nhau)
Xử lí trong trường hợp xảy ra xung đột
Bên phát thấy có xung đột : thoát ra và khởi động lại
Bên nhận thấy có xung đột: Phân biệt bằng địa chỉ mạng, nếu không được nó sẽ không làm gì cả
SSRC
Gói tin RTP do Mixer truyền đi phải có:
SSRC được sinh ra tại mixer
Danh sách các CCRC được lấy từ các SSRC của các gói tin đến Mixer
Gói tin RTP khi đi qua Translator, SSRC vẫn được giữ nguyên
RTP - Phần mào đầu mở rộng
Mục đích: Mặc dù các thông tin trong phần mào đầu RTP khá đầy đủ, có thể đáp ứng cho các ứng dụng hiện nay, nhưng để phòng trường hợp cần sửa đổi để đáp ứng các ứng dụng mới, người ta đưa ra phần mào đầu mở rộng


RTCP - RTP Control Protocol
Bản thân RTP không thể cung cấp các thông tin về chất lượng dữ liệu mà nó truyền đi
RTCP là một giao thức điều khiển được thiết kế để sử dụng kết hợp với RTP
Trong một phiên RTP, các thành viên tham gia sẽ đều đặn gửi các bản tin điều khiển RTCP (sau một khoảng thời gian nào đó) đến các thành viên khác để xác định chất lượng truyền dữ liệu và thông tin về các thành viên khác
Các dịch vụ RTCP cung cấp
Giám sát QoS và điều khiển tắc nghẽn
Đây là chức năng cơ bản của RTCP.
RTCP cung cấp thông tin phản hồi về chất lượng phân bố dữ liệu
Các thông tin điều khiển này rất hữu ích đối với bên gửi, bên nhận và người giám sát mạng
Bên gửi có thể thay đổi chế độ truyền dựa trên báo cáo của bên nhận gửi lại
Bên nhận xác định được tắc ngẽn là cục bộ hay toàn cục
Nhà quản trị mạng có thể đánh giá được khả năng truyền dữ liệu của mạng
Các dịch vụ RCTP cung cấp
Xác định nguồn
Trong gói tin RTP, nguồn được nhận diện bằng một giá trị 32 bít được phát ngẫu nhiên -SSRC
Thông tin này không dễ quan sát bởi người dùng
Chúng có thể thay đổi khi hồi phục lại sau khi xảy ra xung đột
Gói tin SDES (source description) của RCTP chứa các thông tin về thành viên tham gia vào cuộc gọi dưới dạng văn bản (text)
Các thông tin này có thể là tên người dùng, số điện thoại, địa chỉ email hoặc một dạng thông tin khác
Các dịch vụ RTCP cung cấp
Đồng bộ giữa các luồng thông tin
RTCP sender report chứa chỉ thị thời gian thực và RTP timestamp tương ứng.
Đồng bộ giữa các luồng thông tin
Các dịch vụ RTCP cung cấp
Điều chỉnh các thông tin điều khiển
Các gói tin RTCP được gửi liên tục cứ sau một khoảng thời gian nào đó giữa các thành viên tham gia cuộc gọi hội nghị
Lưu lượng RTCP phải vừa đủ để cập nhập được thông tin điều khiển kịp thời, nhưng không được thừa
Lưu lượng thông tin điều khiển chỉ nên chiếm 5% lưu lượng thông tin media (RTP)
Lưu lượng thông tin điều khiển
RTP được thiết kế cho phép số thành viên tham gia vào phiên có thể tăng dần lên (từ một số ít lên đến hàng ngàn)
Nếu tốc độ gửi gói tin RCTP là cố định thì lưu lượng cho thông tin điều khiển sẽ tăng tuyến tính theo số lượng thành viên
Chiếm một tỉ lệ xác định so với băng thông toàn bộ
Lưu lượng thông tin điều khiển
Giá trị này đủ bé nhưng vẫn phải đảm bảo các thông tin điều khiển vẫn cung cấp đầy đủ các thông tin cơ bản, khuyến nghị là 5%
Khoảng thời gian giữa hai lần truyền gói tin RCTP cần phải được điều chỉnh để tránh tắc nghẽn mạng
Các gói tin RTCP được gửi liên tục cứ sau một khoảng thời gian nào đó giữa các thành viên tham gia cuộc gọi hội nghị
Lưu lượng thông tin điều khiển
RTP được thiết kế cho phép số thành viên tham gia vào phiên có thể tăng dần lên (từ một số ít lên đến hàng ngàn)
Nếu tốc độ gửi gói tin RCTP là cố định thì lưu lượng cho thông tin điều khiển sẽ tăng tuyến tính theo số lượng thành viên
Lưu lượng RTCP phải vừa đủ để cập nhập được thông tin điều khiển kịp thời, nhưng không được thừa ra
Lưu lượng thông tin điều khiển
Mỗi phiên RTP sẽ được cấp phát một băng thông, lưu lượng thông tin điều khiển nên chiếm một tỉ lệ nhỏ xác định so với băng thông toàn bộ của phiên
Giá trị này đủ bé nhưng vẫn phải đảm bảo các thông tin điều khiển vẫn cung cấp đầy đủ các thông tin cơ bản, khuyến nghị là 5%
Cần phải có phương pháp để tính toán thời gian giữa hai lần truyền gói tin RCTP (tham khảo phụ lục A.7 H225)
Các loại bản tin RTCP
RR (Receiver Report) - Được gửi đi từ một thành viên đang ở trạng thái không truyền dữ liệu RTP (not active sender). Chứa các thông tin phản hồi lại chất lượng thông tin mà nó nhận được
SR (Sender Report) - Được gửi đi từ thành viên đang ở trạng thái truyền dữ liệu (active sender). Ngoài các thông tin giống hệt như RR,nó còn chứa thêm các thông tin về bên gửi
Các loại bản tin RTCP
SDES (source description) - Chứa các thông tin mô tả nguồn, các thông tin này có thể là tên, số điện thoại...
BYE: Cho biết thành viên này ngừng tham gia vào phiên RTP
APP: Để dành cho việc thử nghiệm các ứng dụng mới, các tính năng mới được phát triển
Thông tin phản hồi trong các bản tin báo cáo RTCP
Tỉ lệ mất gói tin và tổng số gói tin bị mất
Độ trễ jitter trung bình
Nếu các thành phần thông tin này vượt quá một ngưỡng quy định nào đó (thường là do các nhà sản xuất quyết định) thì bên gửi phải thực hiện thủ tục thay đổi kiểu mã hoá, hoặc các thông số liên quan đến chuẩn mã hoá để giảm băng thông
Hoặc nếu không thì nó có thể đóng bớt các kênh thông tin
Nhiều gói tin RCTP trong một gói UDP
Kích thước của các gói tin RCTP luôn là bội số của 32
Nó được bắt đầu với một phần cố định cộng thêm với một phần mở rộng có kích thước thay đổi
Kích thước của các gói tin RCTP luôn có thể tính được dựa vào các thành phần thông tin của nó.
Vì thế có thể xếp nhiều gói tin RCTP cạnh nhau không cần các dấu hiệu phân cách, để tạo thành một gói tin RCTP chung và trong một gói tin ở tầng dưới, chẳng hạn như UDP.
Nhiều gói tin RCTP trong một gói UDP
Mặc dù các gói tin RCTP nằm trong cùng một gói tin UDP được xử lí độc lập, nhưng chúng cũng cần phải tuân theo một số qui định
Tất cả các gói tin RCTP compound đều nên chứa các gói tin SR hoặc RR
Mỗi gói tin RCTP compound nên chứa một bản tin xác định nguồn SDES

Bản tin sender report và receiver report
Phía nhận thông tin RTP phản hồi lại chất lượng thông tin nhận được thông qua 2 loại bản tin này
Hai bản tin này hầu như giống nhau, chỉ khác mã nhận dạng và bản tin sender report sẽ có thêm 20 byte thông tin về người gửi nếu
Trong các bản tin này, mỗi SSRC sẽ có tương ứng một khối thông tin thông báo chất lượng dữ liệu nhận được từ SSRC này
Những thông tin này không có cho các CSRC
Bản tin receive report
Bản tin sender và receice report
version (V): 2 bít, cho biết phiên bản của RTP (2)
padding (P): 1 bít, nếu =1 cho biết bản tin RCTP này có chứa phần chèn thêm
RC (reception report count) cho biết số lượng các khối thông báo chất lượng trong gói tin (có thể bằng 0)
SSRC: định danh nguồn cho chính nó
Bản tin sender và receice report
Phần thông tin cuối chứa một số các khối thông tin phản ánh chất lượng dữ liệu đến từ các nguồn khác nhau, tương ứng với các SSRC
SSRC_n: định danh cho nguồn thứ n
NTP Timestamp:
fractionloss: số lượng gói tin bị mất chia cho số lượng gói tin đáng lẽ sẽ nhận được
Tổng số gói tin bị mất: tổng số gói tin phát đi từ SSCR_n đã bị mất kể từ khi bắt đầu nhận
Phần mở rộng của các bản tin báo cáo
Nếu các ứng dụng mới cần thêm các thông tin phản hồi khác, nó có thể tự định nghĩa phần thông tin mở rộng này để sử dụng
Phương pháp này hay được sử dụng hơn là định nghĩa ra một loại bản tin RTCP mới, vì tốn ít thông tin mào đầu hơn
Bản tin sender và receice report
Interarrival jitter: giá trị trung bình sai lệch trễ của các gói tin RTP
Được tính theo đơn vị của nhãn thời gian
biểu diễn bằng giá trị nguyên

Bản tin nhận dạng nguồn SDES
Bản tin nhận dạng nguồn SDES
Version (V),padding (P), length:giống như trong bản tin SR,RR
PacketType=202 (8bit)
Source count (SC): 5bít, số lượng nguồn sẽ được mô tả trong bản tin này
Mỗi nguồn