Read the abstract, see who wrote it and who cites it, and get the citation in APA, MLA, Chicago or Harvard.
About 309 papers for “RTP Control Protocol”
Group T. Friedman · 2003
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards " (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice
Cited by 0
Boronat Segui, Fernando · RiuNet (Universitat Politècnica de València) · 2016
En el objeto se presentan las diferentes funciones del protocolo RTCP, así como los tipos de paquetes empleados y cómo se envían.
Cited by 0
Source-specific Multicast (ssm Sessions · 2015
The Session Description Protocol (SDP) has an attribute that allows RTP applications to specify an address and a port associated with the RTP Control Protocol (RTCP) traffic. In RTP-based source-specific multicast (SSM) sessions, the same attribute is used to designate the address and the RTCP port of the Feedback Target in the SDP description. However, the RTCP port associated with the SSM session itself cannot be specified by the same attribute to avoid ambiguity, and thus, is required to be derived from the "m= " line of the media description. Deriving the RTCP port from the "m= " line imposes an unnecessary restriction. This document removes this restriction by introducing a new SDP attribute.
Cited by 0
Colin Perkins, Ladan Gharai · 2006
We describe how the new datagram congestion control protocol (DCCP) can be used as a bearer for the real-time transport protocol (RTP) to provide a congestion controlled basis for networked multimedia applications. This is a step towards deployment of congestion control for such applications, necessary to ensure the future stability of the best-effort network if high-bandwidth streaming and IPTV services are to be deployed outside of closed QoS-managed networks
Cited by 10
Timur Friedman, Ramón Cáceres, Alan Clarke · 2003
Internet Draft
Cited by 169
Munawal Ulfiyanto · 2003
Cited by 1
Request Comments, D. Hsu · 2010
This document defines a new report block type within the framework of RTP Control Protocol (RTCP) Extended Reports (XRs). One of the initial XR report block types is the Loss Run Length Encoding (RLE) Report Block. This report conveys information regarding the individual Real-time Transport Protocol (RTP) packet receipt and loss events experienced during the RTCP interval preceding the transmission of the report. The new report, which is referred to as the Post-repair Loss RLE report, carries information regarding the packets that remain lost after all loss-repair methods are applied. By comparing the RTP packet receipts/losses before and after the loss repair is completed, one can determine the effectiveness of the loss-repair methods in an aggregated fashion. This document also defines the signaling of the Post-repair Loss RLE report in the Session Description Protocol (SDP).
Cited by 0
Boronat Segui, Fernando · RiuNet (Universitat Politècnica de València) · 2016
En el ojeto se presentan los tipos de paquete de informe RTCP (reports), su formato, así como también su utilidad.
Cited by 0
S. Casner · 2003
This document defines an extension to the Session Description Protocol (SDP) to specify two additional modifiers for the bandwidth attribute. These modifiers may be used to specify the bandwidth allowed for RTP Control Protocol (RTCP) packets in a Real-time Transport Protocol (RTP) session.
Cited by 25
Colin Perkins · ENLIGHTEN (Jurnal Bimbingan dan Konseling Islam) · 2023
This memo discusses the rate at which congestion control feedback can be sent using the RTP Control Protocol (RTCP) and the suitability of RTCP for implementing congestion control for unicast multimedia applications.
Cited by 2Open access
Ray van Brandenburg, Hans Stokking, Oskar van Deventer et al. · 2014
This document defines a new RTP Control Protocol (RTCP) Packet Type and an RTCP Extended Report (XR) Block Type to be used for achieving Inter-Destination Media Synchronization (IDMS). IDMS is the process of synchronizing playout across multiple media receivers. Using the RTCP XR IDMS Report Block defined in this document, media playout information from participants in a synchronization group can be collected. Based on the collected information, an RTCP IDMS Settings Packet can then be sent to distribute a common target playout point to which all the distributed receivers, sharing a media experience, can synchronize. Typical use cases in which IDMS is useful are social TV, shared service control (i.e., applications where two or more geographically separated users are watching a media stream together), distance learning, networked video walls, networked loudspeakers, etc.
Cited by 8
T. Friedman, R. Caceres · 2003
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards " (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. This document defines the Extended Report (XR) packet type for the RTP Control Protocol (RTCP), and defines how the use of XR packets can be signaled by an application if it employs the Session Description Protocol (SDP). XR packets are composed of report blocks, and seven block types are defined here. The purpose of the extended reporting format is to convey information that supplements the six statistics that are contained in the report blocks used by
Cited by 0
J. Ott, S. Wenger, N. Sato et al. · 2006
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards " (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2006). Real-time media streams that use RTP are, to some degree, resilient against packet losses. Receivers may use the base mechanisms of the Real-time Transport Control Protocol (RTCP) to report packet reception statistics and thus allow a sender to adapt its transmission behavior in the mid-term. This is the sole means for feedback and feedback-based error repair (besides a few codecspecific mechanisms). This document defines an extension to the
Cited by 0
Joonwoo Park, Jaehyun Park · IFAC Proceedings Volumes · 2000
Cited by 1
J. Ott, Status Of This Memo · 2008
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards " (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. An RTP profile (SAVP) for secure real-time communications and another profile (AVPF) to provide timely feedback from the receivers to a sender are defined in RFC 3711 and RFC 4585, respectively. This memo specifies the combination of both profiles to enable secure RTP
Cited by 0
Jörg Ott, Julian Chesterfield, E. Schooler · 2010
This document specifies an extension to the Real-time Transport Control Protocol (RTCP) to use unicast feedback to a multicast sender. The proposed extension is useful for single-source multicast sessions such as Source-Specific Multicast (SSM) communication where the traditional model of many-to-many group communication is either not available or not desired. In addition, it can be applied to any group that might benefit from a sender-controlled summarized reporting mechanism.
Cited by 21
Zheng Hui, Rachel Huang, Rong Gu et al. · 2017
This document defines a new metric for RTP applications to measure the effectiveness of stream repair means, and an RTP Control Protocol (RTCP) Extended Report (XR) Block to report the metric.
Cited by 0
Ali C. Begen, Elisabeth V. C. Friedrich · 2011
In most RTP-based multicast applications, the RTP source sends inter- related data. Due to this interdependency, randomly joining RTP receivers usually cannot start consuming the multicast data right after they join the session. Thus, they often experience a random acquisition delay. One approach to reduce this delay is to receive a burst stream from a retransmission server that facilitates rapid acquisition of the multicast stream. An RTP receiver may use this approach (or any other approach) to achieve rapid acquisition. Yet, due to various factors, performance of the rapid acquisition methods usually varies. Furthermore, in some cases the RTP receiver may (or may have to) do a simple multicast join. For quality reporting, monitoring and diagnostics purposes, it is important to collect detailed information from the RTP receivers about their acquisition and presentation experiences. This document addresses this issue by defining a new report block type, called Multicast Acquisition (MA) Report Block, within the framework of RTP Control Protocol (RTCP) Extended Reports (XR) (RFC 3611). This document also defines the necessary signaling of the new MA report block type in the Session Description Protocol (SDP).
Cited by 1
Alan Clark, S. Zhang, Jiayi Zhao · 2013
Cited by 6
R. Huang · 2016
This document defines a new RTP Control Protocol (RTCP) Extended Report (XR) block that allows the reporting of loss concealment metrics for video applications of RTP.
Cited by 0