Tìm hiểu các giao thức truyền thời gian thực realtime protocols

Số thứ tự trong RTP cho phép người nhận tái tạo lại theo đúng trình tự các gói tin của người gửi nhưng các số thứ tự cũng có thể được sử dụng để xác định vị trí đúng của một gói tin, ví

BỘ GIÁO DỤC VÀ ĐÀO TẠO TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI

-

VŨ VĂN ĐỐC

ĐỀ TÀI: TÌM HIỂU GIAO THỨC TÌM THỜI GIAN THỰC HIỆN

REALTIME PROTOCOLS

LUẬN VĂN THẠC SĨ KHOA HỌC

NGÀNH:CÔNG NGHỆ THÔNG TIN

NGƯỜI HƯỚNG DẪN KHOA HỌC:

TS.DĂNG VĂN CHUYẾT

HÀ NỘI - 2010

MỤC LỤC

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

DANH MỤC CÁC HÌNH VẼ, ĐỒ THỊ 6

MỞ ĐẦU 8

CHƯƠNG 1 – TỔNG QUAN 10

1.1 Giới thiệu 10

1.2 Kịch bản sử dụng RTP 11

1.2.1 Hội nghị Audio đa hướng đơn giản 11

1.2.2 Audio và Video Conference 12

1.2.3 Thiết bị trộn và thiết bị truyền tin 13

1.3 Định nghĩa 14

1.4 Thứ tự byte, sắp xếp, và định dạng thời gian 17

CHƯƠNG 2 CÁC GIAO THỨC TRUYỀN THỜI GIAN THỰC 18

2.1 Giao thức truyền dữ liệu RTP 18

2.1.1 Trường tiêu đề cố định RTP 18

2.1.2 Phiên dồn kênh RTP 21

2.1.3 Sự thay đổi của tiêu đề RTP trong một số trường hợp 22

2.1.4 RTP Header Extension – Tiêu đề RTP mở rộng 23

2.2 Giao thức điều khiển RTCP 24

2.2.1 RTCP Packet Format: Định dạng gói tin RTCP 26

2.2.2 Khoảng thời gian truyền các gói RTCP 28

2.2.3 Báo gửi và báo nhận 32

2.2.4 SDES: gói tin RTCP mô tả thông tin nguồn 42

2.2.5 BYE: Goodbye RTCP packet 48

2.3 RTP Translators và Mixers 50

2.3.1 Mô tả chung 51

2.3.2 Quá trình xử lý RTCP trong Translators 54

2.3.3 Quá trình xử lý RTCP trong Mixers 56

2.3.4 Cascaded Mixers – Các Mixer mắc phân tầng: 58

2.4 Phân bổ và sử dụng SSRC Identifier 59

2.4.1 Xác suất xung đột 60

2.4.2 Giải quyết xung đột và phát hiện vòng lặp 60

2.5 Security – Vấn đề bảo mật trong RTP 66

2.5.1 Khả năng che dấu dữ liệu: 66

2.5.2 Authentication and Message Integrity - Xác thực và toàn vẹn dữ liệu 67

2.6 RTP với các giao thức lớp mạng và giao vận 67

2.7 Tóm tắt các hằng số giao thức 68

2.7.1 RTCP packet types - Các kiểu gói RTCP 69

2.7.2 SDES type – Loại SDES 69

2.8 Các đặc tả định dạng Payload và Profiles RTP 70

2.8.1 Payload và Profiles RTP 70

2.8.2 Đặc tả định dạng giao thức thời gian thực RTP .71

2.8.3 Đặc tả định dạnh giao thức truyền dòng thời gian thực .73

2.8.4 Đặc tả định dạng giao thức điều khiển thời gian thực RTCP 75

2.8.5 Các định dạng payload .76

2.9 Một số giao thức được sử dụng trong truyền thời gian thực 77

2.9.1 Giao thức RSVP (Resource Reservation Protocol) 77

2.9.2 Giao thức IGMP (Internet Group Management Protocol) 80

2.9.3 Giao thức RTSP (Real-Time Streaming Protocol) 83

CHƯƠNG 3 MÔ PHỎNG GIAO THỨC RTP TRÊN NS 85

3.1 Giới thiệu bộ mô phỏng Network Simulator (NS): 85

3.2 Kịch bản mô phỏng: 88

3.3 Đánh giá kết quả mô phỏng .89

CHƯƠNG 4 KẾT LUẬN 93

4.1 Kết quả đạt được của luận văn 93

4.2 Đánh giá ưu điểm và hạn chế của luận văn 93

4.3 Hướng phát triển tiếp theo của luận văn .94

TÀI LIỆU THAM KHẢO 95

PHỤ LỤC 97

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

Các ký tự viết

tắt

Giải thích

APP Application specific functions

CNAME Canonical name

CSRC Contributing SSRC

DLSR Delay since last SR

IGMP Internet Group Management Protocol

RC Reception report count

RCTP Real time Transfer Control Protocol

RR Receiver report

RSVP Resources Reservation Set - tup Protocol

RTP Realtime Transfer Protocols

RTSP Real Time Stream Protocol

SC Source count

SDES Source description items

SDP Secsion DecrIPt Protocol

TCP Tranmission Control Protcol

TSEL Transport selectors

UDP Uer Datagram Protocol

DANH MỤC CÁC HÌNH VẼ, ĐỒ THỊ

1 Hình 1.1: RTP trong hội thảo sử dụng cả video/audio 13

2 Hình 2.1 Định dạng phần header của gói RTP 18

3 Hình 2.2 Tiêu đề RTP mở rộng 23

4 Hình 2.3 Ghép các gói RTCP vào gói UDP 28

5 Hình 2.4 Ghép các gói RTCP vào gói #: SSRC/CSRC 28

6 Hình 2.5 Gói tin RTCP báo gửi 34

7 Hình 2.6 Gói RTCP báo nhận 39

8 Hình 2.7 Gói tin RTCP mô tả thông tin nguồn 42

9 Hình 2.8 Cấu trúc SDES item 43

10 Hình 2.9 Canonical end-point identifier SDES item 44

11 Hình 2.10 User name SDES item 45

12 Hình 2.11 Cấu trúc Email 46

13 Hình 2.12 Phone number SDES item 46

14 Hình 2.13 Geographic user location SDES item 46

15 Hình 2.14 Application or tool name SDES item 47

16 Hình 2.15 Notice/status SDES item 47

17 Hình 2.16 Private extensions SDES item 48

18 Hình 2.17 Goodbye RTCP packet 49

19 Hình 2.18 Application-defined RTCP packet 49

STT Danh mục các hình vẽ,đồ thị Trang

20 Hình 2.19 Minh họa tác động của “mixer” và “translator” tới giá trị

21 Hình 2.20 Quá trình xử lý RTCP trong Translators 54

22 Hình 2.21 Quá trình xử lý RTCP trong Mixers 56

24 Hình 2.23 Cascaded Mixers – Các Mixer mắc phân tầng 58

25 Hình 2.24 Collision Resolution and Loop Detection 61

26 Hình 2.25 Khả năng che dấu dữ liệu 66

27 Hình 2.26 RTCP packet types - Các kiểu gói RTCP 69

28 Hình 2.27 Các hằng số khác được chỉ định bởi IANA 70

29 Hình 2.28 Cấu trúc tiêu đề cố định RTSP 73

30 Hình 3.1 NS theo quan điểm người dùng 85

31 Hình 3.2 Mô hình kiến trúc của NS 87

32 Hình 3.3 Cấu hình mạng mô phỏng 88

33 Hình 3.4 Kết quả mô phỏng bằng NAM khi băng thông đủ 90

34 Hình 3.5 Kết quả mô phỏng bằng Graph khi băng thông đủ 90

35 Hình 3.6 Kết quả mô phỏng bằng NAM khi băng thông không đủ 91

36 Hình 3.7 Kết quả mô phỏng bằng Graph khi băng thông không đủ 92

MỞ ĐẦU

Hiện nay, các ứng dụng đa phương tiện thời gian thực đã và đang được quan tâm ứng dụng nhiều Các ứng dụng này đòi hỏi có độ trễ truyền không đổi và băng thông cố định Giao thức TCP (Tranmission Control Protcol) và UDP (User Datagram Protocol)

là các giao thức được sử dụng rộng rãi trên Internet Tuy nhiên, các giao thức này không đủ các điều kiện đảm bảo truyền thời gian thực

Giao thức truyền thời gian thực được đề xuất để phục vụ cho các dịch vụ truyền thời gian thực trong mạng Việc tìm hiểu, đánh giá, ứng dụng các giao thức truyền thời gian thực đã được quan tâm, nghiên cứu và triển khai nhiều Tuy nhiên việc triển khai các ứng dụng truyền thời gian thực ở Việt Nam cũng còn là vấn đề khá mới Để phục

vụ công tác giảng dạy trong các trường Đại học Kinh tế Kỹ thuật Công nghiệp, tôi muốn nghiên cứu sâu về vấn đề này Được sự đồng ý, động viên của giáo viên hướng

dẫn khoa học, tôi đã chọn đề tài “Tìm hiểu các giao thức truyền thời gian thực

(Realtime Protocols)” làm đề tài nghiên cứu cho luận văn cao học của mình

Trong luận văn của mình, tôi đã tìm hiểu kỹ về giao thức truyền thời gian thực RTP, giao thức điều khiển truyền thời gian thực RCTP, các quá trình xử lý trong việc truyền và trộn gói tin, tìm hiểu các vấn đề về bảo mật trong RTP Đồng thời sử dụng

NS (Network Simulator) để mô phỏng và đánh giá chất lượng dịch vụ của các giao thức này

