โปรโตคอลควบคุม RTP ( RTCP ) เป็น โปรโตคอลการส่งสัญญาณนอกแบนด์ แบบเข้ารหัส ไบนารีซึ่งทำงานควบคู่ไปกับโปรโตคอลการขนส่งแบบเรียลไทม์ (RTP) RTCP ให้ข้อมูลสถิติและข้อมูลควบคุมสำหรับเซสชัน RTP โดยทำงานร่วมกับ RTP ในการส่งและบรรจุข้อมูลมัลติมีเดีย แต่ไม่ได้ขนส่งข้อมูลสื่อใดๆ ด้วยตัวเอง

หน้าที่หลักของ RTCP คือการให้ข้อมูลย้อนกลับเกี่ยวกับคุณภาพการบริการ (QoS) ในการกระจายสื่อ โดยการส่งข้อมูลสถิติเป็นระยะ เช่น จำนวน ไบต์และแพ็กเก็ต ที่ส่ง การสูญหายของแพ็กเก็ตความผันแปรของความล่าช้าของแพ็กเก็ตและเวลาหน่วงไป-กลับ ไปยังผู้เข้าร่วมในเซสชันมัลติมีเดียแบบสตรีมมิ่ง แอปพลิเคชันอาจใช้ข้อมูลนี้เพื่อควบคุมพารามิเตอร์คุณภาพการบริการ เช่น การจำกัดปริมาณการรับส่งข้อมูล หรือการใช้ ตัวแปลงสัญญาณที่แตกต่างกัน

โดยทั่วไป RTP จะถูกส่งผ่านพอร์ต UDPเลขคู่และข้อความ RTCP จะถูกส่งผ่านพอร์ตเลขคี่ถัดไป^{[ 1 ]}

RTCP เองไม่ได้จัดเตรียมวิธีการเข้ารหัสหรือการตรวจสอบความถูกต้องของข้อมูลการไหลใดๆ กลไกดังกล่าวอาจนำไปใช้ได้ เช่น ด้วยโปรโตคอลการขนส่งแบบเรียลไทม์ที่ปลอดภัย (SRTP) ^{[ 2 ]}

RTCP มีฟังก์ชันพื้นฐานที่คาดว่าจะต้องนำไปใช้ในเซสชัน RTP ทั้งหมด:

• หน้าที่หลักของ RTCP คือการรวบรวมสถิติเกี่ยวกับคุณภาพของการกระจายสื่อระหว่างเซสชัน และส่งข้อมูลนี้ไปยังแหล่งที่มาของสื่อในเซสชันและผู้เข้าร่วมเซสชันรายอื่น ๆ ข้อมูลดังกล่าวอาจถูกนำไปใช้โดยแหล่งที่มาเพื่อการเข้ารหัสสื่อแบบปรับเปลี่ยนได้ ( codec ) และการตรวจจับข้อผิดพลาดในการส่ง หากเซสชันดำเนินการผ่านเครือข่ายมัลติแคสต์ จะช่วยให้สามารถตรวจสอบคุณภาพของเซสชันได้โดยไม่รบกวนการทำงานของเซสชัน
• RTCP ให้ตัวระบุปลายทางมาตรฐาน (CNAME) แก่ผู้เข้าร่วมเซสชันทั้งหมด แม้ว่าตัวระบุแหล่งที่มา (SSRC) ของสตรีม RTP จะต้องไม่ซ้ำกัน แต่การเชื่อมโยงตัวระบุแหล่งที่มากับปลายทางในทันทีอาจเปลี่ยนแปลงได้ในระหว่างเซสชัน CNAME สร้างการระบุปลายทางที่ไม่ซ้ำกันในอินสแตนซ์ของแอปพลิเคชัน (การใช้งานเครื่องมือสื่อหลายครั้ง) และสำหรับการตรวจสอบโดยบุคคลที่สาม
• การจัดเตรียมฟังก์ชันควบคุมเซสชัน RTCP เป็นวิธีการที่สะดวกในการเข้าถึงผู้เข้าร่วมเซสชันทั้งหมด ในขณะที่ RTP นั้นไม่ใช่ RTP ถูกส่งผ่านโดยแหล่งสื่อเท่านั้น

