Encoded Stream ID Header Extension

SDP Offerers and Answerers can assign fmt values to SDP Media Descriptions (m= lines) within SDP Offers and Answers, using the procedures in . Each fmt uniquely identifies a media format, which is typically an RTP payload type. fmt values are also used to identity an Encoded Stream, where each combination of (Media Format, Encoded Stream) is represented as a unique fmt value. For large numbers of Media Formats and Encoded Streams, the number of fmts then can exceed what can typically fit in an RTP payload type. This specification defines a new RTP Header Extension and SDES item for an Encoded Stream ID or "ESID" which can be used for either identifying Encoded Streams or extending RTP Payload Types. It also defines how these map to fmt values.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .

This section defines a new RTP SDES item , 'ESID', which is used to carry IDs for Encoded Streams values within RTCP SDES packets. This section also defines a new RTP header extension , which can be used to carry the ESID value in RTP packets. The SDES item and RTP header extension makes is possible for a receiver to associate received RTCP- and RTP packets with a specific Encoded Stream. The RTP MID SDES item SHOULD be sent in the first few RTCP packets sent on joining the session, and SHOULD be sent regularly thereafter. The exact number of RTCP packets in which this SDES item is sent is intentionally not specified here, as it will depend on the expected packet loss rate, the RTCP reporting interval, and the allowable overhead. The RTP ESID header extension SHOULD be included in some RTP packets at the start of the session and whenever the SSRC changes. It might also be useful to include the header extension in RTP packets that comprise random access points in the media (e.g., with video I-frames). The exact number of RTP packets in which this header extension is sent is intentionally not specified here, as it will depend on expected packet loss rate and loss patterns, the overhead the application can tolerate, and the importance of immediate receipt of the ESID value. For robustness purpose, endpoints need to be prepared for situations where the ESID value is delayed, and SHOULD NOT terminate sessions in such cases, as the ESID value is likely to arrive soon.

The payload, containing the ESID value, of the RTP ESID header extension element can be encoded using either the one-byte or two- byte header .

[RFC EDITOR NOTE: Please replace TBD with the assigned SDES identifier value.]

NOTE: The usage of other signalling protocols for carrying the ESID value is not prevented, but the usage of such protocols is outside the scope of this document. fmt values typically do not exceed 127, the limit of the value that can be reprsented by an RTP payload type. The ESID allows for values for fmt larger than 127, calculated from the ESID and the RTP payload type in the following way. The value of the ESID is treated as a big-endian integer, which is then shifted left 7 bits and added to the value of the RTP payload type. This integer value is then used as the fmt value in the SDP.

For an ESID value of 1 and 2 and a Payload Type of 97, the fmt values of (1 << 7) + 97 = 225 and (2 << 7) + 97 = 353 would be used:

TODO

[RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this document.] [RFC EDITOR NOTE: Please replace TBD with the assigned SDES identifier value.] This document adds the MID SDES item to the IANA "RTP SDES item types" registry as follows: