4 Background

26.1393GPPReal-time Transport Protocol (RTP) / RTP Control Protocol (RTCP) verification proceduresRelease 17TS

Today’s 3GPP conversational and real-time services (e.g. MTSI [9] and mission critical services) all use the RTP protocol [2] or the Secure RTP protocol [5] on top of UDP/IP as media transport. (S)RTP has a companion control protocol, (S)RTCP (also in [2] and [5]), which is optional but is typically also used. In the rest of the present document, only the terms RTP/RTCP are used for brevity but should be understood to be equally applicable to SRTP/SRTCP if nothing else is said.

RTCP provides means to feedback statistical characteristics of a received RTP stream from RTP receiver to RTP sender, and to carry RTP stream metadata from RTP sender to RTP receiver, both during an active RTP session and in hold conditions where no RTP is sent. While RTP/RTCP information is designed to be useful to an ongoing real-time media session, the increased focus on automation and the consequential need for service observability and automatic performance measurements also makes it convenient and common to use RTP header and RTCP as one of the information sources to monitor the RTP streams for automation purposes. This is a very straightforward approach since it was one of the very design targets for RTP/RTCP, and both RTCP and RTP are extensible and can optionally carry various types of information. Service observability is paramount to enable any tuning or optimization to achieve a well-functioning system.

However, RTCP information has little or no end-user impact on basic, single-media communication services such as a voice-only call. The reasons for this are mainly twofold:

1) One of the intended usages of RTCP feedback reporting functionality is to allow the RTP sender to adapt its sending rate to available transport capacity since a non-acknowledged transport such as UDP/IP has no built-in congestion control, but most voice-only calls today are both low-rate and fixed-rate that has no use for adaptation; and

2) One of the other intended usages of RTCP is to provide enough metadata information to allow close time synchronization of different RTP streams, such as e.g. voice and video for a video call, but a voice-only call is single-media and has no use for such time synchronization.

Therefore, there is often no direct impact on the voice service performance if a UE or network-node implementation of the RTP stack includes incorrect (e.g. all-zero or random) data in RTCP for a voice-only call. RTCP information content only matters on service level when really making use of RTCP functionality such as for quality monitoring, somehow acting on varying transport characteristics (loss, delay, jitter), or when performing inter-media synchronization.

Also, while the call setup and modification protocol, SIP/SDP, is conformance tested in 3GPP scope (by TSG RAN WG5), no media-level tests are defined or performed there when the present document is written. RTP and RTCP are considered as media-level protocols in that conformance testing. The current overall level of RTCP implementation conformance and accuracy in 3GPP devices and in RTP/RTCP-terminating network nodes is therefore mostly unknown.

Since the information content in RTP/RTCP is often neither fundamental for the user-level experience nor explicitly tested today, there is a risk that automation, performance tuning efforts, and the application using the RTP/RTCP stack will work with incorrect data, potentially making wrong decisions that could result in worse rather than better performance.