KHOẢNG THỜI GIAN TRUYỀN CÁC GÓI RTCP : RTCP TRANSMISSION INTERVAL

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, với các giá trị SSRCCSRC.
Hình 4.2: Minh hoạ việc 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 q 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.

4.3 KHOẢNG THỜI GIAN TRUYỀN CÁC GÓI RTCP : RTCP TRANSMISSION INTERVAL

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 độ phát 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 tố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ó
38
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ế. 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ị session bandwidth, do đó khoảng thời gian phát gói RTCP sẽ được tính giống
nhau. Việc tính tố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 ở lớp mạng và lớp giao vận.
Lưu lượng điều khiển nên giới hạn chỉ là một phần nhỏ của session bandwidth,
để việc truyền tải dữ liệu không bị ảnh hưởng. Theo khuyến nghị, luồng RTCP nên
chiếm 5 session bandwidth. Trong đó 14 giải thơng của RTCP dùng cho những
thành viên hiện đang gởi dữ liệu. Do đó, trong phiên truyền với số lượng người gởi ít, người nhận nhiều, thì một thành viên mới kết nối có thể nhanh chóng nhận được giá trị
CNAME của thành viên đang gởi dữ liệu. Băng thông dành cho lưu lượng điều khiển có thể chia làm 2 loại, một cho cac
thành viên đang ở trạng thái gởi dữ liệu, một dành cho các thành viên còn lại. Chúng ta
2 tham số này là S và R. Theo khuyến nghị, 14 RTCP bandwidth dành cho người gởi
dữ liệu, do vậy tỷ lệ sử dụng băng thông của các thành viên sẽ là 1,25 và 3,75. Khi tỷ lệ người gởi lớn hơn 14 số thành viên, thì những người gởi sẽ sử dụng cả
5 Session bandwidth. Việc phân chia thành hai loại thành viên R, S cho phép ta có
thể giảm băng thông RTCP của những thành viên R không gởi dữ liệu vể 0. Khi đó các thành viên này sẽ không gởi đi các bản tin RTCP, mà chỉ nhận các bản tin RTCP để
phục vụ cho việc khôi phục và đồng bộ dữ liệu. Thông thường, điều này khơng được khuyến khích vì nó sẽ làm mất một số chức năng kiểm soát lỗi như đã nêu ở phần đầu.
Tuy nhiên nó rất phù hợp cho những kết nối 1 chiều, hoặc cho những phiên truyền
39
không cần sự hồi đáp về chất lượng dữ liệu nhận được, cũng như khơng cần quan tâm đến sự có mặt của các thành viên chỉ nghe. Nếu sử dụng cơ chế này ta có thể giảm
được phần nào sự tắc nghẽn trên mạng do băng thông không đủ. Việc tính tốn chu kỳ phát các gói tin ghép RTCP cũng nên đặt ra giới hạn tránh
trường hợp quá nhiều gói tin vượt q mức băng thơng cho phép, khi số lượng thành viên tham gia ít và khơng còn theo qui luật số lớn nữa. Điều này đòi hỏi chu kỳ phát
các bản thông báo phải đủ lớn. Mỗi khi khởi động ứng dụng, thời gian trễ được áp đặt trước cho gói RTCP ghép đầu tiên. Sau đó các thành viên khác gởi các bản tin
thơng báo gởi lại sẽ điều chỉnh lại khoảng thời gian phát của các bản tin RTCP ngắn hơn cho phù hợp, có thể sẽ bằng 12 giá trị ban đầu. Giá trị tối thiểu khuyến cáo là
5s. Các khoảng thời gian phát giữa các gói RTCP liên tiếp, có thể được giảm xuống phụ
thuộc vào các tham số băng thông phiên truyền, tuân theo những yêu cầu sau: - Với phiên truyền Multicast, chỉ có bên chủ động gởi số liệu mới được quyền
rút gắn khoảng thời gian gởi các gói RTCP ghép. - Với phiên truyền unicast việc giảm giá trị có thể được thực hiện bởi bên nhận
lẫn bên gởi. Trong trường hợp này, thời gian trễ được khởi tạo ban đầu là 0 tốc độ gởi nhanh nhất.
- Cho tất cả các phiên truyền nói chung, khoản thời gian nhỏ nhất được cố định, dựa trên sự tính toán dựa trên khoảng thời gian timeout của thành viên. Với
cách này, sẽ không xảy ra hiện tượng timeout cho các gói tin RTCP, khi một thành viên nào đó thiết lập thời gian timeout quá bé.
- Theo khuyến nghị, giá trị tối thiểu có thể được giảm xuống bằng: 360bw kilobitssecond.
Nếu băng thông của phiên truyền lớn hơn 72kbs khi đó khoảng thời gian tối thiểu sẽ nhỏ hơn 5s.
- Khoảng thời gian tính tốn giữa các gói RTCP tỷ lệ tuyến tính với số lượng các thành viên tham gia. Việc này có thể gây rắc rối khi có một nhóm thành viên
mới đồng thời tham gia vào một phiên truyền thiết lập sẵn. Khi đó các thành viên sẽ có sự ước lượng sai về khoảng thời gian truyền, họ sẽ thiết lập khoảng
thời gian này nhỏ hơn so với yêu cầu. Với số lượng thành viên tham gia đồng thời là lớn thì việc này khá quan trọng. Để giải quyết vấn đề này, người ta sử
40
dụng thuật tốn timer reconsideration, trong đó có cơ chế Back-off. Theo
đó, các thành viên sẽ tự động dữ lại gói RTCP của mình khi lắng nghe thấy số lượng thành viên đang tăng lên.
Khoản thời gian thực tế giữa các gói RTCP được biến đổi ngẫu nhiên trong khoảng [0.5,1.5] lần giá trị tính tốn, để tránh sự đồng bộ khơng lường trước được của các thành
viên. Gói RTCP đầu tiên được gởi sau khi thành viên tham gia phiên truyền cũng bị làm trễ đi một khoảng thời gian ngẫu nhiên trong khoảng 12 khoảng thời gian RTCP tối
thiểu. 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.
Khi các thành viên rời bỏ phiên, họ sẽ gởi tín hiệu BYE hoặc tạo ra thời gian
timeout, số lượng thành viên trong nhóm sẽ giảm. thuật toán reverse reconsideration
sẽ được sử dụng để các thành viên khác tăng tốc độ truyền gói RTCP. Mặt khác, khi một người rời khỏi phiên truyền, gói BYTE được chuyển đi ln, khơng đợi đến lượt.
Do đó, để tránh tình trạng tràn số liệu, gây ra khi có nhiều thành viên cùng rời đi, người
ta sử dụng thuật toán back-off. 4.4 CẬP NHẬT SỐ THÀNH VIÊN THAM GIA PHIÊN TRUYỀN:
MAINTAINING THE NUMBER OF SESSION MEMBERS Việc tính tốn chu kỳ gởi các gói RTCP 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 thấy. 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 để dùng cho việc theo dõi. Một thành viên mới sẽ chưa chính thức được thừa nhận trước khi gói tin có chứa giá trị SSRC mới hoặc gói SDES RTCP có
chứa CNAME chưa được nhận. 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ọ gởi đi được nhận. Để tránh trường hợp
một gói tin lang thang đế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 đó. Một thành viên bất kỳ có thể đánh dấu một thành viên khác ở trạng thái không hoạt
động inactive hoặc loại bỏ hẳn nếu không nhận được gói tin RTP và RTCP trong một khoảng thời gian.
41
Với những phiên truyền có số lượng thành viên nhiều, có thể khơng thực hiện được việc duy trì một bảng chứa định danh SSRC và trạng thái của các thành viên. Lúc đó ta
sẽ cài đặt cơ chế lấy mẫu SSRC

4.5 QUI ĐỊNH ĐỐI VỚI VIỆC GỞI VÀ NHẬN CÁC GÓI RTCP: