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 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ế. 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 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 ở 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 đó 1/4 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ị, 1/4 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 1/4 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 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 toá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 quá 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 1/2 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: 360/bw (kilobits/second).
- Nếu băng thông của phiên truyền lớn hơn 72kb/s khi đó khoảng thời gian tối thiểu sẽ nhỏ hơn 5s.
- Khoảng thời gian tính toá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ử dụng thuật toá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 toá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 1/2 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 luôn, 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.