Encoded Stream ID Header Extension
draft-pthatcher-avtext-esid-00

Abstract

This document 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 for extending RTP Payload Types.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on September 10, 2015.

Copyright Notice

Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 2. Terminology
• 3. RTP/RTCP extensions for ESID value transport
• 3.1. RTP ESID Header Extension
• 3.2. RTP ESID SDES Item
• 4. Representation as a fmt value
• 5. Examples
• 6. Security Considerations
• 7. IANA Considerations
• 8. Acknowledgements
• 9. Normative References
• Appendix A. Change log
• Author's Address

1. Introduction

SDP Offerers and Answerers [RFC3264] can assign fmt values to SDP Media Descriptions (m= lines) within SDP Offers and Answers, using the procedures in [RFC4566]. 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.

2. Terminology

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 [RFC2119].

3. RTP/RTCP extensions for ESID value transport

This section defines a new RTP SDES item [RFC3264], 'ESID', which is used to carry IDs for Encoded Streams values within RTCP SDES packets. This section also defines a new RTP header extension [RFC5285], 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.

3.1. RTP ESID Header Extension

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 [RFC5285].

3.2. RTP ESID SDES Item

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     ESID=TBD  |     length    | ESID value                  ...
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

4. Representation as a fmt 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.

5. Examples

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:

       v=0
       o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
       s=
       c=IN IP4 atlanta.example.com
       t=0 0
       m=video 10002 RTP/AVP 225 353
       a=rtpmap:225 VP8/90000
       a=rtpmap:353 VP8/90000

6. Security Considerations

TODO

7. IANA Considerations

[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:

       Value:      TBD
       Abbrev.:    ESID
       Name:       Encoded Stream Identification
       Reference:  RFCXXXX

8. Acknowledgements

9. Normative References

Appendix A. Change log

Author's Address