rtp header

rtp协议基于udp传输，流媒体音视频数据被封装在rtp中，通过rtp协议进行实时的传输。

一、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

二、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;

 

三、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

 

引用:

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

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

转载于:https://www.cnblogs.com/Forever-Kenlen-Ja/p/9473737.html