Nghiên cứu và ứng dụng giao thức RTP

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. 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ể. 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, với các giá trị SSRC/CSRC. 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 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). 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 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. 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 toá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. 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: Đâ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. 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): 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: 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 4.6. Các bản tin thông báo của người gởi và người 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 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. 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: 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 Hình 4.3: Cấu trúc bản tin SR-RTCP. 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 gia