Trong luận văn, sử dụng phương pháp tổng hợp và phân tích tư liệu kết hợp với triển khai thực nghiệm Trên cơ sở nghiên cứu lý thuyết cơ bản về giao thức RTP và RTCP cùng với việc sử dụng mô phỏng để đánh giá hiệu quả của các giao thức trên

Ý nghĩa khoa học và thực tiễn của đề tài: Về mặt lý thuyết, đề tài tiếp cận một hướng nghiên cứu trong lĩnh vực truyền đa phương tiện thời gian thực Đồng thời trình bày những nguyên tắc cơ bản trong giao thức RTP và RCTP cũng như kỹ thuật truyền, trộn gói tin của giao thức Về mặt thực tiễn, đề tài có thể được ứng dụng trong việc việc mô phỏng một số giao thức như RTP, TCP, UDP… phục vụ trong việc giảng dạy

trong trường Đại học Kinh tế Kỹ thuật công nghiệp và có thể ứng dụng trong việc triển khai các giao thức truyền đa phương tiện thời gian thực trong nước cũng như trên thế giới

Nội dung luận văn được phân làm 4 chương:

Chương 1 Tổng quan Chương này giới thiệu tổng quan về các kịch bản, các

khái niệm và thiết bị sử dụng trong giao thức truyền đa phương tiện thời gian thực

Chương 2 Các giao thức truyền thời gian thực Chương này trình bày cụ thể

về các giao thức truyền thời gian thực RTP và giao thức điều khiển truyền RCTP, trình bày sơ bộ một số giao thức truyền thời gian thực khác như RSVP, IGMP, RTSP

Chương 3 Mô phỏng giao thức RTP trên NS Sử dụng ngôn ngữ NS để mô

phỏng giao thức theo kịch bản, đánh giá một vài chỉ số về chất lượng truyền trong giao thức RTP

Chương 4 Kết luận Chương này đưa ra những kết quả đạt được của luận văn,

những đóng góp mới và kiến nghị của tác giả

Chương 1 – TỔNG QUAN

RTP Giao thức truyền thông cho các ứng dụng thời gian thực, cung cấp việc truyền dữ liệu từ đầu cuối tới đầu cuối cho các dữ liệu thời gian thực qua mạng, chẳng hạn như âm thanh, video hay mô phỏng dữ liệu qua các dịch vụ truyền thông đa hướng (multicast) hoặc truyền thông đơn hướng RTP không ghi địa chỉ nguồn tài nguyên và không đảm bảo chất lượng của dịch vụ cho các dịch vụ mang tính thời gian thực Việc vận chuyển dữ liệu được tăng cường bởi một giao thức điều khiển (RTCP) để cho phép giám sát việc phân phối dữ liệu trong một mạng rộng truyền thông đa hướng, và để cung cấp tối thiểu sự điều khiển và chức năng nhận dạng RTP và RTCP được thiết kế độc lập với tầng Transport và tầng Network

1.1 Giới thiệu

Giao thức truyền thông RTP dùng cho các ứng dụng thời gian thực, cung cấp việc truyền dữ liệu từ đầu cuối tới đầu cuối với các dữ liệu có đặc điểm thời gian thực qua mạng ,ví dụ như tương tác Audio và Video Những dịch vụ đó bao gồm định nghĩa kiểu tải trọng trong gói (payload type identifier), số sequence, nhãn thời gian (timestamp) và kiểm tra phân phát dữ liệu Các ứng dụng thông thường sử dụng RTP trên giao thức UDP, sử dụng các dịch vụ dồn kênh và kiểm tra dịch vụ, cả hai giao thức góp phần vào thực hiện chức năng của giao thức vận chuyển Tuy nhiên, RTP có thể được sử dụng với mạng khác ở tầng dưới, hoặc các giao thức vận chuyển (xem phần 10) RTP hỗ trợ truyền dữ liệu đến nhiều điểm đích bằng cách sử dụng phân tán đa hướng cung cấp bởi tầng mạng ở dưới

Bản thân RTP dựa vào các dịch vụ ở tầng thấp hơn để cung cấp cơ chế đảm bảo nhận kịp thời hoặc đảm bảo chất lượng của dịch vụ Nó không giả định rằng mạng ở dưới là đáng tin cậy và cung cấp các gói tin theo đúng thứ tự Số thứ tự trong RTP cho phép người nhận tái tạo lại theo đúng trình tự các gói tin của người gửi nhưng các số thứ tự cũng có thể được sử dụng để xác định vị trí đúng của một gói tin, ví dụ trong giải mã đoạn video không nhất thiết phải giải mã các gói tin theo thứ tự

Trong khi RTP được thiết kế chủ yếu để đáp ứng nhu cầu của nhiều người tham gia hội nghị đa phương tiện, nó không giới hạn đối với những ứng dụng cụ thể Đặc điểm chính của giao thức RTP đó là lưu trữ dữ liệu liên tục, tương tác mô phỏng phân tán, gắn nhãn năng động, ứng dụng điều khiển và đo lường

Tài liệu này định nghĩa RTP, bao gồm hai phần liên kết chặt chẽ:

o Giao thức vận chuyển thời gian thực (RTP), để vận chuyển dữ liệu có đặc tính thời gian thực

o Giao thức điều khiển truyền RTP (RTCP), để theo dõi chất lượng dịch vụ và để truyền tải thông tin về những người tham gia trong một phiên làm việc

1.2 Kịch bản sử dụng RTP

Những phần sau đây mô tả một số khía cạnh của việc sử dụng RTP Các ví dụ đã được chọn để minh họa cho hoạt động cơ bản của các ứng dụng bằng cách sử dụng RTP, không phải để giới hạn những gì có thể được sử dụng bởi RTP Trong các ví dụ này, RTP được thực hiện trên giao thức IP và UDP

1.2.1 Hội nghị Audio đa hướng đơn giản

Một nhóm làm việc của IETF họp để thảo luận về bản dự thảo giao thức mới nhất,

sử dụng dịch vụ multicast IP của Internet cho truyền giọng nói.Thông qua một số cơ chế cấp phát các nhóm làm việc thu được một địa chỉ nhóm multicast và sử dụng đồng thời 2 cổng Một cổng được sử dụng cho dữ liệu âm thanh, và cổng khác được sử dụng

để truyền tín hiệu điều khiển các gói tin (RTCP) Thông tin địa chỉ và cổng được phân phát đến những người dự định tham gia Nếu muốn bảo mật, các gói tin dữ liệu và điều khiển có thể được mã hóa theo quy định tại mục 9.1, trong trường hợp đó một khoá mã hóa cũng phải được tạo ra và truyền kèm theo

Các ứng dụng hội nghị truyền âm thanh được sử dụng bởi mỗi người tham gia hội nghị sẽ gửi dữ liệu âm thanh theo từng đoạn nói nhỏ, trong thời gian 20 ms Mỗi khối

dữ liệu âm thanh được gắn thêm một tiêu đề (header RTP) RTP header và các dữ liệu được chứa trong một gói tin UDP Các tiêu đề RTP chỉ ra kiểu mã hóa của âm thanh

(như PCM, ADPCM hay LPC) được chứa trong mỗi gói tin để người gửi có thể thay đổi mã hóa trong suốt thời gian hội nghị, ví dụ, để cung cấp cho một người mới tham gia kết nối thông qua một liên kết băng thông thấp hoặc đối phó với dấu hiệu tắc nghẽn mạng

Internet, giống như các mạng chuyển mạch gói khác, đôi khi mất và lặp lại gói tin

và làm trễ chúng bởi sự thay đổi của thời gian Để đối phó với những điều này, trong tiêu đề của RTP chứa thông tin thời gian và một số thứ tự cho phép người nhận có thể tái tạo lại thời gian của người gửi, như trong ví dụ này, các âm thanh được phát ra liên tục kế tiếp nhau bởi người nói trong mỗi khoảng thời gian là 20 ms Việc xây dựng lại thời gian này được thực hiện riêng cho mỗi nguồn của các gói tin RTP trong hội nghị Bên nhận có thể dựa vào số thứ tự để đánh giá có bao nhiêu gói tin đã bị mất của mỗi nguồn kể từ khi họ tham gia hội nghị

Khi các thành viên của nhóm tạo liên kết hay hủy liên kết trong thời gian hội nghị,

nó xác định được ai đang tham gia tại mỗi thời điểm và họ nhận dữ liệu âm thanh như thế nào Với mục đích đó, mỗi trường hợp của các ứng dụng âm thanh trong hội nghị, theo định kỳ nhận một báo cáo tiếp nhận, cộng với tên của người sử dụng nó trên cổng RTCP Bản báo cáo cũng cho biết chất lượng âm thanh đang được nhận và có thể dùng

để điều khiển khả năng thích ứng mã hóa Ngoài việc bổ sung tên người dùng, các thông tin nhận biết khác có thể cũng được sử dụng để điều khiển giới hạn băng thông Khi một thành viên rời khỏi hội nghị, họ sẽ gửi một gói tin RTCP BYE để thông báo

1.2.2 Audio và Video Conference

Nếu cả hai phương tiện truyền âm thanh và video cùng được sử dụng trong một hội nghị, chúng được phát như các phiên RTP riêng biệt Các gói tin RTCP được truyền với mỗi phương tiện, sử dụng hai cặp cổng UDP khác nhau và/hoặc địa chỉ multicast Không có liên kết trực tiếp tại mức RTP giữa 2 phiên Audio và Video, ngoại trừ một người dùng tham gia vào cả hai phiên và sử dụng một định danh trong gói tin RTCP để các phiên có thể liên kết được với nhau

Việc chia này là để cho phép một số người tham gia hội nghị có thể chọn một phương thức chỉ nhận Audio hoặc Video Mặc dù phân tách, sự phát lại đồng bộ của nguồn âm thanh và video có thể đạt được bằng cách sử dụng thông tin thời gian thực trong các gói tin RTCP cho cả hai phiên

1.2.3 Thiết bị trộn và thiết bị truyền tin

Giả sử rằng tất cả các vị trí muốn nhận được dữ liệu với cùng kiểu định dạng Tuy nhiên, điều này có thể không phải lúc nào cũng thích hợp Hãy xem xét những trường hợp có thành viên sử dụng đường truyền với tốc độ thấp kết nối với hội nghị bao gồm những người sử dụng đường truyền với tốc độ cao Thay vì buộc tất cả mọi người sử dụng một băng thông thấp và bộ mã hóa chất lượng âm thanh kém, một thiết bị trộn (mixer) có thể được đặt gần khu vực băng thông thấp Thiết bị trộn này đồng bộ hóa lại gói tin Audio đến để tái tạo lại âm thanh không đổi khoảng 20 ms của người gửi Sự trộn này tái tạo lại âm thanh thành một dòng duy nhất, truyền và mã hóa audio trong một băng thông thấp hơn và chuyển tiếp gói tin qua đường truyền tốc độ thấp Những gói tin này có thể được truyền đơn hướng cho một người nhận hoặc đa hướng tới nhiều người nhận Phần RTP header sẽ đảm nhiệm việc định danh lại người

Hình 1.1: RTP trong hội thảo sử dụng cả video/audio

gửi tại bên nhận RTP-level còn có thể sử dụng để thay đổi độ phân giải của tín hiệu Video cho phù hợp với từng thành viên tham gia

Ngoài ra chúng ta còn kể đến trường hợp, một thành viên sử dụng đường truyền tốc

độ cao, nhưng họ lại không thể nhận trực tiếp các gói IP multicast Ví dụ, họ có thể được kết nối qua một Firewall mức ứng dụng, không cho phép bất kỳ gói tin IP nào đi qua Đối với các vị trí này, thiết bị trộn có thể không cần thiết, thay vào đó ta sẽ phải cài đặt 2 bộ RTP-level mixer Một được đặt bên trong firewall, một phía ngoài firewall

có thể truyền các gói tin multicast tới một nhóm multicast bị giới hạn bên trong mạng Thiết bị trộn và truyền có thể được thiết kế cho nhiều mục đích Ví dụ như thiết bị trộn video sắp xếp các ảnh của người riêng biệt trong các lớp video riêng rẽ và tổng hợp chúng lại trong một dòng video để tái tạo thành một chuỗi hoạt động liên tục

1.3 Định nghĩa

- RTP payload: Các dữ liệu vận chuyển bằng RTP trong một gói tin, ví dụ mẫu âm

thanh hoặc dữ liệu video đã được nén Định dạng và giải thích payload không nằm trong phạm vi tài liệu này

- Gói RTP: Một gói dữ liệu bao gồm các tiêu đề RTP cố định, một danh sách có thể

rỗng của các nguồn đóng góp và phần dữ liệu payload Một số giao thức lớp dưới có thể yêu cầu phải đóng gói lại các gói RTP Thông thường một gói tin của giao thức lớp dưới chứa một gói tin RTP duy nhất, nhưng một số gói tin RTP có thể được kèm nếu được phép của phương thức đóng gói lớp dưới (xem Phần 10)

- Gói RTCP: Đây là gói tin điều khiển RTCP bao gồm một phần tiêu đề cố định

tương tự như của gói dữ liệu RTP, tiếp theo là các phần tử có cấu trúc khác nhau tùy thuộc vào loại gói tin RTCP Thông thường, nhiều gói tin RTCP được đóng gói cùng nhau như một gói tin RTCP kép nằm trong một gói tin đơn của giao thức lớp dưới Điều này được kích hoạt bởi trường length trong tiêu đề cố định của mỗi gói RTCP

- Port: Đây là khái niệm trừu tượng mà các giao thức truyền tải sử dụng để phân

biệt các phiên truyền Với giao thức TCP/IP nó là số nguyên dương 16 bit Khái niệm

Port tương đương với khái niệm TSEL (transport selectors) trong mô hình OSI RTP dựa trên các cơ chế tương tự sự phân cổng được cung cấp bởi giao thức lớp dưới để gửi đồng thời các gói dữ liệu RTP và gói tin điều khiển RTCP trong mỗi phiên truyền

- Transport address: Địa chỉ giao vận Địa chỉ này phục vụ cho việc vận chuyển

dữ liệu Nó là sự kết hợp giữa địa chỉ mạng và các cổng được định nghĩa ở tầng giao vận Ví dụ như sự kết hợp giữa địa chỉ IP với một cổng UDP nhất định Các gói tin sẽ được truyền từ địa chỉ giao vận nguồn tới địa chỉ giao vận đích

- RTP session: Một phiên RTP có thể có sự tham gia của một tập các thành viên

cùng trao đổi thông tin Mỗi thành viên được xác định dựa trên cặp địa chỉ nguồn (một dùng truyền gói RTP, một dùng truyền gói RCTP) Cặp địa chỉ đích có thể là chung cho tất cả các thành viên còn lại (trong trường hợp truyền đa điểm multicast ) hoặc riêng biệt cho từng thành viên(trong trường hợp truyền điểm - điểm unicast) Trong một phiên đa phương tiện, mỗi tín hiệu thành phần được mang trong một phiên RTP riêng biệt với gói RTCP của riêng nó Các phiên RTP phức tạp được phân biệt bởi sự khác nhau của cặp số hiệu cổng và/hoặc khác nhau giữa địa chỉ đa hướng

- Synchronization source (SSRC): Nguồn phát dòng các gói RTP, được định danh

bởi 32-bit SSRC trong phần header của gói RTP Nó có giá trị hoàn toàn độc lập với địa chỉ mạng Các gói dữ liệu được phát từ một nguồn được gắn thời gian và số thứ tự một cách đồng bộ Do đó phía nhận sẽ dựa trên SSRC để khôi phục lại tín hiệu Ví dụ

về các nguồn đồng bộ bao gồm người gửi một dòng các gói tin bắt nguồn từ một nguồn tín hiệu như một máy thu hoặc một máy quay, hoặc một bộ trộn RTP Một nguồn tin đồng bộ có thể thay đổi định dạng dữ liệu của nó, ví dụ như mã hóa âm thanh, qua thời gian Giá trị của định danh SSRC của mỗi nguồn RTP là đơn trị trên toàn mạng, nó được khởi tạo một cách ngẫu nhiên trong một phiên RTP cụ thể (xem mục 8) Một người tham gia không cần phải sử dụng cùng một định danh SSRC cho tất cả các RTP buổi trong một phiên họp đa phương tiện; các ràng buộc của SSRC định danh được cung cấp qua RTCP (xem Phần 6.4.1) Nếu một người tham gia tạo ra nhiều dòng trong

một phiên RTP, cho ví dụ từ máy quay video, mỗi dòng phải được xác định là một SSRC khác nhau

- Tổng hợp nguồn (CSRC): Khi dòng các gói RTP được tổng hợp nhờ bộ Mixer

Các Mixer sẽ chèn một danh sách CSRC chứa các định danh SSRC của các nguồn đã được tổng hợp vào trong tiêu đề của gói RTP đó Việc này giúp cho bên nhận có thể dễ dàng phân tách địa chỉ SSRC tương ứng với từng nguồn gửi.Ví dụ một ứng dụng hội nghị audio, ở đó một máy trộn biểu thị tất cả các người nói chuyện có bài phát biểu được kết hợp để tạo các gói tin gửi đi, cho phép nhận để chỉ ra người nói hiện tại, mặc

dù tất cả các gói tin audio có các định danh SSRC giống nhau (của mixer đó)

- Hệ thống cuối: Mỗi ứng dụng mà sinh ra dữ liệu để truyền đi trong những gói

RTP, hoặc nhận những dữ liệu này để xử lý được gọi là hệ thống cuối RTP (End

system) Một hệ thống cuối này có thể hoạt động như một hay nhiều nguồn đồng bộ trong một phiên RTP, tuỳ thuộc vào số định danh SSRC mà nó sử dụng nhưng thường thì chỉ có một

- Mixer: Một hệ thống trung gian mà các gói tin RTP nhận được từ một hoặc

nhiều nguồn, có thể thay đổi các định dạng dữ liệu, kết hợp các gói tin theo cách một

số cách nào đó để tạo thành một gói tin RTP mới sau đó chuyển tiếp Khoảng thời gian giữa các nguồn vào nói chung không được đồng bộ, các máy trộn sẽ điều chỉnh thời gian giữa các dòng và tạo ra thời gian riêng của nó cho dòng kết hợp.Vì vậy, tất cả các gói dữ liệu có nguồn gốc từ máy trộn sẽ được xác định là được đồng bộ hóa

- Thiết bị truyền tin (Translator): Đây là một hệ thống trung gian có nhiệm vụ

chuyển tiếp các gói RTP mà không làm thay đổi giá trị của SSRC.Ví dụ về các thiết bị truyền tin bao gồm các thiết bị chuyển đổi mã hóa mà không trộn, sự tái tạo từ đa hướng tới đơn hướng, và ứng dụng các mức độ của bộ lọc trong các bức tường lửa

- Giám sát (Monitor): Một ứng dụng nhận các gói tin RTCP gửi bởi người tham

gia trong một phiên RTP, đặc biệt là việc tiếp nhận báo cáo, và ước tính chất lượng hiện tại của dịch vụ kiểm tra, chẩn đoán lỗi và thống kê dài hạn Chức năng giám sát

giống như xây dựng một hay nhiều ứng dụng tham gia trong phiên làm việc, nhưng cũng có thể là một ứng dụng riêng biệt mà không tham gia và không gửi hoặc nhận các gói dữ liệu RTP Chúng được gọi là giám sát của bên thứ ba

- Cách thức không RTP: Giao thức và kỹ thuật có thể cần thiết trong việc thêm

