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 hoá 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à hoàn toà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.