Đây là qui tắc gởi một gói RTCP như thế nào và làm gì khi nhận mỗi gói RTCP. Qui tắc phải đảm bảo hoạt động tốt trong trường hợp truyền multicast hay truyền unicast đa điểm và thoả mãn các điều kiện được nêu ở phần trên. Để thực hiện được điều này, mỗi thành viên tham gia phiên phải duy trì được một số thông tin trạng thái sau:
- tp: Thời điểm mà gói RTCP gần nhất được gởi đi. - tc: Mốc thời gian hiện tại.
- tn: Thời điểm mà gói RTCP tiếp theo sẽđược gởi.
- Pmembers: Số thành viên theo kết quảđược tính lần trước. - members: Số thành viên hiện tại.
- senders: số người đang ở trạng thái gởi dữ liệu.
- rtcp_bw (The target RTCP bandwidth): Tổng băng thông được sử dụng cho việc truyền các gói RTCP của tất cả các thành viên tham gia phiên, đơn vị là octets/giây. Giá trị này được sử dụng để tính tỷ lệsession bandwidth được cung cấp cho ứng dụng khi bắt đầu.
- we_sent: Khi cờ này là true dùng để chỉứng dụng đã truyền dữ liệu đi quá 2 chu kỳRTCP report.
- avg_rtcp_size: Kích thước trung bình của gói RTCP ghép (compound RTCP) đã được gởi và nhận bởi thành viên này, đơn vị là octets. Kích thước này bao gồm cả phần tiêu đềđược thêm vào ở tầng mạng và tầng giao vận.
- initial: Cờ này mang giá trị true nếu ứng dụng vẫn chưa gởi đi gói tin RTCP.
Như chúng ta thấy, rất nhiều giá trị được sử dụng cho viẹc tính toán thời gian giữa các lượt truyền các gói tin.
a. Tính toán khoảng thời gian truyền RTCP:
Phần trên chúng ta đã đề cập đến cơ sở lý thuyết cũng như ý nghĩa của thời gian này:T - Nếu số người gởi ≤25% số thành viên, chu kỳ gởi T phụ thuộc là thành viên đó có
đang gởi dữ liệu hay không (dựa trên giá trị we_sent). Nếu thành viên này đang gởi, giá trị (we_sent=true): bw 0,25.rtcp_ ize avg_rtcp_s = Cs
Hằng số nsđược tính bằng số thành viên đang gởi. Với những thành viên không gởi: bw 0,75.rtcp_ ize avg_rtcp_s = Cr
nrđược tính bằng số người không gởi dữ liệu.
Khi số người gởi >25% số thành viên, tất cả người gởi và người nhận được đối xử như nhau. rtcp_bw ize avg_rtcp_s = C
n được tính bằng tổng số thành viên tham gia.
Nhưđã nói ở phần trước, ta có thể phân dải thông của RTCP thành 2 phần, tham số R, S để phân biệt giữa nhóm người đang truyền và không. Trong trường hợp này ta chỉ cần thay 25% bằng tỉ số S/(S+R), còn 75% bằng tỷ số R/(R+S).
Trong trường hợp đặc biệt, khi không có người gởi, hặc không có người nhận (S=0, hoặc R=0) sẽ xảy ra tình huống chia cho 0, do vậy khi cài đặt ta phải chú ý các trường hợp này.
- Nếu một thành viên không tham gia gởi gói RTCP (initial=true), hằng số Tmin=2.5s, ngược lại nó được đặt bằng 5s.
- Giá trị của khoảng thời gian Td sẽ được ước tính là giá trị lớn nhất của (Tmin, n*C).
- Giá trị T sẽđược phân bố trong dải từ 0,5 đến 1,5 lần giá trị tính toán Td.
- Giá trị T trên sẽ được chia cho (e-1,5) để bù lại việc băng thông RTCP trên thực tế thấp hơn so với mức tính toán.
Theo cách tính này, khoảng thời gian T sẽ lấy giá trị ngẫu nhiên tại một thời điểm, tuy nhiên nếu tính lâu dài thì giá trị trung bình sẽ ≥25% RTCP sẽ được giành cho những người gởi dữ liệu, phần còn lại dành cho người nhận dữ liệu.
b. Các giá trị khởi tạo:
Khi một thành viên bắt đầu tham gia, giá trị khởi tạo của các biến sẽ là: - tp=0. - tc=0. - senders=0. - pmembers=1. - members =1. - we_sent = false. - rtcp_bw=5% băng thông của phiên. - initial=true.
- avg_rtcp_size bằng giá trị của gói RTCP mà ứng dụng sắp tạo ra.
- Dựa vào các thông số trên ta ước lượng T. sau đó đặt thời gian cho gói đầu tiên: tn=T.
Chú ý: một ứng dụng bất kỳ có thểđặt lại giá trị thời gian này cho phù hợp. Thành viên sẽ thêm giá trị SSRC của mình vào đầu bảng thành viên.
c. Nguyên tắc nhận một gói RTP hoặc một gói không phải là RTCP-BYTE:
Khi một gói RTP hoặc một gói RTCP mà không phải là BYTE từ một thành viên, bên nhận sẽ trường SSRC tương ứng trong bảng các thành viên(member table). Nếu không thấy, sẽ tạo một bản ghi mới và cập nhật các thông tin về thành viên vừa được
chấp nhận.Các giá trị chung (pmembers) được cập nhật lại. Quá trình tương tự cũng được thực hiện với các gói RTP có chứa danh sách CSRC.
Khi một gói RTP được nhận từ một thành viên mà giá SSRC của nó chưa có mặt trong bảng danh sách người gởi, giá trị này sẽ được thêm mới vào bảng, các thông số dành cho người gởi (sender table) cũng được cập nhật.
Với mỗi gói tin RTCP được nhận, giá trị avg_rtcp_size sẽđược cập nhật lại: avg_rtcp_size = (1/16) * packet_size + (15/16) * avg_rtcp_size.
Trong đó packet_size là kích thước của gói RTCP vừa nhận được.
d. Nguyên tắc nhận một gói RTCP-BYTE:
Khi một gói RTCP-BYTE được nhận, trường SSRC sẽ được kiểm tra lại trong bảng thành viên và bảng người gởi. Nếu có, bản ghi tương ứng trong mỗi bảng sẽ bị xoá. Các giá trị chung được cập nhật lại.
Hơn nữa để tốc độ phát các gói RTCP thích ứng tốt hơn với những thay đổi trong nhóm thành viên, ta sử dụng thuật toán "reverse reconsideration" khi nhận được gói BYTE:
- Giá trị tn, tp được cập nhật lại dựa theo công thức: tn=tc+ (members/pmembers) * (tn - tc). tp = tc - (members/pmembers) * (tc - tp).
- Gói tin RTCP được lập lịch lại với thời điểm sẽ truyền tn được rút ngắn lại. - Giá trị pmembers được đặt bằng giá trị members.
Thuật toán này ngăn việc số lượng các thành viên giảm xuống trong một thời gian ngắn (bằng thời gian timeout), trong trường hợp thành viên rời khỏi phiên một lúc, nhưng sau đó lại quay lại. Do vậy thuật toán này giúp cho việc điều chỉnh lại giá trị chính xác nhanh hơn.
e. Tính toán timeout một nguồn SSRC:
Cứ sau một khoảng thời gian nào đó, mỗi thành viên phải được kiểm tra time out
của các thành viên khác. Để làm được điều này, các thành viên tính toán thời gian Td cho phía nhận (có giá trị we_sent =false).
Nếu một thành viên mà không gởi một gói tin RTP hoặc RTCP nào trong khoảng thời gian M.Td (M là hệ số nhân, có giá trị mặc định là 5). Khi đó thành giá trị SSRC tương ứng sẽ bị loại khỏi bảng thành viên, số thành viên membersđược cập nhật lại.
Nếu một thành viên trong danh sách người gởi mà không được nhận một gói RTP nào trong khoảng thời gian 2T.(khoảng thời gian giữa 2 gói RTCP cuối cùng được nhận), khi đó thành viên sẽ bị loại khỏi danh sách người gởi, số người gởi senders
được cập nhật lại.
Nếu một thành viên nào “time out” ta sẽ sử dụng thuật toán reverse reconsiderationở trên.
Quá trình kiểm tra “time out” nên được thực hiện ít nhất 1 lần trong một chu kỳ RTCP.
f. Hoạt động của đồng hồ truyền tải:
Khi thời gian truyền gói đến, thành viên sẽ thực hiện các thao tác sau: - Tính toán lại giá trị T, bao gồm cả thừa số ngâu nhiên.
- Nếu (tp+T)≤tc, một gói RTCP sẽđược gởi đi. tp = tc,
giá trị T được tính lại. tn = tc + T.
- Nếu (tp+T)>tc: không gói RTCP nào được gởi đi. tn=tp+T.
Thời điểm truyền gói được đặt lại bằng tn. - pmembers = members.
Nếu một gói RTCP được truyền, giá trị của initial được gán lại bằng FALSE. Giá trị avg_rtcp_size được tính lại:
avg_rtcp_size = (1/16) * packet_size + (15/16) * avg_rtcp_size. Với packet_size là kích thước của gói RTCP vừa được gởi.
g. Transmitting a BYE Packet:
Khi một thành viên muốn rời khỏi phiên, một gói BYE được gởi đi để thông báo cho các thành viên khác biết. Để tránh việc tràn dữ liệu do có nhiều thành viên cùng gởi gói BYTE, mỗi thành viên phải phải thực hiện thuật toán sau, nếu tại thời điểm đó
số thành viên >50. Thuật toán này có mức ưu tiên cao hơn quyền thông thường của mỗi thành viên. - Khi một thành viên muốn rời khỏi hệ thống: tp được gán bằng tc. members = pmembers =1. initial =1. we_sent=false. senders =0.
avg_rtcp_size =kích thước của gói BYTE. tn=tc+T. (giá trị T là giá trị cũ).
- Khi nhận được gói BYTE của một thành viên khác:
biến members tăng 1 đơn vị, không cần quan tâm thành viên đó có trong bảng thành viên chưa?
Bảng sample được đưa vào sử dụng, tất cả các giá trị SSRC được đưa vào bảng này(kể cả của gói BYTE).
Giá trị members sẽ không tăng khi nhận được bất kỳ gói tin nào không phải là RTCP BYTE.
avg_rtcp_size cũng chỉđược tính lại khi nhận được gói BYTE. Bảng senders sẽ không cập nhật lại giá trị khi nhận được gói RTP. - Việc truyền gói BYTE được thực hiện theo cơ chế như các gói RTCP thông
thường.
Với cách thực hiện trên, gói BYTE được truyền 1 cách đúng đắn, bởi việc điều khiển tổng băng thông được sử dụng. Trong tình huống xấu nhất, nó sẽđiều khiển các gói tin RTCP sử dụng băng thông gấp đôi mức bình thường (10%). Trong đó, 5% được sử dụng cho truyền gói RTCP BYTE, 5% còn lại dùng truyền RTCP khác.
Nếu một thành viên không muốn đợi thực hiện cơ chế trên, họ có thể rời bỏ nhóm bằng cách không gởi đi gói BYTE, việc còn lại do sự kiện “time out” đảm nhiệm.
Chú ý, nếu kích thước của nhóm nhỏ hơn 50, khi thành viên rời khỏi nhóm có thể gởi ngay gói BYTE mà không phải chờ. Trong trường hợp một thành viên chưa hề gởi
đi một gói RTP hoặc RTCP nào thì khi rời khỏi nhóm họ cũng không cần phải gởi đi gói BYTE.
h. Cập nhật biến we_sent:
Biến we_sent của 1 thành viên trong bảng sender sẽ nhận giá trị true nếu thành viên mới gởi 1 gói RTP, ngược lại nó nhận giá trị false.
Nếu một thành viên gởi đi một gói RTP thì nó sẽ cập nhật lại giá trị biến we_sent trong bảng enders của mình giá trị true.
i. Xác đinh băng thông nguồn:
Có một số thông tin được thêm vào gói SDES (several source description) CNAME, NAME, 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ể. Một ứng dụng phải chú ý đến việc điều khiển phân chia băng thông khi có phần thông tin kèm theo. Bởi vì chúng có thể làm giảm tốc độ nhận các bản tin và CNAME được gởi, điều này làm suy giảm hiệu suất của giao thức RTP. Theo khuyến cáo, không nên sử dụng quá 20% băng thông RTCP của 1 thành viên để truyền các thông tin bổ sung. Hơn nữa không phải mọi thành phần của SDES đều được thêm trong mọi trường hợp. Chúng chỉ nên sử dụng 1 phần băng thông, tuỳ thuộc vào từng trường hợp cụ thể, hơn nữa tỷ lệ này cũng biến đổi động.
Ví dụ, một ứng dụng chỉ truyền 3 thông số: CNAME, NAME và EMAIL. Name được ưu tiên cao hơn EMAIL vì nó luôn được hiển thị trên giao diện người dùng của ứng dụng, còn tên chỉ cần hiển thị khi cóz yêu cầu. Một gói RR và một gói SDES mang CNAME sẽ được truyền đi sau mỗi khoảng 5s. Cứ 3 chu kỳ (15s) thì sẽ có một gói mang thông tin bổ sung trong gói SDES. Trong đó cứ 8 lần bổ sung (2 phút) thì mang giá trị NAME, còn 1ần mang giá trị EMAIL.
Trong những ứng dụng đa luồng, ta có thể phối hợp giữa việc truyền các thông tin bổ sung và CNAME cho mỗi ứng dụng, 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 phiên kia sẽ chỉ truyền giá trị CNAME.