Voice over Internet Protocol (VoIP) is being increasingly used by customers for local, long distance and international calls. There are many potential points of failure in a VoIP network, such as device failures, overloaded devices, network failures, etc. All these weaknesses in VoIP networks contribute to call failure or voice quality issues, such as no voice, one way voice, disturbed voice, etc.
The Real-time Transport Protocol (RTP) defines a standardized packet format for delivering audio and video over the Internet. It was developed by the Audio-Video Transport Working Group of the IETF and first published in 1996 as RFC 1889, which was obsoleted in 2003 by RFC 3550.
In its conventional implementation, RTP does not have a standard TCP or User Datagram Protocol (UDP) port on which it communicates. The only standard that RTP obeys is that UDP communications are done via an even port and the next higher odd port is used for RTP Control Protocol (RTCP) communications. RTP can carry any data with real-time characteristics, such as interactive audio and video. Call setup and tear-down is usually performed by the conventional SIP protocol. The fact that RTP uses a dynamic port range makes it difficult for it to traverse firewalls.
RTP was originally designed as a multicast protocol, but has since been applied in many unicast applications. It is frequently used in streaming media systems as well as videoconferencing and push to talk systems, making RTP the technical foundation of the Voice-over-IP (VoIP) industry. RTP goes along with the RTCP and it's built on top of the User Datagram Protocol (UDP).
RTP Control Protocol (RTCP) is a sister protocol of the Real-time Transport Protocol (RTP). RTCP is defined in RFC 3550 (which obsoletes RFC 1889). RTCP, which stands for Real-time Transport Control Protocol, provides out-of-band control information for an RTP data flow. RTCP partners RTP in the delivery and packaging of multimedia data, but does not transport any data itself. RTCP is used periodically to transmit control packets to participants in a streaming multimedia session. The primary function of RTCP is to provide feedback on the quality of service being provided by RTP.
RTCP gathers statistics on a media connection and information such as bytes sent, packets sent, lost packets, jitter, feedback and round trip delay. An application may use this information to increase the quality of service perhaps by limiting flow, or maybe using a low compression codec instead of a high compression codec. RTCP is often used for quality of service (QoS) reporting.
With the popularity of voice-over-IP (VoIP), and increasing deployments of VoIP interconnections, there is a strong need for providing quality VoIP calls. This often involves monitoring media quality using RTCP statistics and reporting media quality for any corrective actions. Usually, the RTCP data packets follow the RTP data packet pathway. If the RTCP follows the RTP pathway, the conventional process of measuring round-trip time (RTT) will produce accurate results. The RTT can be one metric for determining the quality of the connection. There are several conventional devices, such as Gatekeeper, a conventional session border controller (SBC) in a flow around media mode, a Cisco Call Manager, etc., which handle only signaling data, but not media data. In these scenarios, both RTP and RTCP flow between endpoints or gateways directly.
Without RTCP statistics, these conventional devices are unable to know the media data transfer status, such as one-way voice, no voice, garbled voice, etc. Hence, these conventional devices are not able to report media status or take any corrective actions based on the media status. Such corrective actions can include a rerouting of the media data to avoid a problematic pathway. In addition, these conventional devices generate call detail records (CDRs). However, these CDRs do not currently contain media related information. If these devices could get access to RTCP statistics, the devices could monitor the media status, report media quality, and take any necessary corrective actions based on the media status. Additionally, if these devices could get access to RTCP statistics, the devices could include this information in the CDRs. The CDRs could be analyzed further to make billing decisions or to further handle similar calls with a rerouting, if required. Similarly, if these devices could get access to RTCP statistics, signaling only devices could have media inactivity detection mechanisms to help clear hung calls and to handle appropriate billing. What is needed is a way for signaling only devices to get the RTCP statistics from endpoints or gateways, so that these devices can monitor media status, report media status, take any necessary corrective actions based on the media status, report voice quality in the CDRs, and also assist with system debug.
USPTO Backgrounds
USPTO Backgrounds