vào RTP để cung cấp một dịch vụ có thể sử dụng Đặc biệt, đối với hội nghị đa phương tiện, một ứng dụng điều khiển hội nghị có thể kiểm soát phân phối các địa chỉ đa hướng và các khóa cho sự mã hóa, thương lượng các thuật toán mã hóa được sử dụng,

và xác định các ánh xạ linh động giữa kiểu RTP payload và định dạng payload mà chúng đại diện cho các định dạng đó mà không có một định nghĩa trước cho giá trị Payload Đối với các ứng dụng đơn giản như thư điện tử hoặc một cơ sở dữ liệu hội nghị cũng có thể được sử dụng

1.4 Thứ tự byte, sắp xếp, và định dạng thời gian

Tất cả các trường số nguyên được lưu trữ trong các byte có thứ tự, nghĩa là hầu hết byte đầu là byte (octet) có ý nghĩa cao nhất Byte có thứ tự này thường được gọi là đầu

to (big-endian) Thứ tự truyền được miêu tả chi tiết trong [4].Thông thường là các số thập phân (cơ số 10) Tất cả các dữ liệu tiêu đề được sắp xếp theo chiều dài tự nhiên của nó, nói cách khác các trường 16-bit thì được sắp xếp theo độ lệch chẵn, các trường 32-bit được sắp xếp theo các độ lệch chia hết cho bốn Các octet được xem như là đệm

có giá trị bằng không

Thời gian Wallclock (thời gian tuyệt đối) được biểu diễn bằng cách sử dụng cấu trúc nhãn thời gian (timestamp) của giao thức Network Time Protocol (NTP) tức là trong vài giây tương đối so với 0h UTC ngày 01 tháng 1 năm 1900 [5] Timestamp (NTP) là một số không dấu 64-bit có phần nguyên trong 32 bit đầu tiên và phần thập phân trong 32 bit cuối Trong một số trường, chỉ có 32 bit giữa được sử dụng, khi đó phần nguyên trong 16 bit cao và phần thập phân trong 16 bit thấp 16 bit cao của phần

số nguyên phải được xác định độc lập

Chương 2 CÁC GIAO THỨC TRUYỀN THỜI GIAN THỰC

Trong môi trường truyền thông trên mạng hiện nay, việc truyền các tín hiệu được truyền đều được dựa trên các chuẩn kỹ thuật khác nhau Các nghi thức truyền thông thời gian thực cũng là một trong số các chuẩn kỹ thuật được đưa ra cho hạ tầng mạng hiện nay nhằm truyền các gói tin trong thời gian thực, phục vụ cho các ứng dụng truyền thông đa phương tiện trực tuyến như hội nghị truyền hình (video conference), hội nghị thoại (voice conference) v.v… Trong chương này, chúng ta sẽ cùng đi sâu tìm hiểu rõ về hai chuẩn kỹ thuật tryền thông thời gian thực hiện nay là RTP và RTCP

2.1 Giao thức truyền dữ liệu RTP

2.1.1 Trường tiêu đề cố định RTP

Định dạng phần header của gói RTP như sau :

Hình 2.1 Định dạng phần header của gói RTP

Trong phần tiêu đề của gói RTP, 12 byte đầu tiên đều có trong mọi gói RTP trong khi đó phần CSRC (contributing source identifiers) chỉ có khi nó được thêm bởi thiết bị trộn (mixer) Các trường có nghĩa như sau:

- Version (V): 2 bits Phiên bản của RTP mới nhất là 2

- Padding (P): 1 bit Nếu trường này được thiết lập thì gói sẽ chứa một hay nhiều

các byte thêm tại cuối header của gói mà không phải là thành phần của dữ liệu của gói Byte cuối cùng của phần thêm này chứa số đếm các byte sẽ bị bỏ qua Các byte được

thêm vào bởi một vài thuật toán mã hoá với kích thước khối cố định hoặc để mang một vài gói RTP trong một đơn vị dữ liệu ở giao thức ở tầng thấp hơn

- eXtension (X): 1 bit Nếu trường này được đặt thì một header cố định theo sau bởi

một header mở rộng

- CSRC count (CC): 4 bits Số lượng các định danh CSRC được thêm vào sau phần

tiêu đề cố định Số này nhiều hơn một nếu dữ liệu trong gói RTP chứa dữ liệu đến từ nhiều nguồn

- Marker (M): 1 bit Bit này được dùng với mục đích báo hiệu Ta có thể dùng nó

để làm sự kiện báo hiệu khung trong trường hợp ta truyền các gói tin thành dòng Bit này có thể được sử dụng hoặc không Nếu không sử dụng ta có thể thay đổi số lượng bit trong trường payload type

- Payload Type (PT): 7 bits Xác định định dạng của gói dữ liệu RTP để chọn lựa

các ứng dụng phù hợp Giá trị của phần định dạng tải này có thể cố định trong một phiên RTP nếu ta sử dụng phương pháp mã hoá tĩnh Nó sẽ có giá trị biến đổi nếu như trong phiên RTP đó ta sử dụng cơ chế định dạng động Một nguồn RTP có thể thay đổi định dạng tải trong một phiên truyền, tuy nhiên ta không nên dùng 1 phiên RTP để truyền đồng thời các luồng media có định dạng khác nhau, theo khuyến cáo của RFC1890 Về phía nhận, nếu nhận được gói RTP có định dạng tải mà nó không hiểu, gói này sẽ phải được bỏ qua

- Sequence Number: 16 bits Số thứ tự được đánh tăng dần một khi mỗi gói dữ liệu

RTP được gửi đi và được nơi nhận dùng để phát hiện gói bị mất và khôi phục thứ tự các gói Giá trị ban đầu được chọn ngẫu nhiên nhằm tăng tính bảo mật bởi nó có thể được kết hợp với khóa mã

- Timestamp: 32 bits Nhãn thời gian được tính theo thời điểm lấy mẫu của byte

đầu tiên trong dữ liệu của gói RTP được dùng để đồng bộ và tính toán tắc nghẽn Khoảng lấy mẫu cần được lấy từ đồng hồ có nhịp chuẩn và có độ phân giải phải đủ để cho độ chính xác đồng bộ cần thiết và để đo được độ tắc nghẽn mạng (1 tick cho 1

frame video có lẽ là không đủ) Tần số đồng hồ phụ thuộc vào dạng dữ liệu được gửi đi

và được xác định cố định trong profile, trong đặc tả định dạng payload hoặc được xác định linh động Nếu các gói RTP được sinh theo chu kỳ thì các khoảng lấy mẫu danh nghĩa lấy từ tần số lấy mẫu không cần đọc đồng hồ hệ thống Ví dụ đối với audio có tốc độ cố định thì đồng hồ lấy nhãn thời gian sẽ tăng một lần đối với mỗi chu kỳ lấy mẫu Nếu ứng dụng audio đọc một khối có 160 chu kỳ lấy mẫu từ thiết bị đầu vào, nhãn thời gian sẽ tăng lên 160 cho mỗi khối bất kể khối có được truyền đi không hay

đó chỉ là khoảng lặng Giá trị ban đầu của nhãn thời gian được chọn ngẫu nhiên Một vài gói RTP liên tiếp sẽ có thể có cùng nhãn thời gian do chúng được sinh ra một cách đồng thời ví dụ như chúng thuộc cùng một frame

- SSRC, Synchronization source: 32 bits Trường này dùng cho việc định danh

một nguồn đồng bộ, nó không phụ thuộc vào địa chỉ tầng mạng Giá trị của nó được chọn ngẫu nhiên (có kiểm tra xung đột) để phân biệt các nguồn đồng bộ trong cùng một phiên RTP Nó xác định nơi mà dữ liệu được hợp nhất hoặc nguồn của dữ liệu nếu chỉ có một nguồn Nếu một nguồn thay đổi địa chỉ ở tầng giao vận thì nó cũng cần chọn một SSRC mới để tránh trường hợp xung đột Một người tham gia không thể dùng cùng một định danh SSRC cho tất cả các phiên RTP, việc kết nối dùng định danh SSRC do RTCP cung cấp Nếu một thành viên có thể sinh ra nhiều luồng dữ liệu trong một phiên RTP, ví dụ như một thành viên sinh ra nhiều luồng video trong một phiên RTP, thì mỗi luồng dữ liệu cần phải có một định danh SSRC riêng

- CSRC, Contributing source list: Danh sách này được bổ sung bởi các Mixer chứa

các định danh nguồn SSRC và có từ 0 tới 15 phần tử, 32 bit cho mỗi phần tử Một danh sách gồm 15 thành phần CSRC xác định các nguồn tạo ra nội dung phần tải chứa trong gói đó Số lượng được xác định bởi trường CC Nếu có nhiều hơn 16 nguồn phân phối thì chỉ 16 nguồn được xác định, các nguồn còn lại hoặc sẽ bị loại bỏ hoặc sử dụng cơ chế gán vòng Ví dụ đối với gói audio, các định danh SSRC của tất cả các nguồn được trộn với nhau để tạo ra một gói liệt kê, cho phép xác định đúng người nói tại nơi nhận

2.1.2 Phiên dồn kênh RTP

Đối với các giao thức xử lý có hiệu quả, số lượng các điểm dồn kênh nên được giảm thiểu, như mô tả trong nguyên lý thiết kế xử lý lớp đầy đủ [1] Trong RTP, bộ dồn kênh được cung cấp bởi địa chỉ vận chuyển đích (địa chỉ mạng và số cổng) để xác định một phiên RTP Ví dụ, trong một hội nghị qua điện thoại bao gồm audio và video được mã hóa riêng biệt nhau, mỗi phương tiện phải được tiến hành trong một phiên RTP riêng biệt với địa chỉ vận tải đích riêng Không mong muốn rằng audio và video được thực hiện trong cùng một phiên RTP và phân kênh dựa trên loại payload hoặc trường SSRC Việc chèn các gói với các loại payload khác nhau nhưng bằng cách sử dụng cùng một SSRC sẽ nảy sinh một số vấn đề:

