RTP can be used for media on demand as well as for interactive services – internet telephony.
UDP at transport layer provides the port numbers: (session multiplexing) and header checksum. RTP adds time stamp and sequence number to the header information. So that packets are rearranged at the remote device end in the correct order (sequence number) and a buffer to handle jitter between packets to ensure smooth audio output (time stamp). Figure 1 show RTP head structure.
Figure 1: RTP header
The payload type field is used to designate type of RTP in use. We can use RTP for audio or video purpose. When two devices try to establish an audio session, for each RTP stream an even UDP port number is chosen (ranging from 16,384 to 32,677). RTP streams are one way, so in case of two way communication, two RTP streams, one in each direction will be used. The chosen port is fixed for the entire audio session and ports don’t change dynamically during the call. The table 1 shows the UDP port number ranges used by RTP:
|
UDP Port Range |
Start UDP Range |
End Used For |
|
0 |
16,383 |
Reserved
|
|
16,384 |
32,767 |
Audio |
|
32,768 |
49,151 |
Whiteboard |
|
49,152 |
65,535 |
Video |
The protocol delivers statistics information related to – packet count, packet delay, packet loss and jitter. RTP can carry interactive audio and video using dynamic port range which is makes it difficult to negotiate firewalls. RTP is used commonly for unicast sessions, but it is primarily designed for multicast sessions. So apart from roles of sender/receiver, it also define role for translator and mixer to support multicast sessions. RTP is used in streaming media systems, videoconferencing and push to talk systems. Applications relying on RTP are delay sensitive but less sensitive to packet loss, where preferred choice is UDP. RTP don’t send retransmission request if a packet is lost during the transport. Figure 2 illustrates role of RTP in VOIP networks.
Figure 2: Role of RTP in VOIP networks
Figure 2 is showing the typical role of RTP is VOIP network. RTP communicates directly between the endpoints, and call setup protocols (H.225 and H.245) are used for communication with voice gateways. RTP packet flows are known as RTP streams.
RTP has two parts data portion and header. The RTP data portion is thin which provides support for real time properties of applications namely continuous media, timing reconstruction, loss detection and content identification. The RTP header portion is large and heavy compared to the data portion. The header portion comprises of the IP segment, UDP segment and RTP segment. Combining all three segments and sending them across is an inefficient way of transmission, so the header IP/UDP/RTP is compressed. Figure 3 illustrates RTP header compression.
Figure 3: RTP header compression
The three segments (IP, UDP and RTP) each with size 20 bytes, 8 bytes and 12 bytes makes header size 40 byte. So the RTP packet has payload of 20 to 150 bytes for audio applications which use compressed payloads. The compression feature helps to reduce header size to 2 to 4 bytes.
- RFC 2508: dictates IP/UDP/RTP header compression on slow serial links
- RFC 2509: IP header compression on PPP
- RFC 3545: Enhanced compressed RTP (ECRTP) for links having high delays, packet loss and reordering
RFC 2509 was meant to work with reliable and fast point-to-point links. RTP header compression is supported over serial lines using frame relay, HDLC, PPP encapsulation including ISDN interfaces.
cRTP suppresses the sending of redundant information in voice streams rather than performing compression. When a VOIP call flow is established, every packet has same source/ destination IP address, UDP port number, RTP payload type. This information is redundant in nature and by caching this redundant information at each gateway, reduced header is sent and the reassembly of full header happens, this intends to bring in bandwidth savings without any loss of voice information.
Overhead for multimedia RTP traffic is reduced with RTP compression which further results in reduction in delay. On WAN links where bandwidth is a concern RTP header compression should be used. It can also be used for media on demand and interactive services like internet telephony. It supports for real time conferencing of groups of any size. RTP header compression is useful for both telephony voice and multicast backbone (MBONE) applications using slow links.
Secure RTP was published in IETF in year 2004 as RFC 3711. It provides encryption, message authentication, and integrity and replay protection to RTP data for both unicast/multicast applications.
sRTP has a sister protocol known as Secure RTCP to provide security related features to RTCP. sRTP is used in conjunction with compressed RTP. Figure 4 illustrates use of secure RTP
Figure 4: Use of secure RTP
sRTP is standard for single cipher only. Advanced Encryption standard (AES), which is to be used in two cipher modes, to turn the original block of AES cipher into a stream cipher
Segmented Integer Counter Mode -This allows random access to any blocks and required for RTP traffic on unreliable networks with possibility of packet loss. The default encryption key length is 128 bits and a default session salt key length of 112 bits
F8-Mode– – It is a variation of output feedback mode. Encryption key length and session salt key length is same as AES in counter mode
sRTP also gives the user ability to disable encryption outright, with the use of NULL cipher. NULL cipher doesn’t perform any encryption. The encryption stream copies the input stream to output stream without any changes. sRTP also ensures message integrity from replay.
Authentication and Integrity – Defined in RFC 2104 HMAC-SHA1 algorithm is used for authentication of a message and to ensure its integrity. This algorithm has 160 bit result, which is truncated to 80 bits as authentication tag which is appended to a packet.
Replay Protection – Replay attack protection requires that receiver has indices of previously received message and it is to be compared with the index of each newly received message to ensure its integrity.
Configuring RTP – RTP is configured in Interface configuration mode in Cisco IOS voice gateways and bandwidth is mentioned in Kbps reserved for a range of RTP ports. This is known as IP RTP priority feature. This feature allows specifying a range of UDP/RTP ports whose traffic follows a strict priority queuing scheme over any other queues using same output interface such as data. Voice traffic is assigned priority in the queue and they are sent first.
Knowing voice port call is not necessary to use the IP RTP Priority feature, as it gives the ability to identify a range of ports whose traffic is put into the priority queue. We can specify the entire voice port range—16384 to 32767—to ensure that all voice traffic is given strict priority service. This feature is quite useful on slow-speed links whose speed is less than 1.544 Mbps. This is used in conjunction with either Weighted Fair Queuing (WFQ) or Class-Based WFQ (CBWFQ) on the same outgoing interface. In both cases, traffic matching the range of ports specified for the priority queue is guaranteed strict priority over other CBWFQ classes or WFQ flows; packets in the priority queue are always serviced first.
- When IP RTP priority is used with WFQ, it provides strict priority to voice, and WFQ scheduling is applied to the remaining queues.
- When IP RTP priority is used with CBWFQ, it provides strict priority to voice.
To reserve a strict priority queue for a set of RTP packet flows for a range of UDP destination ports, following command is used in interface configuration mode:
Router(config-if)# ip rtp priority
starting-rtp-port-number port-number-range bandwidth
Maximum reserved bandwidth allocated for CBWFQ and the IP RTP Priority feature can be changed using the following command in interface configuration mode:
Router(config-if)# max-reserved-bandwidth percent
To view contents of the priority queue (such as queue depth and the first packet queued), following command in EXEC mode:
Router# show queue interface-type interface-number
To fine tune RTP bandwidth or decrease RTP traffic in case the priority queue is having packet drops, following commands can be used in EXEC mode:
Router# debug priority
Router# show queue interface-type interface-number
Configuring RTP header compression
In RTP header compression we can configure maximum size of the compressed IP header, the maximum time between transmitting full-header packets, and the maximum number of compressed packets between full headers. These settings are configured using the following three commands:
Router(config-if)# ip header-compression max-header
Router(config-if)# ip header-compression max-time
Router(config-if)# ip header-compression max-period
The ip header-compression max-header command allows you to define the maximum size of the IP header of a packet to be compressed. Any packet with an IP header that exceeds the highest size is sent uncompressed. With the ip header-compression max-time command we can specify the maximum time between transmitting full-header packets, and the ip header-compression max-period command let us specify the maximum number of compressed packets between full headers.
We can specify circumstances under which the RTP packets are compressed and the format that is used when the packets are compressed. These circumstances and formats are defined by the following described as under:
Passive – As default setting, the ip rtp header-compression command compresses outgoing RTP traffic. With passive keyword, outgoing RTP traffic is compressed only if incoming RTP traffic on the same interface is compressed. The passive keyword is ignored on PPP interfaces.
IPHCFormat – The iphc-format keyword states that the IP Header Compression (IPHC) format of header compression will be used. For PPP and HDLC interfaces, with this keyword, TCP header compression is also enabled and both UDP and TCP packets are compressed.
UETF Format – The ietf-format keyword states that the Internet Engineering Task Force (IETF) format of header compression will be used. For HDLC interfaces, the ietf-format keyword compresses only UDP packets. For PPP interfaces, when the ietf-format keyword is specified, TCP header compression is also enabled and both UDP and TCP packets are compressed.
RTCP – Real time control protocol – Each RTP stream is go along with RTCP stream. RTCP is meant for monitoring the quality of the RTP stream, and allows devices to record parameters such as packet count, loss and jitter. This protocol was initial defined in RFC 1889 and was replaced with RFC 3550. It does not transport any data on itself but used to transmit control packets in a streaming multimedia session to participants, its main function is providing feedback on RTP quality of service. Qos reporting uses RTCP protocol, to gather statistics on a media connection and information, which is used to improve the quality of service by use of low compression codec instead of a high compression codec. RTCP packets can be of multiple types such as: send report packet, receiver report packet, source destination RTCP packet, goodbye RTCP packet and application specific RTCP packet. These types are described in detail below:
Sender Report (SR) – Periodically the send report is sent by the active senders in a conference to report transmission and reception statistics for all RTP packets sent during the interval. The sender report comprises of an absolute timestamp, which is the number of seconds elapsed while midnight on January 1, 1900. The absolute timestamp let the receiver to synchronize RTP messages during simultaneously transmission of audio/video, it is quite important because audio/video streams use independent relative timestamps.
Receiver Report (RR) – It is for passive participants, who don’t send RTP packets. The report intimates sender / receivers on the quality of service.
Source Description (SDES) – This is used to send the CNAME item to session participants. It provides other information such as the name, e-mail address, telephone number, and address of the owner or controller of the source.
End of Participation (BYE) – BYE message send to shut down a stream. It permits an endpoint to announce that it is leaving the conference session and it is like a direct announcement and useful to media mixer
Application-Specific Message (APP) – This provides a means to design application-specific extensions to the RTCP protocol.
RTCP provides feedback on current network conditions which are described as:
RTCP provides a means for hosts involved in a session (RTP based) to exchange information on monitoring/ controlling of session. It monitors the quality of session with specific parameters such as packet count, packet loss, jitter, delay. RTCP sends packets at a specific rate of at least every 5 seconds as percentage of session bandwidth.
RTCP packet contains NTP (network time protocol) which indicates time stamps are based on synchronized clocks.
RTCP is assigned an odd numbered port as against even number port for RTP hence a separate transmission channel. So each voice call has four ports assigned RTP and RTCP in transmit direction and RTP and RTCP in receiving direction.
RTCP on its own don’t provide any flow encryption or authentication methods. Such mechanisms may be implemented, for example, with the Secure Real-time Transport Protocol (SRTP) as per RFC 3711.
This concludes our CCNA Voice lesson on voice protocols and standard rules of communication in a voice network.