Packet Validation

It is important to validate whether received packets really are RTP or RTCP. The packing rules, mentioned earlier, allow RTCP packets to be rigorously validated . Successful validation of an RTCP stream gives high assurance that the corresponding RTP stream is also valid, although it does not negate the need for validation of the RTP packets.

Listing 5.1 shows the pseudocode for the validation process. These are the key points:

• All packets must be compound RTCP packets.

• The version field of all packets must equal 2.

• The packet type field of the first RTCP packet in a compound packet must be equal to SR or RR.

• If padding is needed, it is added to only the last packet in the compound. The padding bit should be zero for all other packets in the compound RTCP packet.

• The length fields of the individual RTCP packets must total the overall length of the compound RTCP packet as received.

Because new RTCP packet types may be defined by future profiles, the validation procedure should not require each packet type to be one of the five defined in the RTP specification.

Listing 5.1 Pseudocode for Packet Validation

 validate_rtcp(rtcp_t *packet, int length)     rtcp_t    *end  = (rtcp_t *) (((char *) packet) + length);     rtcp_t    *r    = packet;     int         l    = 0;     int         p    = 0;     // All RTCP packets must be compound packets     if ((packet->length+ 1) * 4) == length) {         ... error: not a compound packet     }     // Check the RTCP version, packet type, and padding of the first     // in the compound RTCP packet...     if (packet->version != 2) {         ...error: version number != 2 in the first subpacket     }     if (packet-> p != 0) {         ...error: padding bit is set on first packet in compound     }     if ((packet->pt != RTCP_SR) && (packet->pt != RTCP_RR)) {         ...error: compound packet does not start with SR or RR     }     // Check all following parts of the compound RTCP packet. The RTP     // version number must be 2, and the padding bit must be zero on     // all except the last packet.     do {         if (p == 1) {             ...error: padding before last packet in compound         }         if (r-> p) {             p = 1;         }         if (r-> version != 2) {             ...error: version number != 2 in subpacket         }         l += (r->length + 1) * 4;         r  = (rtcp_t *) (((uint32_t *) r) + r->length + 1);     } while (r < end);     // Check that the length of the packets matches the length of the     // UDP packet in which they were received...     if ((l != length)  (r != end)) {         ...error: length does not match UDP packet length     }       ...packet is valid } 

One common implementation problem causes packets to fail their validity test: When you're padding compound RTCP packets beyond their natural length, you need to ensure that the padding is added to only the last packet in the compound. A common mistake has been to add the padding to the last packet, but to set the P bit in the header of the first packet in the compound. The P bit must be set only in the last packet.

It is possible to detect RTCP misdirected onto the RTP port via the packet type field. The standard RTCP packets have packet type values with the high bit set; if they are misdirected onto the RTP port, the high bit of the packet type field will fall into the place of the M bit in the RTP header. With the top bit stripped, the standard RTCP packet types correspond to an RTP payload type in the range 72 to 76. This range is reserved in the RTP specification and will not be used for valid RTP data packets, so detection of packets in this range implies that the stream is misdirected. Similarly, RTP packets sent to the RTCP port may clearly be distinguished by their packet type, which will be outside the valid range for RTCP packet types.