a Phía nhận có thể hiểu đây là hai luồng thoại sử dụng cùng một phiên truyền, với

cùng giá trị SSRC Một luồng sẽ được coi là thay đổi cách mã hoá (dựa trên trường payload type) Nhưng nó không thể phân biệt được luồng nào là gốc và luồng nào có thay đổi cách mã hoá

b Một SSRC được định nghĩa để xác định một khoảng thời gian và khoảng đánh

các số thứ tự duy nhất Chèn nhiều loại payload sẽ yêu cầu nhiều khoảng thời gian khác nhau nếu tốc độ các đồng hồ của các phương tiện truyền thông khác nhau và sẽ yêu cầu nhiều dãy các số thứ tự khác nhau để báo các loại payload bị mất gói tin

c Người gửi RTCP và báo nhận (xem phần 6.3) có thể chỉ mô tả một khoảng thời

gian và khoảng số thứ tự cho mỗi SSRC nhưng không mang thông tin về kiểu trường payload

d Một thiết bị trộn RTP sẽ không thể kết hợp xen kẽ dòng tin không tương thích

vào trong cùng một dòng

e Truyền đa phương tiện trong một phiên RTP ngăn cản việc thực hiện tìm đường

đối với từng loại dữ liệu ch phù hợp với tài nguyên mạng Không thể cho người dùng lựa chọn việc chỉ nhận một loại dữ liệu (hình hoặc tiếng) Mà điều này khá cần thiết,

khi một thành viên tham gia hội thảo đang sử dụng đường truyền tốc độ thấp, họ cần chọn giải pháp chỉ chấp nhận tín hiệu âm thanh

2.1.3 Sự thay đổi của tiêu đề RTP trong một số trường hợp

Tiêu đề các gói tin dữ liệu RTP hiện được coi là hoàn chỉnh cho tập hợp các chức năng cần thiết trong ứng dụng phổ biến trên tất cả các lớp RTP có thể hỗ trợ Tuy nhiên, theo nguyên lý thiết kế ALF, tiêu đề có thể hoàn toàn thích hợp thông qua thay đổi hoặc thêm sửa đổi bổ sung quy định tại một đặc điểm kỹ thuật

o Bit đánh dấu (M) và kiểu trường payload mang các thông tin đặc trưng cho từng ứng dụng Các trường này được đặt trong phần tiêu đề cố định, trong khi đó để dùng được cho rất nhiều ứng dụng khác nhau, đòi hỏi chúng phải có độ dài tới 32 Bit Do vậy, những trường này có thể phải được định nghĩa lại trong các trường đánh dấu mở rộng cho phù hợp với các yêu cầu khác nhau, ví dụ với một điểm đánh dấu nhiều hơn hoặc ít hơn 1bit Nếu có bất kỳ bit đánh dấu, thì nên được đặt tại bit quan trọng nhất của octet để có thể giám sát sự tương quan giữa các gói tin mất nguyên mẫu và bit đánh dấu.Tất nhiên, khi ta thêm các byte đánh dấu này thì nên để 1 bit báo hiệu để có thể phân biệt giữa trường hợp có mở rộng và không mở rộng Bit này sẽ nằm trong phần tiêu đề cố định

o Một số thông tin thêm được xác định phụ thuộc vào từng loại định dạng của dữ liệu Ví dụ, trong trường hợp mã hoá tín hiệu Video, phần thông tin thêm vào nên được đặt trong phần tải (payload) của gói tin Nó có thể được đặt ở phần đầu tiên của tải hoặc cũng có thể đặt ở một vị trí nào đó trong phần tải mà đã được mặc định trước

o Một số lớp ứng dụng đặc biệt, các chức năng cài đặt thêm không phụ thuộc vào loại định dạng tải Khi đó phần thông tin thêm vào nên là cố định và đặt ngay sau phần tiêu đề cố định Điều này giúp cho các ứng dụng có thể nhanh chóng và trực tiếp xử lý các thông tin trong trường được thêm Trong khi đó các vẫn thực hiện đồng thời việc phân tích 12 octet tiêu đề cố định

2.1.4 RTP Header Extension – Tiêu đề RTP mở rộng

Một cơ chế mở rộng được cung cấp cho phép việc cài đặt các hàm đơn lẻ hoạt động độc lập với loại định dạng của tải và được yêu cầu bổ sung thông tin trong tiêu đề của gói RTP Cơ chế được thiết kế sao cho phần tiêu đề mở rộng là trong suốt đối với các hàm không được cài đặt cơ chế mở rộng Chú ý rằng, phần mở rộng này chỉ dành cho một số người người dùng, khi mà đa phần người sử dụng đều dùng đến thành phần này thì nó sẽ được đưa vào phần tiêu đề cố định.Ví dụ, phần thông tin mở rộng cụ thể được đưa vào các tiêu đề cố định là ít gây ảnh hưởng đến quá trình xử lý vì nó không phụ thuộc vào vị trí thay đổi Thông tin bổ sung cần thiết cho một tải trọng ngoại lệ không nên sử dụng tiêu đề mở rộng này, nhưng cần được tiến hành trong phần payload của gói tin

Để thực hiện những yêu cầu trên, phần tiêu đề mở rộng được thiết kế với 16-bit đầu tiên được dùng với cho việc nhận biết hoặc dùng để truyền tham số

2.2 Giao thức điều khiển RTCP

RTCP là giao thức điều khiển các gói tin RTP nhằm đảm bảo cho việc truyền các gói dữ liệu tới tất cả những người tham gia trong phiên làm việc, sử dụng cùng một cơ chế phân phối các gói dữ liệu Các giao thức cơ bản ở lớp dưới phải thực hiện việc ghép kênh và kiểm soát các gói dữ liệu như việc sử dụng số cổng riêng biệt của UDP RTCP có bốn chức năng cơ bản sau:

a Chức năng chính là cung cấp các thông tin phản hồi về chất lượng của

đường truyền dữ liệu Đây là một phần không thể thiếu được với vai trò là một giao thức giao vận, nó liên quan đến các hàm điều khiển luồng (flow control) và kiểm soát

sự tắc nghẽn (congestion control) Chức năng này được thực hiện dựa trên các bản tin thông báo từ phía người gửi và phía người nhận Thông tin hồi đáp có thể được sử dụng trực tiếp cho việc điều khiển việc thay đổi phương pháp mã hoá (adaptive encoding) Trong trường hợp truyền IP multicasrt, thì các thông tin hồi tiếp từ phía người nhận là tối quan trọng cho việc chuẩn đoán các sự cố xảy ra trong quá trình truyền Ngoài ra, việc các bản tin phản hồi từ phía người nhận đến tất cả các thành viên khác giúp cho mỗi thành viên có thể quan sát lỗi và đánh giá xem lỗi xảy ra với mình là lỗi cục bộ hay là lỗi trên toàn mạng Với cơ chế truyền IP multicast, có thể cần đến một thực thể đóng vai trò của nhà cung cấp dịch vụ, nhận các thông tin phản hồi Thực thể này đóng vai trò bên thứ 3, quan sát và phân tích các vấn đề xảy ra Chức năng phản hồi này được thực hiện bởi người gửi RTCP và người nhận báo cáo và được mô tả trong phần 6.3

b RTCP mang một thông tin định danh ở lớp vận chuyển gọi là CNAME

(canonical name) Thông tin này giúp ta định danh một nguồn phát RTP(tương ứng với

1 thành viên tham gia hội thảo) Trong 1 phiên truyền RTP, khi giá trị của SSRC của phía phát thay đổi có thể gây ra xung đột sẽ đòi hỏi thiết lập lại kết nối Do đó phía

nhận cần sử dụng CNAME để duy trì kết nối tới từng thành viên Ngoài ra, việc CNAME có thể xác định được từng thành viên, giúp cho bên nhận có thể phân chia những luồng tin nhận được thành từng tập tương ứng với từng người gửi Ví dụ, xác định một cặp tín hiệu video/audieo của cùng một người gửi (vì 2 luồng này có định danh SSRC khác nhau) Điều này giúp cho việc đồng bộ tín hiệu audio với tín hiệu video Việc đồng bộ nội cho từng luồng tín hiệu (video hoặc audio) được thực hiện dựa trên các thông tin về số thứ tự, nhãn thời gian gắn trên các gói RTP và RTCP của bên gửi

c Hai chức năng trên đòi hỏi tất cả các thành viên đều phải gửi đi các gói RTCP

Do vậy, trong trường hợp có một số lượng lớn người cùng tham gia hội thảo, đòi hỏi phải có sự điều chỉnh tốc độ cho phù hợp để dành tài nguyên cho các gói RTP Dựa vào việc mỗi thành viên gửi gói tin điều khiển của mình tới tất cả các thành viên khác, mỗi thành viên có thể độc lập quan sát số lượng người tham gia Con số này sẽ được dùng để tính toán tốc độ truyền Việc tính toán tốc độ được nêu cụ thể tại phần 6.2

d Chức năng tuỳ chọn Cho phép tuỳ chọn các chức năng, giúp giảm tối đa các

việc truyền các thông tin điều khiển Điều này rất hữu ích trong các phiên truyền kiểm soát lỏng lẻo "loosely controlled", các thành viên có thể tham gia và rời bỏ mà không điều khiển quan hệ tới các thành viên khác Ví dụ, một thành viên chỉ cần nghe các thông tin chuyển tới, như một RTCP Server Nó có thể sử dụng một kênh thích hợp kết nối với tất cả các thành viên, nhưng nó không cần sử dụng tất cả các chức năng của một ứng dụng

