Phần này có thể sử dụng để gói gọn một luồng truyền MPEG-2, nó có thể chứa một chương trình đơn hoặc đa chương trình. Việc truyền này chứa nhiều Program Clock Reference (PCR) bằng cách định nghĩa, hằng số của luồng truyền bit dữ liệu. Luồng truyền chứa một đồng hồ đo liên quan tới tốc độ luồng truyền,giá trị này có thể là một hằng số cũng có thể biến đổi.
Chú ý: Tuy nhiên trong trường hợp tốc độ bít là biến đổi, tốc độ bit giữa các PCR là không đổi và được định nghĩa trong MPEG-2.
Content Service Provider (CSP) có thể nhận các luồng truyền dữ liệu (ví như từ vệ tinh) chứa rất nhiều chương trình. CSP được dùng để phân tách các luồng truyền và tạo ra các luồng truyền riêng biệt (SPTS) cho mỗi chương trình, hoặc để truyền Multiple Program Transport Stream (MPTS) để đảm bảo tính toàn vẹn của nó.
Tất cả các luồng truyền MPEG-2 sẽ được tóm lược trong RTP theo RFC 1889[23] kết hợp với RFC [34]. UDP đặc biệt sử dụng trong một vài hệ thống cũng sẽ không được sử dụng trong trường hợp này.
RTP luôn sử dụng số cổng UDP (trong RFC 1889[23]). Nếu thiết bị đầu cuối được áp dụng với một cổng RTP, nó sẽ được thay thế số cổng này thành một số cổng nhỏ hơn. Luồng RTCP trả về sẽ sử dụng một cổng tiếp theo (số thứ tự cổng lớn hơn).
Mỗi gói IP được định dạng theo chuẩn tiêu đề IP, một tiêu đề UDP, một tiêu đề RTP và một số nguyên của gói tin trong luồng truyền 188 byte MPEG-2. Như ta thấy trong hình 10 ở dưới đây, không có yêu cầu cho mỗi gói RTP trong một luồng để chứa cùng một số lượng của các gói trong luồng truyền dữ liệu. Nơi nhận sẽ sử dụng trường chiều dài trong tiêu đề UDP để đo số lượng gói tin truyền trong mỗi gói RTP.
Hình 16 - Định dạng nhỏ nhất của gói (Ipv4)
Số lượng của các gói trong luồng truyền có thể được lược trong mỗi gói IP và được giới hạn bởi kích thước tối đa của khối dữ liệu IP (65 535 octets cho Ipv4). Việc này nhằm mục đích kiểm soát giới hạn tối đa có thể truyền trên mạng. Nếu vượt quá MTU của mạng sẽ dẫn tới phân mảnh IP, và làm tăng hiệu ứng mất gói tin trên mạng. Nguyên nhân là do nếu một đoạn tin bị mất, các đoạn tin còn lại sẽ bị loại khỏi nơi nhận. Nó cũng đặt thêm tải lên bộ định tuyến và tái lắp ráp tại hệ thống đầu cuối.
Đối với Ethernet-based work, 1 492 bytes của MTU (IEEE 802.3 khung với LLC) hoặc 1 500 bytes (IEEE 802.3 khung không chứa LLC), số lượng các gói MPEG trên gói IP sẽ được giới hạn là 7 (tức là chiều dài tối đa của gói là: 1 356 bytes). Nơi lựa chọn tiêu đề IP hoặc RTP được sử dụng số của các gói MTS trên gói IP có thể ít hơn 7 đặt trong MTU.
Nếu tải RTP được thiết lập để tìm kiếm phân mảnh, thì bất cứ thiết bị đầu cuối không được hỗ trợ về phân mảnh thì không thể nhận được luồng dữ liệu này. Vì thế một đề nghị được đưa ra đó là các CSP thiết lập bit DF (do not Fragment) trong tiêu đề IP. Với bit này, các bộ định tuyến sẽ trả về một bản tin ICMP “fragmentation needed and DF set” nếu độ dài gói tin vượt quá MTU của mạng đích. CSP có thể hiệu chỉnh kích cỡ tải như bản tin đã nhận được. IP (RFC 791[12]) yêu cầu tất cả các máy chủ sẽ bắt buộc chấp nhận gói dữ liệu ít nhất là 575 octets
CSP có thể lựa chọn không kiểm tra tổng UDP và thiết lập giá trị này từ 0 (như là trên RFC 768[11]).
Hình 17 - Định dạng tiêu đề RTP
Loại tải sẽ được thiết lập từ MP2T giống như trong RFC 1890[24]
16 bit đếm thứ tự trong tiêu đề RTP sẽ được sử dụng bởi nơi nhận để yêu cầu cung cấp lại các gói đã được gửi đi, xoá các gói giống nhau, và dò tìm các gói bị thất lạc.
32 bit mốc thời gian trong tiêu đề RTP thu được từ nguồn đồng hồ 90kHz, nhưng không yêu cầu tồn tại, khoá đồng hồ tham chiếu tới một trong những chương trình trong luồng tải. Đồng hồ sẽ phù hợp với sự chính xác và giảm khó khăn cho hệ thống đồng hồ của MPEG 2 (như được định nghĩa trong ISO/IEC 13818-1 [62]).
Các trường khác được hoàn thành giống như trên RFC 1889[23] và RFC 2250[34]. Lựa chọn trường CSRC sẽ bị thiết bị đầu cuối bỏ qua.
Đối với hầu hết luồng truyền dữ liệu, các RTP/UDP/IP sử dụng 40 byte trên gói RTP là rất ít (chỉ chiếm 3% trong số 1 316 byte). Mặc dù các tiêu đề nén có thể mang lại lơi ích về tỉ lệ bit thấp, nhưng tăng độ phức tạp mà nơi đầu cuối không thể nhận được. Như vậy tiêu đề nén (như RFC 2508 [41]) sẽ không được sử dụng.