rtp header

rtp協議基於udp傳輸，流媒體音視頻數據被封裝在rtp中，經過rtp協議進行實時的傳輸。

1、rtp協議頭格式

The RTP header has a minimum size of 12 bytes. After the header, optional header extensions may be present. This is followed by the RTP payload, the format of which is determined by the particular class of application.^[20] The fields in the header are as follows:

• Version: (2 bits) Indicates the version of the protocol. Current version is 2.^[21]
• P (Padding): (1 bit) Used to indicate if there are extra padding bytes at the end of the RTP packet. A padding might be used to fill up a block of certain size, for example as required by an encryption algorithm. The last byte of the padding contains the number of padding bytes that were added (including itself).^[13]:12[21]
• X (Extension): (1 bit) Indicates presence of an Extension header between standard header and payload data. This is application or profile specific.^[21]
• CC (CSRC count): (4 bits) Contains the number of CSRC identifiers (defined below) that follow the fixed header.^[13]:12
• M (Marker): (1 bit) Used at the application level and defined by a profile. If it is set, it means that the current data has some special relevance for the application.^[13]:13
• PT (Payload type): (7 bits) Indicates the format of the payload and determines its interpretation by the application. This is specified by an RTP profile. For example, see RTP Profile for audio and video conferences with minimal control(RFC 3551).^[22]
• Sequence number: (16 bits) The sequence number is incremented by one for each RTP data packet sent and is to be used by the receiver to detect packet loss and to restore packet sequence. The RTP does not specify any action on packet loss; it is left to the application to take appropriate action. For example, video applications may play the last known frame in place of the missing frame.^[23] According to RFC 3550, the initial value of the sequence number should be random to make known-plaintext attacks on encryption more difficult.^[13]:13 RTP provides no guarantee of delivery, but the presence of sequence numbers makes it possible to detect missing packets.^[1]
• Timestamp: (32 bits) Used by the receiver to play back the received samples at appropriate time and interval. When several media streams are present, the timestamps may be independent in each stream.^[b] The granularity of the timing is application specific. For example, an audio application that samples data once every 125 µs (8 kHz, a common sample rate in digital telephony) would use that value as its clock resolution. Video streams typically use a 90 kHz clock. The clock granularity is one of the details that is specified in the RTP profile for an application.^[23]
• SSRC: (32 bits) Synchronization source identifier uniquely identifies the source of a stream. The synchronization sources within the same RTP session will be unique.^[13]:15
• CSRC: (32 bits each, number indicated by CSRC count field) Contributing source IDs enumerate contributing sources to a stream which has been generated from multiple sources.^[13]:15
• Header extension: (optional, presence indicated by Extension field) The first 32-bit word contains a profile-specific identifier (16 bits) and a length specifier (16 bits) that indicates the length of the extension (EHL = extension header length) in 32-bit units, excluding the 32 bits of the extension header.^[13]:17

上面針對rtp頭的解釋，最爲重要的就是seq 和 timestamp，seq須要保證連續，timestamp對視頻數據來講，須要時間毫秒數 x 90,

 對於音頻則是時間毫秒數 x 80

2、rtp協議頭定義

rtp協議頭字節序爲網絡字節序，也就是大端模式：

rfc3550中的rtp頭結構體定義

 1  /*
 2  * RTP data header  3     */
 4    typedef struct {  5        unsigned int version:2;   /* protocol version */
 6        unsigned int p:1;         /* padding flag */
 7        unsigned int x:1;         /* header extension flag */
 8        unsigned int cc:4;        /* CSRC count */
 9        unsigned int m:1;         /* marker bit */
10        unsigned int pt:7;        /* payload type */
11        unsigned int seq:16;      /* sequence number */
12        u_int32 ts;               /* timestamp */
13        u_int32 ssrc;             /* synchronization source */
14        u_int32 csrc[1];          /* optional CSRC list */
15    } rtp_hdr_t;

 

rtp封包時，通常設置version, payloadtype,seq,timestamp,ssrc 便可。

能夠按照大端模式直接填充上述的結構體

也能夠直接封包，下面的例子:

 1 // Prepare the 12 byte RTP header
 2   RtpBuf[0]  = 0x80;                               // RTP version
 3   RtpBuf[1]  = 0x1a + (marker_bit << 7);           // JPEG payload (26) and marker bit
 4   RtpBuf[2]  = m_SequenceNumber >> 8;  5   RtpBuf[3]  = m_SequenceNumber & 0x0FF;           // each packet is counted with a sequence counter
 6   RtpBuf[4]  = (m_Timestamp & 0xFF000000) >> 24;   // each image gets a timestamp
 7   RtpBuf[5]  = (m_Timestamp & 0x00FF0000) >> 16;  8   RtpBuf[6]  = (m_Timestamp & 0x0000FF00) >> 8;  9   RtpBuf[7]  = (m_Timestamp & 0x000000FF); 10   RtpBuf[8]  = 0x13;                               // 4 byte SSRC (sychronization source identifier)
11   RtpBuf[9]  = 0xf9;                               // we just an arbitrary number here to keep it simple
12   RtpBuf[10] = 0x7e; 13   RtpBuf[11] = 0x67;

 

3、wireshark抓包出的rdp包，能夠根據包頭的版本號和負載類型篩選出rtp包

 

0x80 =1000 0000  version = 2 

0x7f  =1111 1111

0x00 01 = 0000 0000 0000 0001 seq = 1

0xa5 be c7 60 = 10100101101111101100011101100000  timestamp = 2780743520

 

引用:

一、https://en.wikipedia.org/wiki/Real-time_Transport_Protocol

二、https://tools.ietf.org/html/rfc3550