diff options
Diffstat (limited to 'doc/rfc/rfc8851.txt')
| -rw-r--r-- | doc/rfc/rfc8851.txt | 1309 |
1 files changed, 1309 insertions, 0 deletions
diff --git a/doc/rfc/rfc8851.txt b/doc/rfc/rfc8851.txt new file mode 100644 index 0000000..f783403 --- /dev/null +++ b/doc/rfc/rfc8851.txt @@ -0,0 +1,1309 @@ + + + + +Internet Engineering Task Force (IETF) A.B. Roach, Ed. +Request for Comments: 8851 Mozilla +Updates: 4855 January 2021 +Category: Standards Track +ISSN: 2070-1721 + + + RTP Payload Format Restrictions + +Abstract + + In this specification, we define a framework for specifying + restrictions on RTP streams in the Session Description Protocol + (SDP). This framework defines a new "rid" ("restriction identifier") + SDP attribute to unambiguously identify the RTP streams within an RTP + session and restrict the streams' payload format parameters in a + codec-agnostic way beyond what is provided with the regular payload + types. + + This specification updates RFC 4855 to give additional guidance on + choice of Format Parameter (fmtp) names and their relation to the + restrictions defined by this document. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc8851. + +Copyright Notice + + Copyright (c) 2021 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 + (https://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. Terminology + 2. Introduction + 3. Key Words for Requirements + 4. SDP "a=rid" Media Level Attribute + 5. "a=rid" Restrictions + 6. SDP Offer/Answer Procedures + 6.1. Generating the Initial SDP Offer + 6.2. Answerer Processing the SDP Offer + 6.2.1. "a=rid"-Unaware Answerer + 6.2.2. "a=rid"-Aware Answerer + 6.3. Generating the SDP Answer + 6.4. Offerer Processing of the SDP Answer + 6.5. Modifying the Session + 7. Use with Declarative SDP + 8. Interaction with Other Techniques + 8.1. Interaction with VP8 Format Parameters + 8.1.1. max-fr - Maximum Frame Rate + 8.1.2. max-fs - Maximum Frame Size, in VP8 Macroblocks + 8.2. Interaction with H.264 Format Parameters + 8.2.1. profile-level-id and max-recv-level - Negotiated + Subprofile + 8.2.2. max-br / MaxBR - Maximum Video Bitrate + 8.2.3. max-fs / MaxFS - Maximum Frame Size, in H.264 + Macroblocks + 8.2.4. max-mbps / MaxMBPS - Maximum Macroblock Processing Rate + 8.2.5. max-smbps - Maximum Decoded Picture Buffer + 8.3. Redundancy Formats and Payload Type Restrictions + 9. Format Parameters for Future Payloads + 10. Formal Grammar + 11. SDP Examples + 11.1. Many Bundled Streams Using Many Codecs + 11.2. Scalable Layers + 12. IANA Considerations + 12.1. New SDP Media-Level Attribute + 12.2. Registry for RID-Level Parameters + 13. Security Considerations + 14. References + 14.1. Normative References + 14.2. Informative References + Acknowledgements + Contributors + Author's Address + +1. Terminology + + The terms "source RTP stream", "endpoint", "RTP session", and "RTP + stream" are used as defined in [RFC7656]. + + [RFC4566] and [RFC3264] terminology is also used where appropriate. + +2. Introduction + + The payload type (PT) field in RTP provides a mapping between the RTP + payload format and the associated SDP media description. For a given + PT, the SDP rtpmap and/or fmtp attributes are used to describe the + properties of the media that is carried in the RTP payload. + + Recent advances in standards have given rise to rich multimedia + applications requiring support for either multiple RTP streams within + an RTP session [RFC8843] [RFC8853] or a large number of codecs. + These demands have unearthed challenges inherent with: + + * The restricted RTP PT space in specifying the various payload + configurations + + * The codec-specific constructs for the payload formats in SDP + + * Missing or underspecified payload format parameters + + * Overloading of PTs to indicate not just codec configurations, but + individual streams within an RTP session + + To expand on these points: [RFC3550] assigns 7 bits for the PT in the + RTP header. However, the assignment of static mapping of RTP payload + type numbers to payload formats and multiplexing of RTP with other + protocols (such as the RTP Control Protocol (RTCP)) could result in a + limited number of payload type numbers available for application + usage. In scenarios where the number of possible RTP payload + configurations exceeds the available PT space within an RTP session, + there is a need for a way to represent the additional restrictions on + payload configurations and effectively map an RTP stream to its + corresponding restrictions. This issue is exacerbated by the + increase in techniques -- such as simulcast and layered codecs -- + that introduce additional streams into RTP sessions. + + This specification defines a new SDP framework for restricting source + RTP streams (Section 2.1.10 of [RFC7656]), along with the SDP + attributes to restrict payload formats in a codec-agnostic way. This + framework can be thought of as a complementary extension to the way + the media format parameters are specified in SDP today, via the + "a=fmtp" attribute. + + The additional restrictions on individual streams are indicated with + a new "a=rid" ("restriction identifier") SDP attribute. Note that + the restrictions communicated via this attribute only serve to + further restrict the parameters that are established on a PT format. + They do not relax any restrictions imposed by other mechanisms. + + This specification makes use of the RTP Stream Identifier Source + Description (SDES) RTCP item defined in [RFC8852] to provide + correlation between the RTP packets and their format specification in + the SDP. + + As described in Section 6.2.1, this mechanism achieves backwards + compatibility via the normal SDP processing rules, which require + unknown "a=" lines to be ignored. This means that implementations + need to be prepared to handle successful offers and answers from + other implementations that neither indicate nor honor the + restrictions requested by this mechanism. + + Further, as described in Section 6 and its subsections, this + mechanism achieves extensibility by: (a) having offerers include all + supported restrictions in their offer, and (b) having answerers + ignore "a=rid" lines that specify unknown restrictions. + +3. Key Words for Requirements + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + +4. SDP "a=rid" Media Level Attribute + + This section defines new SDP media-level attribute [RFC4566], + "a=rid", used to communicate a set of restrictions to be applied to + an identified RTP stream. Roughly speaking, this attribute takes the + following form (see Section 10 for a formal definition): + + a=rid:<rid-id> <direction> [pt=<fmt-list>;]<restriction>=<value>... + + An "a=rid" SDP media attribute specifies restrictions defining a + unique RTP payload configuration identified via the "rid-id" field. + This value binds the restriction to the RTP stream identified by its + RTP Stream Identifier Source Description (SDES) item [RFC8852]. + Implementations that use the "a=rid" parameter in SDP MUST support + the RtpStreamId SDES item described in [RFC8852]. Such + implementations MUST send that SDES item for all streams in an SDP + media description ("m=") that have "a=rid" lines remaining after + applying the rules in Section 6 and its subsections. + + Implementations that use the "a=rid" parameter in SDP and make use of + redundancy RTP streams [RFC7656] -- e.g., RTP RTX [RFC4588] or + Forward Error Correction (FEC) [RFC5109] -- for any of the source RTP + streams that have "a=rid" lines remaining after applying the rules in + Section 6 and its subsections MUST support the RepairedRtpStreamId + SDES item described in [RFC8852] for those redundancy RTP streams. + RepairedRtpStreamId MUST be used for redundancy RTP streams to which + it can be applied. Use of RepairedRtpStreamId is not applicable for + redundancy formats that directly associate RTP streams through shared + synchronization sources (SSRCs) -- for example, [RFC8627] -- or other + cases that RepairedRtpStreamId cannot support, such as referencing + multiple source streams. + + RepairedRtpStreamId is used to provide the binding between the + redundancy RTP stream and its source RTP stream by setting the + RepairedRtpStreamId value for the redundancy RTP stream to the + RtpStreamId value of the source RTP stream. The redundancy RTP + stream MAY (but need not) have an "a=rid" line of its own, in which + case the RtpStreamId SDES item value will be different from the + corresponding source RTP stream. + + It is important to note that this indirection may result in the + temporary inability to correctly associate source and redundancy data + when the SSRC associated with the RtpStreamId or RepairedRtpStreamId + is dynamically changed during the RTP session. This can be avoided + if all RTP packets, source and repair, include their RtpStreamId or + RepairedRtpStreamId, respectively, after the change. To maximize the + probability of reception and utility of redundancy information after + such a change, all the source packets referenced by the first several + repair packets SHOULD include such information. It is RECOMMENDED + that the number of such packets is large enough to give a high + probability of actual updated association. Section 4.1.1 of + [RFC8285] provides relevant guidance for RTP header extension + transmission considerations. Alternatively, to avoid this issue, + redundancy mechanisms that directly reference its source data may be + used, such as [RFC8627]. + + The "direction" field identifies the direction of the RTP stream + packets to which the indicated restrictions are applied. It may be + either "send" or "recv". Note that these restriction directions are + expressed independently of any "inactive", "sendonly", "recvonly", or + "sendrecv" attributes associated with the media section. It is, for + example, valid to indicate "recv" restrictions on a "sendonly" + stream; those restrictions would apply if, at a future point in time, + the stream were changed to "sendrecv" or "recvonly". + + The optional "pt=<fmt-list>" lists one or more PT values that can be + used in the associated RTP stream. If the "a=rid" attribute contains + no "pt", then any of the PT values specified in the corresponding + "m=" line may be used. + + The list of zero or more codec-agnostic restrictions (Section 5) + describes the restrictions that the corresponding RTP stream will + conform to. + + This framework MAY be used in combination with the "a=fmtp" SDP + attribute for describing the media format parameters for a given RTP + payload type. In such scenarios, the "a=rid" restrictions + (Section 5) further restrict the equivalent "a=fmtp" attributes. + + A given SDP media description MAY have zero or more "a=rid" lines + describing various possible RTP payload configurations. A given + "rid-id" MUST NOT be repeated in a given media description ("m=" + section). + + The "a=rid" media attribute MAY be used for any RTP-based media + transport. It is not defined for other transports, although other + documents may extend its semantics for such transports. + + Though the restrictions specified by the "rid" restrictions follow a + syntax similar to session-level and media-level parameters, they are + defined independently. All "rid" restrictions MUST be registered + with IANA, using the registry defined in Section 12. + + Section 10 gives a formal Augmented Backus-Naur Form (ABNF) [RFC5234] + grammar for the "rid" attribute. The "a=rid" media attribute is not + dependent on charset. + +5. "a=rid" Restrictions + + This section defines the "a=rid" restrictions that can be used to + restrict the RTP payload encoding format in a codec-agnostic way. + Please also see the preceding section for a description of how the + "pt" parameter is used. + + The following restrictions are intended to apply to video codecs in a + codec-independent fashion. + + * *max-width*, for spatial resolution in pixels. In the case that + stream-orientation signaling is used to modify the intended + display orientation, this attribute refers to the width of the + stream when a rotation of zero degrees is encoded. + + * *max-height*, for spatial resolution in pixels. In the case that + stream-orientation signaling is used to modify the intended + display orientation, this attribute refers to the height of the + stream when a rotation of zero degrees is encoded. + + * *max-fps*, for frame rate in frames per second. For encoders that + do not use a fixed frame rate for encoding, this value is used to + restrict the minimum amount of time between frames: the time + between any two consecutive frames SHOULD NOT be less than 1/max- + fps seconds. + + * *max-fs*, for frame size in pixels per frame. This is the product + of frame width and frame height, in pixels, for rectangular + frames. + + * *max-br*, for bitrate in bits per second. The restriction applies + to the media payload only and does not include overhead introduced + by other layers (e.g., RTP, UDP, IP, or Ethernet). The exact + means of keeping within this limit are left up to the + implementation, and instantaneous excursions outside the limit are + permissible. For any given one-second sliding window, however, + the total number of bits in the payload portion of RTP SHOULD NOT + exceed the value specified in "max-br." + + * *max-pps*, for pixel rate in pixels per second. This value SHOULD + be handled identically to max-fps, after performing the following + conversion: max-fps = max-pps / (width * height). If the stream + resolution changes, this value is recalculated. Due to this + recalculation, excursions outside the specified maximum are + possible near resolution-change boundaries. + + * *max-bpp*, for maximum number of bits per pixel, calculated as an + average of all samples of any given coded picture. This is + expressed as a floating point value, with an allowed range of + 0.0001 to 48.0. These values MUST NOT be encoded with more than + four digits to the right of the decimal point. + + * *depend*, to identify other streams that the stream depends on. + The value is a comma-separated list of rid-ids. These rid-ids + identify RTP streams that this stream depends on in order to allow + for proper interpretation. The mechanism defined in this document + allows for such dependencies to be expressed only when the streams + are in the same media section. + + All the restrictions are optional and subject to negotiation based on + the SDP offer/answer rules described in Section 6. + + This list is intended to be an initial set of restrictions. Future + documents may define additional restrictions; see Section 12.2. + While this document does not define restrictions for audio codecs or + any media types other than video, there is no reason such + restrictions should be precluded from definition and registration by + other documents. + + Section 10 provides formal Augmented Backus-Naur Form (ABNF) + [RFC5234] grammar for each of the "a=rid" restrictions defined in + this section. + +6. SDP Offer/Answer Procedures + + This section describes the SDP offer/answer procedures [RFC3264] when + using this framework. + + Note that "rid-id" values are only required to be unique within a + media section ("m=" line); they do not necessarily need to be unique + within an entire RTP session. In traditional usage, each media + section is sent on its own unique 5-tuple (that is: combination of + sending address, sending port, receiving address, receiving port, and + transport protocol), which provides an unambiguous scope. Similarly, + when using BUNDLE [RFC8843], Media Identification (MID) values + associate RTP streams uniquely to a single media description. When + restriction identifier (RID) is used with the BUNDLE mechanism, + streams will be associated with both MID and RID SDES items. + +6.1. Generating the Initial SDP Offer + + For each RTP media description in the offer, the offerer MAY choose + to include one or more "a=rid" lines to specify a configuration + profile for the given set of RTP payload types. + + In order to construct a given "a=rid" line, the offerer must follow + these steps: + + 1. It MUST generate a "rid-id" that is unique within a media + description. + + 2. It MUST set the direction for the "rid-id" to one of "send" or + "recv". + + 3. It MAY include a listing of SDP media formats (usually + corresponding to RTP payload types) allowed to appear in the RTP + stream. Any payload type chosen MUST be a valid payload type for + the media section (that is, it must be listed on the "m=" line). + The order of the listed formats is significant; the alternatives + are listed from (left) most preferred to (right) least preferred. + When using RID, this preference overrides the normal codec + preference as expressed by format type ordering on the "m=" line, + using regular SDP rules. + + 4. The offerer then chooses zero or more "a=rid" restrictions + (Section 5) to be applied to the RTP stream and adds them to the + "a=rid" line. + + 5. If the offerer wishes the answerer to have the ability to specify + a restriction but does not wish to set a value itself, it + includes the name of the restriction in the "a=rid" line, but + without any indicated value. + + Note: If an "a=fmtp" attribute is also used to provide media-format- + specific parameters, then the "a=rid" restrictions will further + restrict the equivalent "a=fmtp" parameters for the given payload + type for the specified RTP stream. + + If a given codec would require an "a=fmtp" line when used without + "a=rid", then the offer MUST include a valid corresponding "a=fmtp" + line even when using "a=rid". + +6.2. Answerer Processing the SDP Offer + +6.2.1. "a=rid"-Unaware Answerer + + If the receiver doesn't support the framework defined in this + specification, the entire "a=rid" line is ignored following the + standard offer/answer rules [RFC3264]. + + Section 6.1 requires the offer to include a valid "a=fmtp" line for + any media formats that otherwise require it (in other words, the + "a=rid" line cannot be used to replace "a=fmtp" configuration). As a + result, ignoring the "a=rid" line is always guaranteed to result in a + valid session description. + +6.2.2. "a=rid"-Aware Answerer + + If the answerer supports the "a=rid" attribute, the following + verification steps are executed, in order, for each "a=rid" line in a + received offer: + + 1. The answerer ensures that the "a=rid" line is syntactically well + formed. In the case of a syntax error, the "a=rid" line is + discarded. + + 2. The answerer extracts the rid-id from the "a=rid" line and + verifies its uniqueness within a media section. In the case of a + duplicate, the entire "a=rid" line, and all "a=rid" lines with + rid-ids that duplicate this line, are discarded and MUST NOT be + included in the SDP answer. + + 3. If the "a=rid" line contains a "pt=", the list of payload types + is verified against the list of valid payload types for the media + section (that is, those listed on the "m=" line). Any PT missing + from the "m=" line is discarded from the set of values in the + "pt=". If no values are left in the "pt=" parameter after this + processing, then the "a=rid" line is discarded. + + 4. If the "direction" field is "recv", the answerer ensures that the + specified "a=rid" restrictions are supported. In the case of an + unsupported restriction, the "a=rid" line is discarded. + + 5. If the "depend" restriction is included, the answerer MUST make + sure that the listed rid-ids unambiguously match the rid-ids in + the media description. Any "depend" "a=rid" lines that do not + are discarded. + + 6. The answerer verifies that the restrictions are consistent with + at least one of the codecs to be used with the RTP stream. If + the "a=rid" line contains a "pt=", it contains the list of such + codecs; otherwise, the list of such codecs is taken from the + associated "m=" line. See Section 8 for more detail. If the + "a=rid" restrictions are incompatible with the other codec + properties for all codecs, then the "a=rid" line is discarded. + + Note that the answerer does not need to understand every restriction + present in a "send" line: if a stream sender restricts the stream in + a way that the receiver does not understand, this causes no issues + with interoperability. + +6.3. Generating the SDP Answer + + Having performed verification of the SDP offer as described in + Section 6.2.2, the answerer shall perform the following steps to + generate the SDP answer. + + For each "a=rid" line that has not been discarded by previous + processing: + + 1. The value of the "direction" field is reversed: "send" is changed + to "recv", and "recv" is changed to "send". + + 2. The answerer MAY choose to modify specific "a=rid" restriction + values in the answer SDP. In such a case, the modified value + MUST be more restrictive than the ones specified in the offer. + The answer MUST NOT include any restrictions that were not + present in the offer. + + 3. The answerer MUST NOT modify the "rid-id" present in the offer. + + 4. If the "a=rid" line contains a "pt=", the answerer is allowed to + discard one or more media formats from a given "a=rid" line. If + the answerer chooses to discard all the media formats from an + "a=rid" line, the answerer MUST discard the entire "a=rid" line. + If the offer did not contain a "pt=" for a given "a=rid" line, + then the answer MUST NOT contain a "pt=" in the corresponding + line. + + 5. In cases where the answerer is unable to support the payload + configuration specified in a given "a=rid" line with a direction + of "recv" in the offer, the answerer MUST discard the + corresponding "a=rid" line. This includes situations in which + the answerer does not understand one or more of the restrictions + in an "a=rid" line with a direction of "recv". + + Note: In the case that the answerer uses different PT values to + represent a codec than the offerer did, the "a=rid" values in the + answer use the PT values that are present in its answer. + +6.4. Offerer Processing of the SDP Answer + + The offerer SHALL follow these steps when processing the answer: + + 1. The offerer matches the "a=rid" line in the answer to the "a=rid" + line in the offer using the "rid-id". If no matching line can be + located in the offer, the "a=rid" line is ignored. + + 2. If the answer contains any restrictions that were not present in + the offer, then the offerer SHALL discard the "a=rid" line. + + 3. If the restrictions have been changed between the offer and the + answer, the offerer MUST ensure that the modifications are more + restrictive than they were in the original offer and that they + can be supported; if not, the offerer SHALL discard the "a=rid" + line. + + 4. If the "a=rid" line in the answer contains a "pt=" but the offer + did not, the offerer SHALL discard the "a=rid" line. + + 5. If the "a=rid" line in the answer contains a "pt=" and the offer + did as well, the offerer verifies that the list of payload types + is a subset of those sent in the corresponding "a=rid" line in + the offer. Note that this matching must be performed + semantically rather than on literal PT values, as the remote end + may not be using symmetric PTs. For the purpose of this + comparison: for each PT listed on the "a=rid" line in the answer, + the offerer looks up the corresponding "a=rtpmap" and "a=fmtp" + lines in the answer. It then searches the list of "pt=" values + indicated in the offer and attempts to find one with an + equivalent set of "a=rtpmap" and "a=fmtp" lines in the offer. If + all PTs in the answer can be matched, then the "pt=" values pass + validation; otherwise, it fails. If this validation fails, the + offerer SHALL discard the "a=rid" line. Note that this semantic + comparison necessarily requires an understanding of the meaning + of codec parameters, rather than a rote byte-wise comparison of + their values. + + 6. If the "a=rid" line contains a "pt=", the offerer verifies that + the attribute values provided in the "a=rid" attributes are + consistent with the corresponding codecs and their other + parameters. See Section 8 for more detail. If the "a=rid" + restrictions are incompatible with the other codec properties, + then the offerer SHALL discard the "a=rid" line. + + 7. The offerer verifies that the restrictions are consistent with at + least one of the codecs to be used with the RTP stream. If the + "a=rid" line contains a "pt=", it contains the list of such + codecs; otherwise, the list of such codecs is taken from the + associated "m=" line. See Section 8 for more detail. If the + "a=rid" restrictions are incompatible with the other codec + properties for all codecs, then the offerer SHALL discard the + "a=rid" line. + + Any "a=rid" line present in the offer that was not matched by step 1 + above has been discarded by the answerer and does not form part of + the negotiated restrictions on an RTP stream. The offerer MAY still + apply any restrictions it indicated in an "a=rid" line with a + direction field of "send", but it is not required to do so. + + It is important to note that there are several ways in which an offer + can contain a media section with "a=rid" lines, although the + corresponding media section in the response does not. This includes + situations in which the answerer does not support "a=rid" at all or + does not support the indicated restrictions. Under such + circumstances, the offerer MUST be prepared to receive a media stream + to which no restrictions have been applied. + +6.5. Modifying the Session + + Offers and answers inside an existing session follow the rules for + initial session negotiation. Such an offer MAY propose a change in + the number of RIDs in use. To avoid race conditions with media, any + RIDs with proposed changes SHOULD use a new ID rather than reusing + one from the previous offer/answer exchange. RIDs without proposed + changes SHOULD reuse the ID from the previous exchange. + +7. Use with Declarative SDP + + This document does not define the use of a RID in declarative SDP. + If concrete use cases for RID in declarative SDP use are identified + in the future, we expect that additional specifications will address + such use. + +8. Interaction with Other Techniques + + Historically, a number of other approaches have been defined that + allow restricting media streams via SDP. These include: + + * Codec-specific configuration set via format parameters ("a=fmtp") + -- for example, the H.264 "max-fs" format parameter [RFC6184] + + * Size restrictions imposed by the "a=imageattr" attribute [RFC6236] + + When the mechanism described in this document is used in conjunction + with these other restricting mechanisms, it is intended to impose + additional restrictions beyond those communicated in other + techniques. + + In an offer, this means that "a=rid" lines, when combined with other + restrictions on the media stream, are expected to result in a non- + empty intersection. For example, if image attributes are used to + indicate that a PT has a minimum width of 640, then specification of + "max-width=320" in an "a=rid" line that is then applied to that PT is + nonsensical. According to the rules of Section 6.2.2, this will + result in the corresponding "a=rid" line being ignored by the + recipient. + + In an answer, the "a=rid" lines, when combined with the other + restrictions on the media stream, are also expected to result in a + non-empty intersection. If the implementation generating an answer + wishes to restrict a property of the stream below that which would be + allowed by other parameters (e.g., those specified in "a=fmtp" or + "a=imageattr"), its only recourse is to discard the "a=rid" line + altogether, as described in Section 6.3. If it instead attempts to + restrict the stream beyond what is allowed by other mechanisms, then + the offerer will ignore the corresponding "a=rid" line, as described + in Section 6.4. + + The following subsections demonstrate these interactions using + commonly used video codecs. These descriptions are illustrative of + the interaction principles outlined above and are not normative. + +8.1. Interaction with VP8 Format Parameters + + [RFC7741] defines two format parameters for the VP8 codec. Both + correspond to restrictions on receiver capabilities and never + indicate sending restrictions. + +8.1.1. max-fr - Maximum Frame Rate + + The VP8 "max-fr" format parameter corresponds to the "max-fps" + restriction defined in this specification. If an RTP sender is + generating a stream using a format defined with this format + parameter, and the sending restrictions defined via "a=rid" include a + "max-fps" parameter, then the sent stream will conform to the smaller + of the two values. + +8.1.2. max-fs - Maximum Frame Size, in VP8 Macroblocks + + The VP8 "max-fs" format parameter corresponds to the "max-fs" + restriction defined in this document, by way of a conversion factor + of the number of pixels per macroblock (typically 256). If an RTP + sender is generating a stream using a format defined with this format + parameter, and the sending restrictions defined via "a=rid" include a + "max-fs" parameter, then the sent stream will conform to the smaller + of the two values; that is, the number of pixels per frame will not + exceed: + + min(rid_max_fs, fmtp_max_fs * macroblock_size) + + This fmtp parameter also has bearing on the max-height and max-width + parameters. Section 6.1 of [RFC7741] requires that the width and + height of the frame in macroblocks be less than int(sqrt(fmtp_max_fs + * 8)). Accordingly, the maximum width of a transmitted stream will + be limited to: + + min(rid_max_width, int(sqrt(fmtp_max_fs * 8)) * macroblock_width) + + Similarly, the stream's height will be limited to: + + min(rid_max_height, int(sqrt(fmtp_max_fs * 8)) * macroblock_height) + +8.2. Interaction with H.264 Format Parameters + + [RFC6184] defines format parameters for the H.264 video codec. The + majority of these parameters do not correspond to codec-independent + restrictions: + + * deint-buf-cap + + * in-band-parameter-sets + + * level-asymmetry-allowed + + * max-rcmd-nalu-size + + * max-cpb + + * max-dpb + + * packetization-mode + + * redundant-pic-cap + + * sar-supported + + * sar-understood + + * sprop-deint-buf-req + + * sprop-init-buf-time + + * sprop-interleaving-depth + + * sprop-level-parameter-sets + + * sprop-max-don-diff + + * sprop-parameter-sets + + * use-level-src-parameter-sets + + Note that the max-cpb and max-dpb format parameters for H.264 + correspond to restrictions on the stream, but they are specific to + the way the H.264 codec operates, and do not have codec-independent + equivalents. + + The [RFC6184] codec format parameters covered in the following + sections correspond to restrictions on receiver capabilities and + never indicate sending restrictions. + +8.2.1. profile-level-id and max-recv-level - Negotiated Subprofile + + These parameters include a "level" indicator, which acts as an index + into Table A-1 of [H264]. This table contains a number of + parameters, several of which correspond to the restrictions defined + in this document. [RFC6184] also defines format parameters for the + H.264 codec that may increase the maximum values indicated by the + negotiated level. The following sections describe the interaction + between these parameters and the restrictions defined by this + document. In all cases, the H.264 parameters being discussed are the + maximum of those indicated by [H264] Table A-1 and those indicated in + the corresponding "a=fmtp" line. + +8.2.2. max-br / MaxBR - Maximum Video Bitrate + + The H.264 "MaxBR" parameter (and its equivalent "max-br" format + parameter) corresponds to the "max-bps" restriction defined in this + specification, by way of a conversion factor of 1000 or 1200; see + [RFC6184] for details regarding which factor gets used under + differing circumstances. + + If an RTP sender is generating a stream using a format defined with + this format parameter, and the sending restrictions defined via + "a=rid" include a "max-fps" parameter, then the sent stream will + conform to the smaller of the two values -- that is: + + min(rid_max_br, h264_MaxBR * conversion_factor) + +8.2.3. max-fs / MaxFS - Maximum Frame Size, in H.264 Macroblocks + + The H.264 "MaxFs" parameter (and its equivalent "max-fs" format + parameter) corresponds roughly to the "max-fs" restriction defined in + this document, by way of a conversion factor of 256 (the number of + pixels per macroblock). + + If an RTP sender is generating a stream using a format defined with + this format parameter, and the sending restrictions defined via + "a=rid" include a "max-fs" parameter, then the sent stream will + conform to the smaller of the two values -- that is: + + min(rid_max_fs, h264_MaxFs * 256) + +8.2.4. max-mbps / MaxMBPS - Maximum Macroblock Processing Rate + + The H.264 "MaxMBPS" parameter (and its equivalent "max-mbps" format + parameter) corresponds roughly to the "max-pps" restriction defined + in this document, by way of a conversion factor of 256 (the number of + pixels per macroblock). + + If an RTP sender is generating a stream using a format defined with + this format parameter, and the sending restrictions defined via + "a=rid" include a "max-pps" parameter, then the sent stream will + conform to the smaller of the two values -- that is: + + min(rid_max_pps, h264_MaxMBPS * 256) + +8.2.5. max-smbps - Maximum Decoded Picture Buffer + + The H.264 "max-smbps" format parameter operates the same way as the + "max-mbps" format parameter, under the hypothetical assumption that + all macroblocks are static macroblocks. It is handled by applying + the conversion factor described in Section 8.1 of [RFC6184], and the + result of this conversion is applied as described in Section 8.2.4. + +8.3. Redundancy Formats and Payload Type Restrictions + + Section 4 specifies that redundancy formats using redundancy RTP + streams bind the redundancy RTP stream to the source RTP stream with + either the RepairedRtpStreamId SDES item or other mechanisms. + However, there exist redundancy RTP payload formats that result in + the redundancy being included in the source RTP stream. An example + of this is "RTP Payload for Redundant Audio Data" [RFC2198], which + encapsulates one source stream with one or more redundancy streams in + the same RTP payload. Formats defining the source and redundancy + encodings as regular RTP payload types require some consideration for + how the "a=rid" restrictions are defined. The "a=rid" line "pt=" + parameter can be used to indicate whether the redundancy RTP payload + type and/or the individual source RTP payload type(s) are part of the + restriction. + + Example (SDP excerpt): + + m=audio 49200 RTP/AVP 97 98 99 100 101 102 + a=mid:foo + a=rtpmap:97 G711/8000 + a=rtpmap:98 LPC/8000 + a=rtpmap:99 OPUS/48000/1 + a=rtpmap:100 RED/8000/1 + a=rtpmap:101 CN/8000 + a=rtpmap:102 telephone-event/8000 + a=fmtp:99 useinbandfec=1; usedtx=0 + a=fmtp:100 97/98 + a=fmtp:102 0-15 + a=ptime:20 + a=maxptime:40 + a=rid:5 send pt=99,102;max-br=64000 + a=rid:6 send pt=100,97,101,102 + + The RID with ID=6 restricts the payload types for this RID to 100 + (the redundancy format), 97 (G.711), 101 (Comfort Noise), and 102 + (dual-tone multi-frequency (DTMF) tones). This means that RID 6 can + either contain the Redundant Audio Data (RED) format, encapsulating + encodings of the source media stream using payload type 97 and 98, 97 + without RED encapsulation, Comfort noise, or DTMF tones. Payload + type 98 is not included in the RID, and can thus not be sent except + as redundancy information in RED encapsulation. If 97 were to be + excluded from the pt parameter, it would instead mean that payload + types 97 and 98 are only allowed via RED encapsulation. + +9. Format Parameters for Future Payloads + + Registrations of future RTP payload format specifications that define + media types that have parameters matching the RID restrictions + specified in this memo SHOULD name those parameters in a manner that + matches the names of those RID restrictions and SHOULD explicitly + state what media-type parameters are restricted by what RID + restrictions. + +10. Formal Grammar + + This section gives a formal Augmented Backus-Naur Form (ABNF) + [RFC5234] grammar, with the case-sensitive extensions described in + [RFC7405], for each of the new media and "a=rid" attributes defined + in this document. + + rid-syntax = %s"a=rid:" rid-id SP rid-dir + [ rid-pt-param-list / rid-param-list ] + + rid-id = 1*(alpha-numeric / "-" / "_") + + alpha-numeric = < as defined in [RFC4566] > + + rid-dir = %s"send" / %s"recv" + + rid-pt-param-list = SP rid-fmt-list *(";" rid-param) + + rid-param-list = SP rid-param *(";" rid-param) + + rid-fmt-list = %s"pt=" fmt *( "," fmt ) + + fmt = < as defined in [RFC4566] > + + rid-param = rid-width-param + / rid-height-param + / rid-fps-param + / rid-fs-param + / rid-br-param + / rid-pps-param + / rid-bpp-param + / rid-depend-param + / rid-param-other + + rid-width-param = %s"max-width" [ "=" int-param-val ] + + rid-height-param = %s"max-height" [ "=" int-param-val ] + + rid-fps-param = %s"max-fps" [ "=" int-param-val ] + + rid-fs-param = %s"max-fs" [ "=" int-param-val ] + + rid-br-param = %s"max-br" [ "=" int-param-val ] + + rid-pps-param = %s"max-pps" [ "=" int-param-val ] + + rid-bpp-param = %s"max-bpp" [ "=" float-param-val ] + + rid-depend-param = %s"depend=" rid-list + + rid-param-other = 1*(alpha-numeric / "-") [ "=" param-val ] + + rid-list = rid-id *( "," rid-id ) + + int-param-val = 1*DIGIT + + float-param-val = 1*DIGIT "." 1*DIGIT + + param-val = *(%x20-3A / %x3C-7E) + ; Any printable character except semicolon + +11. SDP Examples + + Note: See [RFC8853] for examples of RID used in simulcast scenarios. + +11.1. Many Bundled Streams Using Many Codecs + + In this scenario, the offerer supports the Opus, G.722, G.711, and + DTMF audio codecs and VP8, VP9, H.264 (CBP/CHP, mode 0/1), H.264-SVC + (SCBP/SCHP), and H.265 (MP/M10P) for video. An 8-way video call (to + a mixer) is supported (send 1 and receive 7 video streams) by + offering 7 video media sections (1 sendrecv at max resolution and 6 + recvonly at smaller resolutions), all bundled on the same port, using + 3 different resolutions. The resolutions include: + + * 1 receive stream of 720p resolution is offered for the active + speaker. + + * 2 receive streams of 360p resolution are offered for the prior 2 + active speakers. + + * 4 receive streams of 180p resolution are offered for others in the + call. + + NOTE: The SDP given below skips a few lines to keep the example short + and focused, as indicated by either the "..." or the comments + inserted. + + The offer for this scenario is shown below. + + ... + m=audio 10000 RTP/SAVPF 96 9 8 0 123 + a=rtpmap:96 OPUS/48000 + a=rtpmap:9 G722/8000 + a=rtpmap:8 PCMA/8000 + a=rtpmap:0 PCMU/8000 + a=rtpmap:123 telephone-event/8000 + a=mid:a1 + ... + m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107 + a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id + a=rtpmap:98 VP8/90000 + a=fmtp:98 max-fs=3600; max-fr=30 + a=rtpmap:99 VP9/90000 + a=fmtp:99 max-fs=3600; max-fr=30 + a=rtpmap:100 H264/90000 + a=fmtp:100 profile-level-id=42401f; packetization-mode=0 + a=rtpmap:101 H264/90000 + a=fmtp:101 profile-level-id=42401f; packetization-mode=1 + a=rtpmap:102 H264/90000 + a=fmtp:102 profile-level-id=640c1f; packetization-mode=0 + a=rtpmap:103 H264/90000 + a=fmtp:103 profile-level-id=640c1f; packetization-mode=1 + a=rtpmap:104 H264-SVC/90000 + a=fmtp:104 profile-level-id=530c1f + a=rtpmap:105 H264-SVC/90000 + a=fmtp:105 profile-level-id=560c1f + a=rtpmap:106 H265/90000 + a=fmtp:106 profile-id=1; level-id=93 + a=rtpmap:107 H265/90000 + a=fmtp:107 profile-id=2; level-id=93 + a=sendrecv + a=mid:v1 (max resolution) + a=rid:1 send max-width=1280;max-height=720;max-fps=30 + a=rid:2 recv max-width=1280;max-height=720;max-fps=30 + ... + m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107 + a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id + ...same rtpmap/fmtp as above... + a=recvonly + a=mid:v2 (medium resolution) + a=rid:3 recv max-width=640;max-height=360;max-fps=15 + ... + m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107 + a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id + ...same rtpmap/fmtp as above... + a=recvonly + a=mid:v3 (medium resolution) + a=rid:3 recv max-width=640;max-height=360;max-fps=15 + ... + m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107 + a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id + ...same rtpmap/fmtp as above... + a=recvonly + a=mid:v4 (small resolution) + a=rid:4 recv max-width=320;max-height=180;max-fps=15 + ... + m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107 + a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id + ...same rtpmap/fmtp as above... + ...same rid:4 as above for mid:v5,v6,v7 (small resolution)... + ... + +11.2. Scalable Layers + + Adding scalable layers to a session within a multiparty conference + gives a selective forwarding unit (SFU) further flexibility to + selectively forward packets from a source that best match the + bandwidth and capabilities of diverse receivers. Scalable encodings + have dependencies between layers, unlike independent simulcast + streams. RIDs can be used to express these dependencies using the + "depend" restriction. In the example below, the highest resolution + is offered to be sent as 2 scalable temporal layers (using Multiple + RTP Streams on a Single Media Transport (MRST)). See [RFC8853] for + additional detail about simulcast usage. + + Offer: + ... + m=audio ...same as previous example ... + ... + m=video ...same as previous example ... + ...same rtpmap/fmtp as previous example ... + a=sendrecv + a=mid:v1 (max resolution) + a=rid:0 send max-width=1280;max-height=720;max-fps=15 + a=rid:1 send max-width=1280;max-height=720;max-fps=30;depend=0 + a=rid:2 recv max-width=1280;max-height=720;max-fps=30 + a=rid:5 send max-width=640;max-height=360;max-fps=15 + a=rid:6 send max-width=320;max-height=180;max-fps=15 + a=simulcast: send rid=0;1;5;6 recv rid=2 + ... + ...same m=video sections as previous example for mid:v2-v7... + ... + +12. IANA Considerations + + This specification updates [RFC4855] to give additional guidance on + choice of Format Parameter (fmtp) names and their relation to RID + restrictions. + +12.1. New SDP Media-Level Attribute + + This document defines "rid" as an SDP media-level attribute. This + attribute has been registered by IANA under "Session Description + Protocol (SDP) Parameters" under "att-field (media level only)". + + The "rid" attribute is used to identify the properties of an RTP + stream within an RTP session. Its format is defined in Section 10. + + The formal registration information for this attribute follows. + + Contact name, email address, and telephone number + IETF MMUSIC Working Group + mmusic@ietf.org + +1 510 492 4080 + + Attribute name (as it will appear in SDP) + rid + + Long-form attribute name in English + Restriction Identifier + + Type of attribute (session level, media level, or both) + Media Level + + Whether the attribute value is subject to the charset attribute + The attribute is not dependent on charset. + + A one-paragraph explanation of the purpose of the attribute + The "rid" SDP attribute is used to unambiguously identify the RTP + streams within an RTP session and restrict the streams' payload + format parameters in a codec-agnostic way beyond what is provided + with the regular payload types. + + A specification of appropriate attribute values for this attribute + Valid values are defined by the ABNF in RFC 8851 + + Multiplexing (Mux) Category + SPECIAL + +12.2. Registry for RID-Level Parameters + + This specification creates a new IANA registry named "RID Attribute + Parameters" within the SDP parameters registry. The "a=rid" + restrictions MUST be registered with IANA and documented under the + same rules as for SDP session-level and media-level attributes as + specified in [RFC4566]. + + Parameters for "a=rid" lines that modify the nature of encoded media + MUST be of the form that the result of applying the modification to + the stream results in a stream that still complies with the other + parameters that affect the media. In other words, restrictions + always have to restrict the definition to be a subset of what is + otherwise allowable, and never expand it. + + New restriction registrations are accepted according to the + "Specification Required" policy of [RFC8126]. The registration MUST + contain the RID parameter name and a reference to the corresponding + specification. The specification itself must contain the following + information (not all of which appears in the registry): + + * restriction name (as it will appear in SDP) + + * an explanation of the purpose of the restriction + + * a specification of appropriate attribute values for this + restriction + + * an ABNF definition of the restriction + + The initial set of "a=rid" restriction names, with definitions in + Section 5 of this document, is given below: + + +====================+===========+ + | RID Parameter Name | Reference | + +====================+===========+ + | pt | RFC 8851 | + +--------------------+-----------+ + | max-width | RFC 8851 | + +--------------------+-----------+ + | max-height | RFC 8851 | + +--------------------+-----------+ + | max-fps | RFC 8851 | + +--------------------+-----------+ + | max-fs | RFC 8851 | + +--------------------+-----------+ + | max-br | RFC 8851 | + +--------------------+-----------+ + | max-pps | RFC 8851 | + +--------------------+-----------+ + | max-bpp | RFC 8851 | + +--------------------+-----------+ + | depend | RFC 8851 | + +--------------------+-----------+ + + Table 1: "a=rid" restriction names + + It is conceivable that a future document will want to define RID- + level restrictions that contain string values. These extensions need + to take care to conform to the ABNF defined for rid-param-other. In + particular, this means that such extensions will need to define + escaping mechanisms if they want to allow semicolons, unprintable + characters, or byte values greater than 127 in the string. + +13. Security Considerations + + As with most SDP parameters, a failure to provide integrity + protection over the "a=rid" attributes gives attackers a way to + modify the session in potentially unwanted ways. This could result + in an implementation sending greater amounts of data than a recipient + wishes to receive. In general, however, since the "a=rid" attribute + can only restrict a stream to be a subset of what is otherwise + allowable, modification of the value cannot result in a stream that + is of higher bandwidth than would be sent to an implementation that + does not support this mechanism. + + The actual identifiers used for RIDs are expected to be opaque. As + such, they are not expected to contain information that would be + sensitive, were it observed by third parties. + +14. References + +14.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <https://www.rfc-editor.org/info/rfc2119>. + + [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model + with Session Description Protocol (SDP)", RFC 3264, + DOI 10.17487/RFC3264, June 2002, + <https://www.rfc-editor.org/info/rfc3264>. + + [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. + Jacobson, "RTP: A Transport Protocol for Real-Time + Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, + July 2003, <https://www.rfc-editor.org/info/rfc3550>. + + [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session + Description Protocol", RFC 4566, DOI 10.17487/RFC4566, + July 2006, <https://www.rfc-editor.org/info/rfc4566>. + + [RFC4855] Casner, S., "Media Type Registration of RTP Payload + Formats", RFC 4855, DOI 10.17487/RFC4855, February 2007, + <https://www.rfc-editor.org/info/rfc4855>. + + [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", STD 68, RFC 5234, + DOI 10.17487/RFC5234, January 2008, + <https://www.rfc-editor.org/info/rfc5234>. + + [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", + RFC 7405, DOI 10.17487/RFC7405, December 2014, + <https://www.rfc-editor.org/info/rfc7405>. + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, <https://www.rfc-editor.org/info/rfc8174>. + + [RFC8852] Roach, A.B., Nandakumar, S., and P. Thatcher, "RTP Stream + Identifier Source Description (SDES)", RFC 8852, + DOI 10.17487/RFC8852, January 2021, + <https://www.rfc-editor.org/info/rfc8852>. + +14.2. Informative References + + [H264] International Telecommunication Union, "Advanced video + coding for generic audiovisual services", ITU-T + Recommendation H.264, June 2019, + <https://www.itu.int/rec/T-REC-H.264>. + + [RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., + Handley, M., Bolot, J.C., Vega-Garcia, A., and S. Fosse- + Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, + DOI 10.17487/RFC2198, September 1997, + <https://www.rfc-editor.org/info/rfc2198>. + + [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. + Hakenberg, "RTP Retransmission Payload Format", RFC 4588, + DOI 10.17487/RFC4588, July 2006, + <https://www.rfc-editor.org/info/rfc4588>. + + [RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error + Correction", RFC 5109, DOI 10.17487/RFC5109, December + 2007, <https://www.rfc-editor.org/info/rfc5109>. + + [RFC6184] Wang, Y.-K., Even, R., Kristensen, T., and R. Jesup, "RTP + Payload Format for H.264 Video", RFC 6184, + DOI 10.17487/RFC6184, May 2011, + <https://www.rfc-editor.org/info/rfc6184>. + + [RFC6236] Johansson, I. and K. Jung, "Negotiation of Generic Image + Attributes in the Session Description Protocol (SDP)", + RFC 6236, DOI 10.17487/RFC6236, May 2011, + <https://www.rfc-editor.org/info/rfc6236>. + + [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and + B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms + for Real-Time Transport Protocol (RTP) Sources", RFC 7656, + DOI 10.17487/RFC7656, November 2015, + <https://www.rfc-editor.org/info/rfc7656>. + + [RFC7741] Westin, P., Lundin, H., Glover, M., Uberti, J., and F. + Galligan, "RTP Payload Format for VP8 Video", RFC 7741, + DOI 10.17487/RFC7741, March 2016, + <https://www.rfc-editor.org/info/rfc7741>. + + [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for + Writing an IANA Considerations Section in RFCs", BCP 26, + RFC 8126, DOI 10.17487/RFC8126, June 2017, + <https://www.rfc-editor.org/info/rfc8126>. + + [RFC8285] Singer, D., Desineni, H., and R. Even, Ed., "A General + Mechanism for RTP Header Extensions", RFC 8285, + DOI 10.17487/RFC8285, October 2017, + <https://www.rfc-editor.org/info/rfc8285>. + + [RFC8627] Zanaty, M., Singh, V., Begen, A., and G. Mandyam, "RTP + Payload Format for Flexible Forward Error Correction + (FEC)", RFC 8627, DOI 10.17487/RFC8627, July 2019, + <https://www.rfc-editor.org/info/rfc8627>. + + [RFC8843] Holmberg, C., Alvestrand, H., and C. Jennings, + "Negotiating Media Multiplexing Using the Session + Description Protocol (SDP)", RFC 8843, + DOI 10.17487/RFC8843, January 2021, + <https://www.rfc-editor.org/info/rfc8843>. + + [RFC8853] Burman, B., Westerlund, M., Nandakumar, S., and M. Zanaty, + "Using Simulcast in Session Description Protocol (SDP) and + RTP Sessions", RFC 8853, DOI 10.17487/RFC8853, January + 2021, <https://www.rfc-editor.org/info/rfc8853>. + +Acknowledgements + + Many thanks to Cullen Jennings, Magnus Westerlund, and Paul Kyzivat + for reviewing. Thanks to Colin Perkins for input on future payload + type handling. + +Contributors + + The following individuals have contributed significant text to this + document. + + Peter Thatcher + Google + + Email: pthatcher@google.com + + + Mo Zanaty + Cisco Systems + + Email: mzanaty@cisco.com + + + Suhas Nandakumar + Cisco Systems + + Email: snandaku@cisco.com + + + Bo Burman + Ericsson + + Email: bo.burman@ericsson.com + + + Byron Campen + Mozilla + + Email: bcampen@mozilla.com + + +Author's Address + + Adam Roach (editor) + Mozilla + + Email: adam@nostrum.com |