Các chức năng 1-3 đầu nên được cài đặt trong mọi môi trường hoạt động, đặc biệt

là trong môi trường IP multicast Những nhà thiết kế ứng dụng RTP nên tránh các cơ chế mà chỉ sử dụng được trong môi trường unicast, không tương thích với số người dùng lớn Việc truyền tải RTCP có thể được điều khiển khác nhau giữa người nhận và người gửi, trong trường hợp sử dụng đường truyền đơn hướng

2.2.1 RTCP Packet Format: Định dạng gói tin RTCP

Một số loại gói tin RTCP tương ứng với những loại thông tin điều khiển khác nhau:

- SR (Sender report): Bản tin phía gửi, dùng để thông tin về trạng thái truyền và

nhận của phía gửi tin

- RR (Receiver report): Bản tin người nhận, dùng để thông tin về trạng thái nhận

của phía nhận tin

- SDES (Source description items): Thông tin mô các về nguồn gửi, bao gồm cả

CNAME

- BYE: Dùng khi thành viên nào đó thoát khỏi hội thảo

- APP (Application specific functions): Xác định các chức năng phụ thuộc vào

từng ứng dụng cụ thể

Mỗi gói tin RTCP được bắt đầu với phần tiêu đề cố định tương tự như của gói tin RTP, tiếp theo là các thành phần cấu trúc, chúng có thể có chiều dài biến đổi tuỳ thuộc vào loại của gói tin, nhưng phải giới hạn trong 32-bit

Sự chuẩn hoá và các trường có chiều dài cố định trong mỗi gói RTCP làm cho chúng có thể được lưu trong ngăn xếp Nhiều gói RTCP có thể được kết nối với nhau thành gói ghép (compound packet ), mà không cần sử dụng dấu phân cách giữa các gói RTCP, khi đưa chúng xuống đóng gói ở các lớp dưới Ví dụ như đóng trong các gói UDP

Mỗi gói RTCP trong gói ghép có thể được xử lý một cách độc lập, không cần dựa vào thứ tự hoặc sự kết hợp giữa các gói Tuy nhiên để thực hiện được điều này thì ta phải thiết lập một số ràng buộc:

- Các thông báo trạng thái (trong RS hoặc RR) phải được gửi đi định một cách thường xuyên nhất có thể, điều này cho phép để cập nhật các thông tin trạng thái Trong mỗi gói ghép RTCP, phải có 1 gói mang bản tin (RS hoặc RR)

- Một người nhận mới cần nhận được giá trị CNAME càng sớm càng tốt Điều này giúp cho việc định danh nguồn gửi, từ đó có thể thực hiện đồng bộ giữa các thành

phần (video/audio) Do vậy trong mỗi gói ghép RTCP cần phải có gói SDES chứa CNAME

- Số các kiểu gói có thể chứa trong phần đầu tiên của gói ghép Để giới hạn sự gia tăng của các hằng số định kiểu, giá trị này được chứa trong 2 Byte

Mỗi gói tin RTCP phải được gửi trong một gói ghép chứa được ít nhất 2 gói riêng lẻ được chỉ ra sau đây:

- Encryption prefix: tiền tố của phần mã mật

Trường này chỉ được sử dụng khi gói tin được mã hoá theo phương thức mã mật được đề cập ở phần sau Đây là một chuỗi 32-bit truyền ngẫu nhiên được thêm vào đầu mỗi gói ghép Nếu trường đệm (padding) được truyền theo mã mật thì nó sẽ được thêm vào ở gói cuối cùng trong gói ghép

- SR hoặc RR:

Gói RTCP đầu tiên trong gói ghép luôn là gói report packet, để xác định hiệu lực của phần header Sự kiện này phải luôn được đảm bảo và được mô tả trong phụ lục A.2 Nếu trong trường hợp không có dữ liệu được gửi hay nhận thì RR rỗng sẽ được gửi, thậm chí trong trường hợp trong gói ghép chỉ chứa 1 gói BYTE

- Additional RRs:

Khi số nguồn gửi các thông tin trạng thái vượt quá 31 (giá trị tối đa mà SR hoặc

RR có thể chứa), khi đó gói RR sẽ được thêm vào sau gói report packet khởi tạo

- SDES:

Một gói SDES có chứa CNAME phải được thêm vào mỗi gói RTCP ghép Còn một số các thông số về nguồn phát khác có thể được lựa chọn, tuỳ thuộc vào từng ứng dụng cụ thể, vấn đề bắt buộc về băng thông (xem 6.2.2)

- BYE or APP:

Một số gói RTCP loại khác có thể được đặt ở các vị trí bất kỳ Ngoại trừ gói BYTE nên nằm ở vị trí cuối cùng của gói tin gửi đi, với các giá trị SSRC/CSRC

Hình 2.3 ghép các gói RTCP vào gói UDP

Thông thường, các bộ translators và mixers sẽ xử lý từng gói RTCP riêng lẻ từ các nguồn khác nhau, sau đó chuyển tiếp trong một gói ghép Nếu gói ghép này có kích thước vượt quá giá trị của một đơn vị truyền tải (maximum transmission unit), khi đó

nó sẽ được phân thành các gói ghép nhỏ hơn để có thể tryền được trong những gói của giao thức lớp dưới Nhưng chú ý rằng, mỗi gói ghép sau khi chia vẫn phải đảm bảo được bắt đầu bởi một gói SR hoặc RR

Nên cài đặt cơ chế tự động bỏ qua một gói RTCP mà ta không xác định được loại Cũng cần cài đặt thêm cơ chế để một loại gói RTCP mới có thể được đăng ký với IANA (the Internet Assigned Numbers Authority)

2.2.2 Khoảng thời gian truyền các gói RTCP

Nếu mã hóa: số nguyên ngẫu nhiên 32-bit

Hình 2.4 ghép các gói RTCP vào gói #: SSRC/CSRC UDP

[ -packet -] [ -packet -] [ packet ] receiver reports chunk chunk

item item item item

