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 phát nếu có gói dữ liệu gởi đi trong khoảng thời gian giữa 2 bản tin cuối cùng được phátđi. Nếu ngược lại, 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 thông tin.
Các đơn vị bản tin báo nhận (reception report blocks) cung cấp trạng thái về số liệu được nhận từ một thành viên, định danh của thành viên này cũng được mang theo trong bản tin report. Một gói SR hoặc RR có thể chứa tối đa 31 khối các bản tin này báo nhận này.
Các gói RR được thêm nên được đặt sau gói SR hoặc gói RR khởi tạo, để dùng mang 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. Nếu có quá nhiều nguồn phát, 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.
Trong phần tiếp theo, chúng ta sẽ tìm hiểu cấu trúc của 2 loại bản tin thông báo này, có bao nhiêu thông tin có thể thêm khi một ứng dụng yêu cầu hồi tiếp, những bản tin này được sử dụng ra sao.
a. Gói tin RS: Sender Report RTCP Packet
Đây là gói tin RTCP thông báo của người đang truyền dữ liệu phát đi. Trước tiên ta xét đến cấu trúc của gói tin RS:
Bảng 2.3: Cấu trúc bản tin SR-RTCP. 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 Header V=2 P RC PT=SR=200 Length SSRC of sender Sender infor
NTP timestamp, most significant word NTP timestamp, least significant word RTP timestamp
sender's packet count sender's octet count
Report Block 1
SSRC_1 (SSRC of first source)
fraction lost cumulative number of packets lost extended highest sequence number received
interarrival jitter last SR (LSR)
delay since last SR (DLSR) Report Block 2 SSRC_2 (SSRC of second source) ………. profile-specific extensions
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.
Phần đầu: 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 giờ 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 là một 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ả chinh 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ã mật với kích thước block cố định. Trong 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. - length: 16 bits
Dùng xác định kích thước gói tin RTCP, đơn vị là 32-bit, bao gồm cả phần tiêu đề và các phần đệm.
- SSRC: 32 bits Dùng để xác định nguồn đồng bộ (synchronization source) của gói SR.
Phần thứ 2: mang thông tin về người gởi, có chiều dài 20 octets, nó có mặt trong tất cả các gói SR. Nó tóm tắt việc truyền dữ liệu của người gởi này. Các trường có ý nghĩa như sau:
- NTP timestamp: 64 bits. Dùng xác định giá nhãn thời gian, khi mà gói này được truyền đi. Nó có thể được bên nhận dùng để xác định tổng thời gian truyền từ điểm gởi đến điểm nhận. Người nhận phải xác định rằng độ chính xác của nhãn thời gian có thể thấp hơn nhiều 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 riêng, khi đó người gởi sẽ sử dụng đồng hồ hệ thống của mình, dựa vào đó để tính toán ra thời gian NTP tương ứng.
- 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. Điều này có thể giúp cho bên nhận có thể thực hiện đồng bộ các tín hiệu video/audio thu được.
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 không giống nhau.
Ngoài ra, ta nên tính toán ra thời gian dạng NTP, bằng cách sử dụng mối quan hệ giữa việc đếm các nhãn thời gian RTP và thời gian thực được xác định bằng cách kiểm tra đồng hồ chuẩn tại 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ừ 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 được lắng nghe bởi người gởi này, kể từ khi nó goiwr đ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ố đặc điểm về sự nhận các gói tin RTP tại một thành viên nhận. 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 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. 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 đến muộn cũng bị loại bỏ khi mà đã có một gói tương tựđế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 ở cac thời điểm khác nhau sẽ tạo ra phần mở rộng khac 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ị của độ jitter J dùng đượ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 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 tạm ngừng được đánh giá trong 1/65536 giây, giữa quá trình nhận một gói SR cuối nhất 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 gởi từ nguồn SSRC_n nào được gởi thì trường DLSR được gán bằng zero.
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ơì 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.
Cách tính thời gian trễ lan truyền được minh hoạ trong hình dưới. Thời gian được biểu diễn ở cả hai dạng, thập lục phân 32-bit và dạng số thực tương đương. Dấu “:” dùng để phân cách giữa 16-bit phần nguyên và 16-bit phần thập phân.
b. Gói tin RR:
Cấu trúc khung một gói RR như sau:
Bảng 2.4: Cấu trúc bản tin RR-RTCP. 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 Header V=2 P RC PT=RR=201 Length SSRC of packet sender Report Block 1 SSRC_1 (SSRC of first source)
fraction lost cumulative number of packets lost extended highest sequence number received
interarrival jitter last SR (LSR) Report Block 2 SSRC_2 (SSRC of second source) ………. profile-specific extensions
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à 5x4-byte chứa thông tin người gởi (nhãn thời gian NTP và RTP, sốđếm gói và số octet của người gởi bị loại bỏ). 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 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. Extending the Sender and Receiver Reports:
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ản tin thông báo của bên gởi và bên nhận, nếu nó là thông tin được trao đổi thường xuyên giữa bên gởi và bên nhận. Các trường hợp này nên được định nghĩa khác so với các gói RTCP chuẩn, bởi vì nó yêu cầu phần đầu nhỏ hơn:
Cần ít bytes hơn trong gói (không có trường RTCP header hoặc trường SSRC).
Sẽđơn giản và nhanh hơn trong quá trình phân tích, bởi vì trong trường hợp này, ứng dụng đã được lập trình và luôn biết trước cấu trúc các trường mở rộng, do đó có thể truy nhập trực tiếp đến từng trường khi nhận được một bản tin.
Phần mở rộng nếu có, là phần thứ 4 trong gói bản tin gởi hoặc nhận, nó nằm ở phần cuối sau khối bản tin báo nhận (reception report blocks).
Nếu thông tin thêm về người gởi được yêu cầu, khi đó trong các bản tin thông báo của bên gởi, nó sẽ được thêm vào phía trước của phần mở rộng. Còn đối với bên nhận, ta không thực hiện được điều này. Nếu các thông tin về người nhận được thêm, nó sẽđược cấu trúc thành mảng các block ngang hàng với mảng các block khác trong bản tin báo nhận, số các blockđược xác định bởi trường RC.
d. Analyzing Sender and Receiver Reports :
Một điều chắc chắn rằng các thông tin hồi đáp về chất lượng nhận thông tin sẽ không chỉ hữu ích cho người nhận, nó còn dùng cho các người nhận khác và nhà quản trị mạng (đóng vai trò của thành viên thứ 3).
Người gởi có thểđiều chỉnh quá trình truyền tin của mình thông qua các thông tin hồi đáp. Nếu có lỗi xảy ra, các người nhận khác có thể dựa vào thông tin hồi đáp để xác định, cấp độ lỗi là cục bộ, khu vực hay toàn cục. Nhà quản trị mạng có thể chỉ nhận các gói RTCP (không cần quan tâm đến các gói RTP) để đánh giá hiệu suất của mạng trong quá trình truyền multicast.
Các sốđếm tích luỹđược sử dụng trong cả thông tin người gởi và các khối thông báo của người nhận, do đó sự khác biệt được tính giữa 2 bản tin bất kỳ phục vụ cho phép đo trong thời gian ngắn hoặc dài, được dùng để khôi phục lại các bản tin bị thất lạc. Sự khác nhau giữa 2 bản tin cuối cùng nhận được có thể được dùng để ước tính chất lượng hiện thời của đường truyền.
Việc gắn nhãn thời gian NTP giúp ta có thể tính được tốc độ truyền tải dựa vào khoảng thời gian chênh lệch của 2 gói RTCP.
Ta lấy một ví dụ, tính toán tốc độ thất lạc gói trong khoảng thời gian giữa 2 bản tin (bất kỳ). Sự khác biệt giữa các sốđếm tích luỹ cho ta biết được số gói đã bị thất lạc. Giá trị của số thứ tự trong gói tin cuối cùng nhận được giúp ta biết được số gói tin cần
nhận được trong khoảng thời gian giữa 2 bản tin. Tỷ lệ thất lạc gói tin trongkhoảng thời gian này chính là tỷ số của 2 giá trị trên. Nếu 2 bản tin là liên tiếp thì tỷ số này sẽ bằng giá trị của fraction lost field. Ta cũng có thể tính tỷ lệ thất lạc gói tin trong 1s bằng cách chia tỷ số này cho khoảng thời gian chênh lệch giữa 2 nhãn thời gian NTP (đơn vị tính bằng s). Điều này rất quan trọng, bởi các giá trị thống kê được tính trong thời gian dài luôn có ý nghĩa hơn các giá trị tức thời. Việc 200 gói thất lạc trong số 1000 gói có ý nghĩa hơn nhiều so với việc 1 gói thất lạc trong 5 gói. Bởi con số thứ nhất có thể nói lên đặc tính của mạng, còn con số thứ 2 chỉ nói lên một giá trị tức thời, không thể nói là mạng đó tốt hay dở.
Từ những thông tin của người gởi, nhà quản trị mạng có thể tính toán tốc độ tải