Change:
This PR refactors the packet format in -double to be friendlier to implementations using double-unaware base transforms. Move the OHB to the payload of the packet Arrange the inner tag, OHB, and outer tag so that appending / truncation are the only transormations needed in the encryption / decryption process Remove support for E2E-protected header extensions, so that implementations don't need header-processing logic

Discussion:
4. <del> Any SRTP packet processed following these procedures MAY contain an Original Header Block (OHB) RTP header extension. The OHB contains the original values of any modified header fields and MUST be placed after any already-existing RTP header extensions. Placement of the OHB after any original header extensions is important so that the receiving endpoint can properly authenticate the original packet and any originally included RTP header extensions.  The receiving endpoint will authenticate the original packet by restoring the modified RTP header field values and header extensions.  It does this by copying the original values from the OHB and then removing the OHB extension and any other RTP header extensions that appear after the OHB extension. The Media Distributor is only permitted to modify the extension (X) bit, payload type (PT) field, and the RTP sequence number field. The OHB extension is either one octet in length, two octets in length, or three octets in length.  The length of the OHB indicates what data is contained in the extension. If the OHB is one octet in length, it contains the original PT field value.  In this case, the OHB has this form: Note that "R" indicates a reserved bit that MUST be set to zero when sending a packet and ignored upon receipt.  ID is the RTP Header Extension identifier negotiated in the SDP. If the OHB is two octets in length, it contains the original RTP packet sequence number.  In this case, the OHB has this form: If the OHB is three octets in length, it contains the original PT field value and RTP packet sequence number.  In this case, the OHB has this form: If a Media Distributor modifies an original RTP header value, the Media Distributor MUST include the OHB extension to reflect the changed value, setting the X bit in the RTP header to 1 if no header extensions were originally present.  If another Media Distributor along the media path makes additional changes to the RTP header and any original value is already present in the OHB, the Media Distributor must extend the OHB by adding the changed value to the OHB.  To properly preserve original RTP header values, a Media Distributor MUST NOT change a value already present in the OHB extension. </del> <ins> The Original Header Block (OHB) contains the original values of any modified header fields.  In the encryption process, the OHB is appended to the RTP payload.  In the decryption process, the receiving endpoint uses it to reconstruct the original RTP header, so that it can pass the proper AAD value to the inner transform. The OHB can reflect modifications to the following fields in an RTP header: the payload type, the sequence number, and the marker bit. All other fields in the RTP header MUST remain unmodified; since the OHB cannot reflect their original values, the receiver will be unable to verify the E2E integrity of the packet. The OHB has the following syntax (in ABNF): If present, the PT and SEQ parts of the OHB contain the original payload type and sequence number fields, respectively.  The final "config" octet of the OHB specifies whether these fields are present, and the original value of the marker bit (if necessary): In particular, an all-zero OHB config octet (0x00) indicates that there have been no modifications from the original header. </ins> 5.