คาดว่าผู้เข้าร่วมทั้งหมดจะส่งรายงาน RTCP แม้ในเซสชันแบบมัลติแคสต์ซึ่งอาจมีผู้รับหลายพันคน ปริมาณการรับส่งข้อมูลจะเพิ่มขึ้นตามสัดส่วนของจำนวนผู้เข้าร่วม ดังนั้น เพื่อหลีกเลี่ยงความแออัดของเครือข่าย โปรโตคอลจึงต้องมีการจัดการแบนด์วิดท์ของเซสชัน ซึ่งทำได้โดยการควบคุมความถี่ในการส่งรายงานแบบไดนามิก โดยทั่วไปแล้ว การใช้งานแบนด์วิดท์ RTCP ไม่ควรเกิน 5% ของแบนด์วิดท์ทั้งหมดของเซสชัน นอกจากนี้ ควรสงวนแบนด์วิดท์ RTCP ไว้ 25% สำหรับแหล่งข้อมูลสื่อตลอดเวลา เพื่อให้ในงานประชุมขนาดใหญ่ ผู้เข้าร่วมใหม่สามารถรับตัวระบุ CNAME ของผู้ส่งได้โดยไม่ล่าช้าเกินไป

ช่วงเวลาการรายงาน RTCP จะถูกสุ่มเพื่อป้องกันการซิงโครไนซ์การรายงานโดยไม่ตั้งใจ ช่วงเวลาการรายงาน RTCP ขั้นต่ำที่แนะนำต่อสถานีคือ 5 วินาที สถานีไม่ควรส่งรายงาน RTCP บ่อยกว่าหนึ่งครั้งทุกๆ 5 วินาที

เวอร์ชัน: 2 บิต

ระบุเวอร์ชันของ RTP ซึ่งเหมือนกันในแพ็กเก็ต RTCP เช่นเดียวกับในแพ็กเก็ตข้อมูล RTP เวอร์ชันที่กำหนดโดยข้อกำหนดนี้คือสอง (2)

การเติมข้อมูล (P): 1 บิต

ระบุว่ามีไบต์เสริม (padding bytes) เพิ่มเข้ามาที่ส่วนท้ายของแพ็กเก็ต RTP หรือไม่ ไบต์เสริมอาจใช้เพื่อเติมเต็มบล็อกที่มีขนาดตามที่กำหนด เช่น ตามที่อัลกอริทึมการเข้ารหัสต้องการ ไบต์สุดท้ายของไบต์เสริมจะมีจำนวนไบต์เสริมที่ถูกเพิ่มเข้ามา (รวมถึงตัวมันเองด้วย)

จำนวนรายงานการรับสัญญาณ (RC): 5 บิต

จำนวนบล็อกรายงานการรับที่อยู่ในแพ็กเก็ตนี้ ค่าศูนย์ถือว่าถูกต้อง

ประเภทแพ็กเก็ต (PT): 8 บิต

ประกอบด้วยค่าคงที่สำหรับระบุประเภทแพ็กเก็ต RTCP

ความยาว: 16 บิต

ระบุความยาวของแพ็กเก็ต RTCP นี้ (รวมถึงส่วนหัวด้วย) ในหน่วย 32 บิต ลบหนึ่ง

รหัส SSRC: 32 บิต

ตัวระบุแหล่งที่มาของการซิงโครไนซ์จะระบุแหล่งที่มาของสตรีมได้อย่างเฉพาะเจาะจง

โปรดทราบว่าสามารถรวมรายงานหลายฉบับเข้าไว้ในแพ็กเก็ต RTCP แบบผสมเดียวได้ โดยแต่ละรายงานจะมีส่วนหัวแพ็กเก็ตเป็นของตนเอง

RTCP แยกแยะแพ็กเก็ตหลายประเภท ได้แก่รายงานผู้ส่งรายงานผู้รับคำอธิบายแหล่งที่มาและลาก่อนนอกจากนี้ โปรโตคอลยังสามารถขยายได้และอนุญาตให้ใช้แพ็กเก็ต RTCP เฉพาะแอปพลิเคชัน ส่วนขยายตามมาตรฐานของ RTCP คือประเภทแพ็กเก็ตรายงานแบบขยาย^{[ 4 ​​]}

