Một bộ “translator” nhận một bản tin báo nhận từ một “cloud” chuyển tiếp đến các “cloud” khác, với trường SSRC không đổi. Chú ý rằng, luồng các bản tin báo nhận có chiều ngược với chiều của luồng dữ liệu RTP.
Nếu trước đây “translator” kết hợp nhiều gói RTP đầu vào thành một gói RTP ghép tại đầu ra và đã thực hiện việc thay đổi số thứ tự của gói, thì nó phải thực hiện chuyển đổi ngược tương ứng với các trường “packet loss” và "extended last sequence number”. Điều này có thể là phức tạp.
Trong một số trường hợp, khơng có cách nào hiệu quả để chuyển đổi các bản tin báo nhận, “translator”sẽ tổng hợp các bản tin báo nhận của từng đầu cuối rồi tạo ra một bản báo nhận mới để chuyển đi.
Một “translator” khơng bắt buộc có một định danh SSRC riêng, tuy nhiên cũng nên có một giá trị SSRC dùng với mục đích gởi đi các thơng báo nó đã nhận được những gì. Các bản tin này sẽ được gởi tới tất cả các “cloud” kết nối với “translator” đó. Mỗi “cloud” sẽ nhận các bản tin này rồi truyền multicast các thành viên của nó.
c. SDES: Thường thì “translator” sẽ chuyển tiếp các gói tin SDES từ một “cloud”
đến các “cloud” khác mà không hề thay đổi gì. Trong trường hợp băng thơng hạn chế “translator” sẽ chặn các gói SDES. Các gói CNAME phải ln được chuyển tiếp vì nó được dùng để xác định xung đột SSRC trên mạng.
Khi một bộ “translator” có tạo ra các gói RR của riêng mình thì phải gởi đi các thông tin về SDES, CNAME của nó.
d. BYE:
“translator” chuyển tiếp gói BYE, khơng hề thay đổi gì. khi một bộ “translator” dừng việc chuyển tiếp các gói tin (RTP/RCTP) thì nó sẽ gởi gói BYE đến tất cả các “cloud” mà nó kết nối. Trong gói BYE này sẽ chứa danh sách tất cả các SSRC mà nó đã từng chuyển tiếp đến “cloud” đó, bao gồm cả SSRC của chính nó (nếu như nó cũng đã gởi đi các bản thơng báo của riêng mình).
e. APP: Gói này được chuyển tiếp hồn tồn khơng thay đổi gì.
5.3. HOẠT ĐỘNG CỦA MIXERS:
Do “mixer” ln tạo ra các luồng dữ liệu mới của riêng mình, nó sẽ khơng chuyển thẳng các gói SR hay RR mà nó sẽ tái tạo lại các thơng tin rồi mới chuyển đi.
Hình 5.3: Hoạt động của Mixer.
Bây giờ ta sẽ đi tìm hiểu, cách xử lý của mixer với từng loại gói tin RTCP.
a. SR (sender information):
Bộ “mixer” khơng chuyển thẳng các bản tin SR bởi vì một số đặc tính của nguồn đều bị thay đổi khi qua bộ “mixer”. Bộ “mixer” sẽ đóng vai trị như một nguồn đồng bộ, nó sẽ tạo ra gói SR riêng với thông tin thông báo cho luồng dữ liệu đã được trộn tại đầu ra.
b. SR/RR (reception report blocks):
Tương tự như trên, bộ “mixer” cũng sẽ tạo ra bản tin báo nhận mới tương ứng với các nguồn gởi.
Trong bản tin báo nhận mà bộ “mixer” gởi đi nguồn nhận sẽ không được xác định dựa trên trường SSRC mà sẽ được xác định dựa trên danh sách CSRC. Do vậy các bản tin báo nhận cho một nguồn ở trong một “cloud” nào thì chỉ được gởi đến “cloud” đó, khơng được gởi đến các “cloud” khác. Cũng không được chuyển tiếp một bản tin báo nhận từ một “cloud” đến một “cloud” khác.
c. SDES:
Bộ “mixer” thường nhận các gói SDES từ một “cloud” chuyển tiếp đến các “cloud” khác mà khơng thay đổi gì. Tuy nhiên trong trường hợp mạng có băng thơng hạn chế, “mixer” cũng giống như “translator” sẽ hạn chế việc truyền đi các gói SDES khơng mang CNAME. Các gói SDES-CNAME được truyền đi để sử dụng cho việc phát hiện xung đột SSRC trên mạng.
Hình 5.4: khả năng phát hiện vịng lặp hoặc xung đột của mixer.
Chú ý: một định danh SSRC trong danh sách CSRC được tạo bởi “mixer” có thể
xung đột với một giá rị SSRC được phát bởi một hệ thống cuối.
Ngoài ra bộ “mixer” phải gởi các gói SDES-CNAME của nó tới các “cloud” mà nó gởi tới các gói SR, RR.
Khi các bộ “mixer” khơng chuyển tiếp thẳng các gói SR, RR, chúng sẽ phân tích các gói SDES từ một gói ghép RTCP, tối thiểu hố phần tiêu đề, sau đó có thể ghép các đoạn trong một gói SDES đơn. Các gói SDES này sẽ được xếp vào trong các bản tin SR hoặc RR được phát đi bởi “mixer”. Vì thế mà tốc độ gói RTCP có thể khác nhau tại hai phía của một bộ “mixer”.
Một bộ “mixer” tổng hợp các gói SDES sẽ sử dụng băng thơng RTCP nhiều hơn một nguồn đơn bởi cac gói SDES ghép có kích thước lớn hơn. Điều này là hồn tồn hợp lý bởi một bộ “mixer” đại diện cho nhiều nguồn đơn.
Đối với một bộ “mixer” sử dụng cơ chế chuyển thẳng các gói SDES mà nó nhận được cũng có tốc độ phát các gói RTCP lớn hơn so với một nguồn đơn.
d. BYTE:
Một bộ “mixer” phải chuyển thẳng các gói BYTE. Khi bộ “mixer” muốn rời khỏi phiên làm việc, nó sẽ gởi một gói BYTE đến tất cả các “cloud” có kết nối đến. Gói Byte này sẽ chứa định danh SSRC của tất cả các nguồn đã từng được chuyển qua, kể cả định danh SSRC của bản thân bộ “mixer”.
e. APP:
Việc xử lý các gói AAP tại “mixer” sẽ phụ thuộc vào từng ứng dụng cụ thể.
5.4. CÁC “MIXER” MẮC PHÂN TẦNG:
Một phiên RTP có thể bao gồm nhiều bộ “translator” và “mixer” như trên hình vẽ
Hình5.5 :Mơ hình phân tầng các Mixer.
Nếu 2 “mixer” được phân tầng như M2 và M3 trong hình, các gói được nhận bởi một “mixer” đã được tổng hợp và đã được chèn thêm danh sách CSRC. Bộ “mixer” sau đó sẽ tạo danh sách CSRC ở đầu ra dựa vào danh sách CSRC từ “mixer” trước và các định danh SSRC của các gói chưa được trộn.
Trên hình vẽ đầu ra của M3 sẽ có danh sách CSRC là (64,45). Giá trị này được tổng hợp từ danh sách CSRC chuyển tới từ M2 (64) với giá trị SSRC của đầu cuối E5:45.
Cũng giống như trong trường hợp khơng phân tầng, nếu danh sách CSRC có nhiều hơn 15 định danh thì những giá trị từ 16 trở đi sẽ không được thêm. Trường hợp này để không xảy ra mất các nguồn từ 16 trở đi, ta sử dụng một cơ chế vòng lặp, chèn luân phiên.