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 cha đợ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.