| R[SR | # sender #site#site] [SDES | # CNAME PHONE | #CNAME LOC] [BYE##why]

| R[ | # report # 1 # 1 ] [ | # CNAME PHONE | # ] [ ## ]

| R[ | # report # 1 # 1 ] [ | # CNAME PHONE | # ] [ ## ]

| R[ | # report # 1 # 1 ] [ | # CNAME PHONE | # ] [ ## ]

| UDP packet (compound packet) |

RTP được thiết kế để cho phép một ứng dụng có thể tự co giãn kích cỡ phiên truyền

từ vài thành viên đến hàng nghìn thành viên Ví dụ, trong cuộc hội thảo thoại, lưu lượng dữ liệu vốn đã tự giới hạn Bởi vì trong cùng một thời điểm, chỉ có 1 hoặc 2 người cùng phát biểu Do vậy đối với việc truyền multicast, tốc độ dữ liệu để duy trì một liên kết là tương đối ổn định, độc lập so với số thành viên tham gia

Tuy vậy, lưu lượng dùng cho việc điều khiển thì không được hạn chế như vậy Nếu các bản báo nhận của mỗi thành viên được duy trì ở một tốc độ không đổi, thì lưu lượng của luồng điều khiển sẽ tăng tỉ lệ với số thành viên tham gia Do đó, tốc độ phát phải được thay đổi động dựa trên tính toán khoảng thời gian phát các gói RTCP liên tiếp

Với mỗi phiên truyền giả sử rằng lưu lượng dữ liệu chịu ảnh hưởng của một tập các giới hạn, gọi là băng thông của phiên truyền (session bandwidth) Băng thông có thể được cung cấp và bị giới hạn bởi nhà cung cấp dịch vụ Nếu không có sự giới hạn của nhà cung cấp thì sẽ có một số ràng buộc, phụ thuộc vào môi trường mạng Điều này sẽ giới hạn số phiên truyền tối đa có thể chấp nhận Giá trị này có thể được hiểu như là session bandwidth

Việc chọn băng thông này có thể dựa trên yếu tố giá thành hoặc kinh nghiệm của nhà thiết kế cho phiên làm việc Thông thường giá trị của nó sẽ phụ thuộc vào kiểu định dạng của dữ liệu Các thông số của session bandwidth là cố định, được quyết định bởi sự quản lý phiên của ứng dụng Tuy nhiên, các ứng dụng có thể thiết lập một giá trị mặc định, tương ứng với dải thông dữ liệu (data bandwidth ) của từng người gửi, tương ứng với từng cách mã hoá dữ liệu Tất cả các thành viên đều phải sử dụng cùng một giá trị băng thông của phiên, do đó khoảng thời gian phát gói RTCP sẽ được tính giống nhau

Việc tính toán băng thông cho lưu lượng dữ liệu và lưu lượng thông tin điều khiển, được thực hiện bởi giao thức ở lớp mạng và lớp giao vận (ví dụ như giao thức UDP hay IP)

Đường truyền điều khiển nên được giới hạn theo một phần đủ nhỏ và được tính toán trước theo giới hạn băng thông phiên để chức năng chính của tầng giao vận là vận chuyển dữ liệu không bị ảnh hưởng, đường truyền điều khiển có thể được tính toán trước và đưa tới một giao thức dành riêng tài nguyên và mỗi thành viên có thể tính toán độc lập băng thông chia sẻ Theo đó thì tỷ lệ băng thông dùng cho RTCP trên băng thông phiên nên cố định là 5% Khi sử dụng giá trị này hay giá trị cố định nào khác trong tính toán khoảng thời gian thì không là vấn đề quyết định Mọi người tham gia trong một phiên phải sử dụng chung một giá trị và giá trị đó sẽ được tính toán Vì vậy những hằng số này nên cố định trong mỗi phiên cụ thể

Giải thuật tính toán khoảng thời gian giữa việc gửi các gói RTCP để chia lượng băng thông điều khiển cho phép giữa các thành viên Nó cho phép một ứng dụng trả lời nhanh đối với các phiên nhỏ như có thể xác định các thành viên trong phiên, và tự động thay đổi theo các phiên lớn Giải thuật được dựa trên các đặc điểm sau:

▪ Những người gửi được chiếm ít nhất ¼ băng thông điều khiển để trong các phiên

có số lượng người nhận lớn nhưng có số lượng người gửi nhỏ thì các thành viên mới sẽ nhận được CNAME của người gửi nhanh hơn

▪ Độ trễ tính toán gửi các gói RTCP được yêu cầu là phải lớn hơn 5 giây để tránh các gói RTCP lớn hơn băng thông cho phép khi số lượng thành viên là nhỏ và để lưu lượng không theo luật số lớn

▪ Độ trễ giữa các gói RTCP được chọn ngẫu nhiên trong khoảng [0.5, 1.5] lần độ trễ tính toán để tránh sự đồng bộ không mong muốn của tất cả các thành viên Gói RTCP đầu tiên gửi sau khi kết nối tới một phiên bị trễ một khoảng thời gian ngẫu nhiên trong khoảng 1/2 khoảng thời gian RTCP tối thiểu trong trường hợp ứng dụng bắt đầu nhiều phiên cùng một lúc

▪ Ta liên tục ước lượng động giá trị trung bình của các gói tin RTCP ghép, bao gồm

cả các gói phía nhận và các gói phía gửi Giá trị này được dùng để tự động thay đổi lượng thông tin điều khiển được mang đi

Thuật toán này có thể được sử dụng cho các phiên trong đó tất cả người tham gia được được phép gửi Trong trường hợp đó, tham số băng thông của phiên tỉ lệ với số người tham gia và băng thông RTCP là 5% của số đó

a Duy trì số lượng thành viên tham gia phiên

Việc tính toán khoảng cách giữa các gói RTCP được gửi dựa trên sự ước lượng số thành viên tham gia trong phiên truyền Một thành viên mới sẽ được thêm vào biến đếm khi họ được nghe Khi đó mỗi thành viên sẽ được thêm vào bảng được đánh số bởi định danh SSRC hoặc CSRC (xem 8.2) để dùng cho việc theo dõi Các thành viên mới sẽ chính thức được thừa nhận khi nhận được gói tin có chứa giá trị SSRC mới Các thành viên này sẽ bị loại khỏi bảng khi gói RTCP BYE có kèm theo định danh SSRC tương ứng mà họ nhận được

Một thành viên có thể đánh dấu một địa chỉ không hoạt động hoặc loại bỏ nó nếu không hợp lý khi không nhận được gói RTP hoặc RTCP trong một số nhỏ lần nhận báo cáo RTCP (đề nghị là 5) Điều này cung cấp một cách hiệu quả việc chống mất gói tin Tất cả các thành viên phải tính toán sơ bộ khoảng thời gian chờ giữa các báo cáo RTCP

để hoạt động đúng

Khi một thành viên đã được coi là hợp lệ, sau đó nếu nó bị đánh dấu là trạng thái không hoạt động thì thành viên đó nên tiếp tục được giữ lại và được đếm trong tổng số thành viên chia sẻ băng thông RTCP trong một khoảng thời gian đủ dài để sự phân chia mạng kết thúc Điều này tránh được việc dùng băng thông quá mức do khoảng cách giữa các báo cáo RTCP quá nhỏ Khoảng thời gian này được đề nghị là 30 phút Lưu ý rằng giá trị này vẫn lớn hơn 5 lần giá trị lớn nhất của khoảng trễ dự kiến giữa các báo cáo RTCP là 2-5 phút

Để tránh trường hợp một gói tin nào đó đến sau gói BYTE có thể tạo ra địa chỉ mới Một thành viên khi nhận được gói tin BYTE sẽ đánh dấu lại sự nhận được đó và sẽ xoá địa chỉ SSRC tương ứng sau một khoảng thời gian nào đó

b Phân bổ băng thông mô tả nguồn

Các thành phần miêu tả nguồn (SDES), ngoài thành phần chính CNAME còn có các thành phần khác như NAME (tên riêng) và EMAIL (địa chỉ email) Ngoài ra phần thông tin thêm còn cung cấp phương tiện để định nghĩa các loại gói RTCP mới cho từng ứng dụng cụ thể Các ứng dụng cần chú ý đến sự chiếm băng thông điều khiển của các thông tin thêm này vì nó sẽ làm giảm tốc độ mà các báo nhận và CNAME được gửi

do đó làm giảm hiệu năng của giao thức RTP Theo đó không nên có quá 20% băng thông dành cho RTCP của một thành viên được dùng để truyền các thông tin thêm này Không phải các thành phần SDES đều được thêm trong mọi ứng dụng, và chỉ được thêm vào trong ứng dụng tuỳ thuộc vào tỷ lệ băng thông được dành cho điều khiển

Ví dụ, một ứng dụng có thể được thiết kế để chỉ gửi 3 tham số: CNAME, NAME

và EMAIL NAME có lẽ được ưu tiên hơn EMAIL vì NAME có thể được hiện trên giao diện người dùng của ứng dụng trong khi đó EMAIL được xuất hiện khi có yêu cầu Trong mọi khoảng thời gian giữa hai lần gửi gói RTCP, một gói RR và một gói SDES chứa thành phần CNAME sẽ được gửi Đối với các phiên nhỏ có khoảng thời gian giữa hai lần gửi RTCP trung bình là 5 giây Khi đó cứ 3 chu kỳ (15 giây) sẽ có một gói mang thông tin bổ sung trong gói SDES Bảy trong 8 lần gửi là thành phần NAME và cứ 8 lần gửi đó (2 phút) có một thành phần EMAIL

Trong những ứng dụng đa luồng, ta có thể phối hợp giữa việc truyền thông tin qua một CNAME chung cho mỗi thành viên, bằng cách sử dụng các kết nối chéo thông qua CNAME Ví dụ, trong một ứng dụng hội thảo Multimedia, mỗi phiên RTP dùng truyền một thành phần, thông tin thêm trong SDES có thể được gửi trong một phiên RTP, còn các phiên kia sẽ chỉ truyền giá trị CNAME

2.2.3 Báo gửi và báo nhận

Trong giao thức RTP, các thành viên có thể trao đổi thông tin điều khiển thông qua các bản tin RTCP Các bản tin này có 2 dạng, phụ thuộc vào phía gửi đi là người gửi hay là người nhận dữ liệu Sự khác nhau giữa 2 loại bản tin này được xác định dựa trên

kiểu mã hoá, trong đó bản tin của người gửi sẽ gắn thêm 20-byte thông tin dùng cho người gửi tích cực (active senders)

Bản tin SR được gửi đi nếu có gói dữ liệu bất kỳ được gửi đi trong khoảng thời gian giữa 2 bản báo cáo cuối cùng được phát đi, nếu không bản tin RR sẽ được phát đi

Cả bản tin SR và RR đều có thể không mang thông tin (rỗng) hoặc mang thêm một vài khối báo nhận là một khối cho mỗi nguồn đồng bộ (synchronization sources) mà người nhận đã nhận các gói dữ liệu RTP từ khi có báo cáo cuối cùng Mỗi khối báo nhận cung cấp các thống kê về dữ liệu nhận được từ nguồn đồng bộ trong khối đó Có tối đa

31 khối báo nhận trong một gói SR hoặc RR tuy nhiên có thể thêm các gói RR và nên được đặt sau gói SR khởi tạo hoặc gói RR, để gửi các bản tin báo nhận cho các nguồn

mà nó nhận được thông tin trong khoảng thời gian kể từ khi gửi bản tin trước Khi có quá nhiều nguồn phát, sẽ dẫn đến số lượng các gói RR lớn Khi ta dồn tất cả các gói

RR này vào một gói RTCP ghép sẽ gây ra tràn MTU khi lan truyền trên mạng Khi đó, trong mỗi khoảng thời gian nhất định, ta chỉ có thể truyền đi một phần trong số các gói

RR này Việc truyền đi các tập con này được thực hiện luân phiên sao cho tất cả mọi nguồn đều có thể nhận được bản thông báo của mình

Người nhận RTP cung cấp các phản hồi về chất lượng nhận thông qua các gói báo cáo RTCP, các gói này có thể có định dạng vừa là các gói gửi vừa là các gói nhận tuỳ thuộc vào người nhận có đồng thời là người gửi hay không Chỉ có một sự khác biệt duy nhất giữa các báo gửi (SR) và các báo nhận (RR) đó là loại mã hóa gói, báo gửi chứa 20 byte thông tin người gửi để sử dụng bởi người gửi đang hoạt động Báo cáo

SR được gửi đi nếu máy đã gửi bất cứ gói dữ liệu trong khoảng thời gian kể từ khi máy gửi báo cáo cuối cùng hoặc báo cáo trước đó, nếu không thì báo cáo RR sẽ được gửi

a SR: Gói tin RTCP báo gửi

Đây là gói tin RTCP thông báo của người đang truyền dữ liệu phát đi Gói thông báo của bên gửi dữ liệu chứa 3 phần cố định, có thể được gắn thêm tới 4 phần

mở rộng (profile-specific extension) nếu nó được định nghĩa

Trước tiên ta xét đến cấu trúc của gói tin RS:

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1V=2 P RC PT=SR=200 Length

Header

SSRC của người gửi Nhãn thời gian NTP, từ quan trọng nhất Nhãn thời gian NTP, từ ít quan trọng nhất

Tỷ lệ mất gói Số gói tin mất tích lũy

Số thứ tự cao nhất đã nhận được interarrival jitter – Độ lệch về mặt thời gian của các gói tin RTP

………

Report

Block

2 profile-mở rộng riêng

Hình 2.5 Gói tin RTCP báo gửi

Phần đầu: đây là phần tiêu đề, chiếm chiều dài là 8 octets, bao gồm các trường:

- Version (V): 2 bits, dùng để xác định version của RTP (giá trị V trong các gói dữ liệu

RTP và gói RTCP đều có giá trị giống nhau) Trong trường hợp này V=2 (giá trị hiện nay của RTP đang được sử dụng)

- Padding (P): 1 bit Nếu giá trị này được đặt bằng 1 thì trong gói RTCP này có chứa

một số octets mở rộng ở phần cuối Nó không phải là phần của thông tin điều khiển nhưng chiều dài của nó vẫn được tính vào trường length

Octet cuối cùng của phần đệm có chứa số octets nên được bỏ qua, kể cả chính nó (giá trị này sẽ là bộ số của 4) Các bits đệm có thể được sử dụng trong một số thuật toán mã hóa với kích thước block cố định Trong một gói ghép RTCP, bits đệm chỉ được sử dụng trong các gói con, bởi vì gói ghép sẽ được mã mật như là một khối Hơn nữa, nếu phần đệm được thêm vào gói thì giá trị của nó chỉ có ý nghĩa cho gói đó mà thôi

- Reception report count (RC): 5 bits

Dùng để xác định số các block báo nhận (reception report blocks) được mang trong gói này Nếu không có block nào thì trường này có giá trị 0

- Packet type (PT): 8 bits

Trường này có giá trị bằng 200 để xác định gói RTCP này là gói SR

so với độ chính xác của nhãn thời gian NTP Một hệ thống có thể không có một đồng

hồ chuẩn, khi đó người gửi có thể sử dụng đồng hồ hệ thống của mình để giữ vết của thời gian trôi qua từ khi kết nối vào phiên làm việc

Có thể dùng thời gian lấy mẫu để tính thời gian thực tế trôi qua Một người gửi không biết thời gian thực tế hoặc thời gian trôi qua có thể đặt tem thời gian NTP bằng

0

- RTP timestamp: 32 bits

Nhãn thời gian này giống như NTP timestamp ở trên, tuy nhiên giá trị ở đây là độ chênh lệch giữa các thời điểm phát các gói tin Sự phù hợp này có thể dùng để đồng bộ intra và inter media đối với những nguồn mà nhãn thời gian NTP đã được đồng bộ và

có thể được sử dụng bởi các thiết bị nhận độc lập để ước tính tần số trên danh nghĩa đồng hồ RTP Chú ý rằng, trong đa số các trường hợp, giá trị nhãn thời gian RTP của các SR khác nhau trong mọi gói dữ liệu liền nhau Nó được tính toán từ tem thời gian NTP bằng cách dùng mối quan hệ giữa số tem thời gian RTP và thời gian thực được duy trì bằng cách kiểm tra định kỳ thời gian thực tế thời điểm lấy mẫu

- Sender's packet count: 32 bits

Tổng sô các gói dữ liệu RTP đã được gửi bởi người nào đó kể từ khi bắt đầu phiên đến khi gói SR được sinh ra Biến đếm này phải được khởi tạo lại mỗi khi người gửi thay đổi định danh SSRC

- Sender's octet count: 32 bits

Tổng số octets của phần tải (payload), không tính phần tiêu đề hoặc phần đệm, đã được truyền đi kể từ khi thành viên này tham gia phiên truyền đến khi gói SR này được tạo ra Biến đếm này cũng nên được khởi tạo lại khi người gửi thay đổi định danh Trường này cũng có thể được sử dụng để ước tính tốc độ tải trung bình của một người gửi

Phần thứ 3:

Phần này có thể bỏ trống hoặc có giá trị thay đổi phụ thuộc vào số các nguồn lắng nghe bởi người gửi này, kể từ khi gửi đi bản tin hồi đáp cuối cùng Mỗi một khối tin

báo nhận mang theo một số trạng thái về việc nhận các gói tin RTP từ một nguồn đơn đồng bộ Việc truyền đi trạng thái của người nhận trong khi người nhận đó đang thay đổi định danh SSRC có thể gây ra xung đột Những thông tin trạng thái bao gồm:

- SSRC_n (source identifier): 32 bits Định danh SSRC của nguồn mà khối tin báo

nhận này cần chuyển tới

- Fraction lost: 8 bits

Tỷ lệ gói RTP bị thất lạc từ nguồn gửi SSRC_n kể từ lần truyền gói SR hoặc gói RR trước Nó được tính bằng tỷ số giữa số gói bị mất trên số gói được gửi Giá trị được biểu diễn bằng giá trị, tính bằng số nguyên của 8-bit nhị phân chia cho 256 Nếu những gói tin mất do trùng lặp tỉ lệ mất sẽ được thiết lập về 0 Chú ý rằng, phía nhận không thể nói rằng có bao nhiêu gói bị thất lạc trước khi nó nhận được gói tin cuối cùng (tính tại thời điểm đấy) Do vậy, sẽ không có một bản tin báo nhận được phát đi cho nguồn SSRC_n , nếu tất cả các gói tin gửi đi từ nó (kể từ khi phát đi bản thông báo cuối) đều bị thất lạc

- Cumulative number of packets lost: 24 bits

Tổng số các gói dữ liệu RTP từ nguồn SSRC_n đã bị mất, kể từ khi nhận được gói tin RTP đầu tiên Con số này xác định số các gói được nhận trên thực tế hụt bao nhiêu

so với mong muốn Do con số này tính trong một thời gian dài, nên các gói đến muộn

sẽ không bị coi là thất lạc, một gói bị mất cũng bị loại bỏ khi mà đã có một bản sao đến trước

- Extended highest sequence number received: 32 bits

Trong đó, 16 bits thấp chứa số thứ tự cao nhất đã nhận được trong các gói dữ liệu RTP phát từ nguồn SSRC_n 16-bit cao dùng mở rộng cho các số thứ tự này, được dùng khi số đếm vượt quá 16-bit Chú ý rằng, với những người nhận khác nhau, tham gia cùng một phiên RTP nhưng ở các thời điểm khác nhau sẽ tạo ra phần mở rộng khác nhau

- Interarrival jitter: 32 bits

Dùng ước lượng sự khác nhau về mặt thời gian đến của các gói dữ liệu RTP Giá trị này được tính toán dựa trên giá trị của các nhãn thời gian, được biểu diễn bằng số nguyên không dấu Giá trị xác suất của jitter J được xác định nhằm so sánh sự khác nhau D từ nguồn đến đích giữa 2 gói RTP Như được chỉ ra ở công thức dưới đây, điều

này tương đương với sự khác nhau về “relative transit time“ của 2 gói tin “relative

transit time“ là sự khác nhau giữa nhãn thời gian được gắn trên gói RTP và đồng hồ

của bên nhận khi gói tin đó đến đích

Nếu gọi Si là nhãn thời gian gắn trên gói RTP, Ri là thời gian đến của gói Khi đó đối với hai gói i và j ta có D được tính:

D(i,j) = (Rj - Ri) - (Sj - Si) = (Rj - Sj) - (Ri - Si)

interarrival jitter nên được tính một cách liên tục khi mỗi gói dữ liệu được nhận

từ nguồn SSRC_n để thực hiện điều này, sự khác biệt D giữa 1 gói RTP và một gói RTP trước nó (không cần quan tâm đến số thứ tự) được tính theo công thức sau:

J(i) = J(i-1) + (|D(i-1,i)| - J(i-1))/16

- Last SR timestamp (LSR): 32 bits

32 bits giữa của 64 bits trong NTP timestamp nhận được từ gói SR của RTCP mới

nhất từ nguồn SSRC_n Nếu chưa có bản tin SR nào được nhận thì trường này được gán bằng 0

- Delay since last SR (DLSR): 32 bits

Thời gian trễ được đánh giá trong 1/65536 giây, giữa quá trình nhận một gói SR cuối cùng từ nguồn SSRC_n và quá trình gửi đi bản tin hồi đáp Nếu không có bản tin

SR nào được nhận từ nguồn SSRC_n thì trường DLSR được gán bằng 0

Gọi SSRC_r là người nhận đang phát đi bản tin báo nhận này SSRC_n có thể tính toán tổng thời gian trễ lan truyền đến SSRC_r bằng cách ghi lại thời gian A khi bản tin

báo nhận được nhận Nó tính tổng thời gian round-trip time (A-LSR) dựa trên nhãn

thời gian của gói SR cuối cùng (LSR), sau đó trừ đi thời gian DLSR ta có thời gian trễ

lan truyền là: (A - LSR - DLSR) Giá trị này có thể được dùng để tính gần đúng khoảng cách tới các người nhận, cho dù thời gian trễ trên các đường truyền là khác nhau

b RR: gói RTCP báo nhận

Cấu trúc khung một gói RR như sau:

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1V=2 P RC PT=RR=201 Chiều dài gói tin

Report

Block

1

LSR – SR cuối cùng SSRC_2 (SSRC của nguồn thứ 2)

Dạng của bản tin RR cũng gần giống so với SR, ngoại trừ trường PT của SR=201 (của

SR là 200) và 5 từ chứa thông tin người gửi (nhãn thời gian NTP và RTP, số gói và số octet của người gửi) Các trường còn lại hoàn toàn giống so với gói SR

Trong trường hợp gói RR không có dữ liệu được truyền hay nhận cần thông báo, một gói tin RR rỗng (có trường RC=0) phải được đặt ở đầu mỗi gói RTCP ghép

c Báo gửi và báo nhận mở rộng

Trong một vài trường hợp cụ thể, cần định nghĩa một số thông tin mở rộng trong các báo gửi và báo nhận, nếu nó là thông tin được trao đổi thường xuyên giữa bên gửi