รายงานผู้ส่ง (SR)

รายงานผู้ส่งจะถูกส่งเป็นระยะโดยผู้ส่งที่ใช้งานอยู่ในการประชุมเพื่อรายงานสถิติการส่งและรับสำหรับแพ็กเก็ต RTP ทั้งหมดที่ส่งในช่วงเวลาดังกล่าว รายงานผู้ส่งประกอบด้วยการประทับเวลาสองแบบที่แตกต่างกัน การประทับเวลาสัมบูรณ์ ซึ่งแสดงโดยใช้รูปแบบการประทับเวลาของโปรโตคอลเวลาเครือข่าย (NTP) (ซึ่งเป็นวินาทีเทียบกับเที่ยงคืน UTC ในวันที่ 1 มกราคม 1900) และการประทับเวลา RTP ที่สอดคล้องกับเวลาเดียวกันกับการประทับเวลา NTP แต่มีหน่วยเดียวกันและมีค่าชดเชยแบบสุ่มเดียวกันกับการประทับเวลา RTP ในแพ็กเก็ตข้อมูลที่อธิบายโดยรายงานผู้ส่งนี้^{[ 3 ] : 12,37} การประทับเวลาสัมบูรณ์ช่วยให้ผู้รับสามารถซิงโครไนซ์ข้อความ RTP ได้ ซึ่งมีความสำคัญอย่างยิ่งเมื่อมีการส่งทั้งเสียงและวิดีโอพร้อมกัน เนื่องจากสตรีมเสียงและวิดีโอใช้การประทับเวลาสัมพัทธ์ที่เป็นอิสระต่อกัน

รายงานผู้รับ (RR)

รายงานผู้รับนี้มีไว้สำหรับผู้เข้าร่วมแบบไม่ส่งแพ็กเก็ต RTP โดยรายงานนี้จะแจ้งให้ผู้ส่งและผู้รับรายอื่น ๆ ทราบเกี่ยวกับคุณภาพของบริการ

คำอธิบายแหล่งที่มา (SDES)

ข้อความคำอธิบายแหล่งที่มาใช้สำหรับส่งรายการ CNAME ไปยังผู้เข้าร่วมเซสชัน นอกจากนี้ยังอาจใช้เพื่อระบุข้อมูลเพิ่มเติม เช่น ชื่อ ที่อยู่อีเมล หมายเลขโทรศัพท์ และที่อยู่ของเจ้าของหรือผู้ควบคุมแหล่งที่มา

ลาก่อน (BYE)

แหล่งสัญญาณส่งข้อความ BYE เพื่อปิดการถ่ายทอดสด ข้อความนี้ช่วยให้ปลายทางประกาศว่ากำลังออกจากงานประชุม แม้ว่าแหล่งสัญญาณอื่นจะสามารถตรวจจับการหายไปของแหล่งสัญญาณได้ แต่ข้อความนี้เป็นการประกาศโดยตรง และยังเป็นประโยชน์สำหรับผู้ควบคุมการผสมสื่ออีกด้วย

ข้อความเฉพาะแอปพลิเคชัน (APP)

ข้อความเฉพาะแอปพลิเคชันเป็นกลไกในการออกแบบส่วนขยายเฉพาะแอปพลิเคชันสำหรับโปรโตคอล RTCP

ในแอปพลิเคชันขนาดใหญ่ เช่นโทรทัศน์โปรโตคอลอินเทอร์เน็ต (IPTV) อาจเกิดความล่าช้าเป็นเวลานานมาก (นาทีถึงชั่วโมง) ระหว่างรายงาน RTCP เนื่องจากกลไกการควบคุมแบนด์วิดท์ RTCP ที่จำเป็นในการควบคุมความแออัด (ดู§ ฟังก์ชันโปรโตคอล ) ความถี่ที่ยอมรับได้มักจะน้อยกว่าหนึ่งครั้งต่อนาที ซึ่งอาจทำให้ผู้รับรายงานสถิติที่เกี่ยวข้องอย่างไม่เหมาะสม หรือทำให้ผู้ส่งสื่อประเมินไม่ถูกต้องเมื่อเทียบกับสถานะปัจจุบันของเซสชัน มีการนำวิธีการต่างๆ มาใช้เพื่อบรรเทาปัญหาเหล่านี้: ^{[ 5 ]}การกรอง RTCP, การให้อคติ RTCP และการรวมแบบลำดับชั้น^{[ 6 ]}

การรวมกลุ่มแบบลำดับชั้น (หรือที่รู้จักกันในชื่อลำดับชั้นการตอบรับ RTCP) เป็นการปรับปรุงโมเดลการตอบรับ RTCP และมีเป้าหมายเพื่อเลื่อนขีดจำกัดจำนวนผู้ใช้สูงสุดออกไปพร้อมกับ การวัด คุณภาพการบริการ (QoS) ^{[ 7 ] [ 8 ]}แบนด์วิดท์RTCP คงที่และใช้เพียง 5% ของแบนด์วิดท์เซสชัน ดังนั้นช่วงเวลาการรายงานเกี่ยวกับ QoS จึงขึ้นอยู่กับจำนวนสมาชิกเซสชัน และสำหรับเซสชันขนาดใหญ่มาก ช่วงเวลานี้อาจสูงมาก (นาทีหรือชั่วโมง) ^{[ 3 ]}อย่างไรก็ตาม ช่วงเวลาที่ยอมรับได้คือประมาณ 10 วินาทีของการรายงาน ค่าที่มากกว่านี้จะทำให้สถานะที่รายงานเกี่ยวกับสถานะเซสชันปัจจุบันคลาดเคลื่อนและไม่ถูกต้องมาก และการปรับปรุงใดๆ ที่ผู้ส่งทำอาจส่งผลเสียต่อสภาพเครือข่ายหรือ QoS ได้

การรวมกลุ่มแบบลำดับชั้น (Hierarchical Aggregation) ใช้กับมัลติแคสต์เฉพาะแหล่งที่มา (Source-Specific Multicast)ซึ่งอนุญาตให้มีแหล่งที่มาเพียงแหล่งเดียว เช่นIPTVมัลติแคสต์อีกประเภทหนึ่งคือมัลติแคสต์จากทุกแหล่งที่มา (Any-Source Multicast ) แต่ไม่ค่อยเหมาะสมสำหรับแอปพลิเคชันขนาดใหญ่ที่มีผู้ใช้จำนวนมาก

ณ เดือนมิถุนายน ปี 2550 มีเพียงระบบ IPTV รุ่นใหม่ล่าสุดเท่านั้นที่ใช้การรวมข้อมูลแบบลำดับชั้น (Hierarchical aggregation)

Feedback Target เป็นสมาชิกประเภทใหม่ที่ได้รับการแนะนำครั้งแรกโดย Internet Draft draft-ietf-avt-rtcpssm-13 ^{[ 9 ]}วิธีการรวมแบบลำดับชั้นได้ขยายฟังก์ชันการทำงานของสมาชิกนี้ หน้าที่ของสมาชิกนี้คือการรับรายงานผู้รับ (RR) (ดูRTCP ) และส่งแพ็กเก็ต RR ที่สรุปแล้ว ซึ่งเรียกว่าข้อมูลสรุปผู้รับ (RSI) ^{[ 9 ]}ไปยังผู้ส่ง (ในกรณีของลำดับชั้นระดับเดียว)

• RFC  3550 – " RTP: โปรโตคอลการขนส่งสำหรับแอปพลิเคชันแบบเรียลไทม์ " มาตรฐานอินเทอร์เน็ต 64

• สื่อสตรีมมิ่ง
• เสียงผ่านอินเทอร์เน็ต

• เพอร์กินส์, โคลิน (2003). RTP . แอดดิสัน-เวสลีย์. หน้า 414. ISBN 978-0-672-32249-5.
• Peterson, Larry L.; Bruce S. Davie (2007). เครือข่ายคอมพิวเตอร์ (ฉบับที่ 4). Morgan Kaufmann. หน้า 806. ISBN 978-0-12-374013-7.
• "RTCP"คู่มือโปรโตคอลเครือข่าย Javvin Technologies. 2005. ISBN 978-0-9740945-2-6.