Sau bước lập lịch, receiver sẽ gửi lịch biểu cho các supplier. Khi có một peer cung cấp nhận được lịch nó sẽ gửi các block đã được gán cho receiver thông qua giao thức UDP và sử dụng cơ chế điều khiển tắc nghẽn TCP-friendly (RAP[23] hoặc TFRC[21]) dựa trên kết nối UDP.
Trong suốt phiên streaming, receiver theo dõi tốc độ của dòng streaming nhận được từ mỗi supplier. Nếu như receiver nhận thấy tốc độ nhận được từ một supplier bị suy giảm trong một khoảng thời gian đủ lâu là TDecr, nhận được thông báo hoặc phát hiện có supplier bị lỗi hoặc rời hệ thống thì quá trình chuyển đổi supplier sẽ được thực hiện. Receiver sẽ chọn supplier thay thế từ tập dự phòng và dành băng thông cho supplier (tổng băng thông dành riêng mới phải lớn hơn hoặc bằng băng thông cung cấp bởi supplier đã được thay thế). Sau đó receiver sinh ra một lịch biểu mới để gán các block còn chưa nhận được và gửi lịch cho tập các supplier mới.
Khi xem xét đến yếu tố này có thể thấy việc sinh ra lịch biểu cùng lúc cho tất cả các block trong một segment không phải là sự lựa chọn tốt bởi lịch biểu có thể sẽ phải thay đổi trong suốt phiên streaming, hơn nữa với số lượng lớn các block trong mỗi lần
lập lịch cũng làm tăng chi phí tính toán của receiver lên nhiều lần. Bởi vậy ta lại chia mỗi segment thành nhiều phân đoạn lập lịch khác nhau, mỗi phân đoạn bao gồm Nsche block. Trong phiên streaming của một segment, receiver ban đầu sinh ra lịch biểu cho phân đoạn lập lịch đầu tiên và kết hợp các supplier để tạo dòng truyền tải cho các block thuộc phân đoạn lập lịch này. Khi receiver đã nhận gần đủ tất cả các block thuộc phân đoạn lập lịch thứ nhất (và vẫn còn đủ thời gian để receiver sinh ra và gửi lịch của phân đoạn lập lịch kế tiếp), nó sẽ làm tương tự đối với phân đoạn kế tiếp và cứ tiếp tục như vậy. Việc chọn giá trị cho Nsche (độ dài của một phân đoạn lâp lịch) như thế nào cũng cần phải được cân nhắc và điều chỉnh hợp lý. Nếu Nsche quá nhỏ, receiver sẽ phải gửi lịch nhiều lần và thường xuyên khiến cho lưu lượng truyền tải tăng lên. Còn nếu như Nsche quá lớn thì có thể phần lớn thời gian của lịch biểu trở thành vô nghĩa, vì nhiều khả năng có thể phải thay đổi lịch về sau.
Để quản lý các block nhận được, receiver cũng sử dụng một bộ đệm vòng (ring buffer). Kích thước của bộ đệm vòng là αbuff×Nsche×blk_size, trong đó αbuff>1 và blk_size là kích thước của một block (tính theo byte). Mỗi khi nhận được một block, nó sẽ ghi lại block này vào vị trí tương ứng trong bộ đệm vòng. Như đã đề cập đến trong phần 2.5.3, quá trình thay thế các peer bị lỗi hoặc mất kết nối cũng khiến cho các gói tin đến trễ, bởi vậy bắt buộc receiver phải lưu đệm ít nhất là SInitBuff block trước khi bắt đầu phát hình (quá trình khởi tạo bộ đệm). Sau thời gian khởi tạo bộ đệm thì receiver sẽ liên tục đọc dữ liệu từ bộ đệm vòng và render các khung hình video lên cửa sổ media player.
Receiver cũng theo dõi trạng thái của bộ đệm vòng và ghi vết các block nhận được trong suốt phiên streaming. Mỗi block phải được nhận TAdv giây trước khi phát hình. Ngược lại, block này coi như đã bị thất lạc và receiver sẽ truy vấn các supplier tương ứng để yêu cầu gửi lại.