Movatterモバイル変換

RFC 8851	RTP Restrictions	January 2021
Roach	Standards Track	[Page]

2.Introduction

The payload type (PT) field in RTP provides a mapping between the RTP payloadformat and the associated SDP media description. For a given PT, the SDPrtpmap and/or fmtp attributes are used to describe the properties ofthe media that is carried in the RTP payload.¶

Recent advances in standards have given rise to richmultimedia applications requiring support for either multiple RTP streams within anRTP session[RFC8843][RFC8853] or alarge number of codecs.These demands have unearthed challenges inherent with:¶

The restricted RTP PT space in specifying the various payloadconfigurations¶
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, butindividual 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 RTPstreams (Section 2.1.10 of[RFC7656]), along withthe SDP attributes to restrict payload formats in a codec-agnostic way.This framework can be thought of as a complementary extension to the waythe 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 thisattribute only serve to further restrict the parameters that are establishedon 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 correlationbetween the RTP packets and their format specification in the SDP.¶

As described inSection 6.2.1, this mechanism achieves backwardscompatibility via the normal SDP processing rules, which require unknown "a="lines to be ignored. This means that implementations need to be preparedto handle successful offers and answers from other implementations thatneither indicate nor honor the restrictions requested by this mechanism.¶

Further, as described inSection 6 and its subsections, this mechanismachieves extensibility by: (a) having offerers include all supportedrestrictions in their offer, and (b) having answerers ignore "a=rid" lines thatspecify unknown restrictions.¶

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 beapplied to an identified RTP stream. Roughly speaking, this attribute takesthe following form (seeSection 10 for aformal definition):¶

a=rid:<rid-id> <direction> [pt=<fmt-list>;]<restriction>=<value>...

An "a=rid" SDP media attribute specifies restrictions defining a uniqueRTP payload configuration identified via the "rid-id" field. Thisvalue binds the restriction to the RTP stream identified by its RTPStream Identifier Source Description (SDES) item[RFC8852].Implementations that use the "a=rid" parameter in SDPMUST supportthe RtpStreamId SDES item described in[RFC8852]. SuchimplementationsMUST send that SDES item for all streams in an SDP media description("m=") that have "a=rid" lines remaining after applying the rules inSection 6 and its subsections.¶

Implementations that use the "a=rid" parameter in SDP and make use ofredundancy RTP streams[RFC7656] -- e.g., RTP RTX[RFC4588] or Forward Error Correction (FEC)[RFC5109] -- for any of thesource RTP streams that have "a=rid" lines remainingafter applying the rules inSection 6 and its subsectionsMUSTsupport the RepairedRtpStreamId SDES item described in[RFC8852] for those redundancy RTP streams. RepairedRtpStreamIdMUST be used for redundancy RTP streams to which it can be applied.Use of RepairedRtpStreamId is not applicable forredundancy formats that directly associate RTP streamsthrough shared synchronization sources (SSRCs) -- for example,[RFC8627] --or other cases that RepairedRtpStreamId cannot support, such as referencingmultiple source streams.¶

RepairedRtpStreamId is used to provide the binding between the redundancy RTPstream and its source RTP stream by setting the RepairedRtpStreamId value forthe redundancy RTP stream to the RtpStreamId value of the source RTP stream.The redundancy RTP streamMAY (but need not) have an "a=rid" line of its own,in which case the RtpStreamId SDES item value will be different from thecorresponding source RTP stream.¶

It is important to note that this indirection may result in the temporaryinability to correctly associate source and redundancy data when the SSRCassociated with the RtpStreamId or RepairedRtpStreamId is dynamically changedduring the RTP session. This can be avoided if all RTP packets, source andrepair, include their RtpStreamId or RepairedRtpStreamId,respectively, after the change. To maximize the probability of reception and utility ofredundancy information after such a change, all the source packets referencedby the first several repair packetsSHOULD include such information. It isRECOMMENDED that the number of such packets is large enough to give a highprobability of actual updated association. Section 4.1.1 of[RFC8285]provides relevant guidance for RTP header extension transmissionconsiderations. Alternatively, to avoid this issue, redundancy mechanismsthat directly reference its source data may be used, such as[RFC8627].¶

The "direction" field identifies the direction of the RTP stream packets towhich the indicated restrictions are applied. It may be either "send" or"recv". Note that these restriction directions are expressed independently ofany "inactive", "sendonly", "recvonly", or "sendrecv" attributes associatedwith the media section. It is, for example, valid to indicate "recv"restrictions on a "sendonly" stream; those restrictions would apply if, at afuture 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 usedin the associated RTP stream. If the "a=rid" attribute containsno "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 thecorresponding RTP stream will conform to.¶

This frameworkMAY be used in combination with the "a=fmtp" SDP attributefor describing the media format parameters for a given RTP payload type. Insuch scenarios, the "a=rid" restrictions (Section 5)further restrict the equivalent "a=fmtp" attributes.¶

A given SDP media descriptionMAY have zero or more "a=rid" lines describingvarious possible RTP payload configurations. A given "rid-id"MUST NOTbe repeated in a given media description ("m=" section).¶

The "a=rid" media attributeMAY be used for any RTP-based media transport. Itis not defined for other transports, although other documents may extend itssemantics for such transports.¶

Though the restrictions specified by the "rid" restrictions follow asyntax similar to session-level and media-level parameters, they are definedindependently. All "rid" restrictionsMUST be registered with IANA, usingthe registry defined inSection 12.¶

Section 10 gives a formal Augmented Backus-Naur Form (ABNF)[RFC5234]grammar for the "rid" attribute. The "a=rid" media attribute is not dependenton charset.¶

5."a=rid" Restrictions

This section defines the "a=rid" restrictions that can be used to restrict theRTP 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 acodec-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 zerodegrees is encoded.¶
max-fps, for frame rate in frames per second. For encoders that do not usea fixed frame rate for encoding, this value is used to restrict the minimumamount of time between frames: the time between any two consecutive framesSHOULD NOT be less than 1/max-fps seconds.¶
max-fs, for frame size in pixels per frame. This is the product of framewidth and frame height, in pixels, for rectangular frames.¶
max-br, for bitrate in bits per second. The restriction applies to themedia payload only and does not include overhead introduced by other layers(e.g., RTP, UDP, IP, or Ethernet). The exact means of keeping within thislimit are left up to the implementation, and instantaneous excursionsoutside the limit are permissible. For any given one-second sliding window,however, the total number of bits in the payload portion of RTPSHOULD NOTexceed the value specified in "max-br."¶
max-pps, for pixel rate in pixels per second. This valueSHOULD be handledidentically to max-fps, after performing the following conversion: max-fps =max-pps / (width * height). If the stream resolution changes, this value isrecalculated. Due to this recalculation, excursions outside the specifiedmaximum are possible near resolution-change boundaries.¶
max-bpp, for maximum number of bits per pixel, calculated as an average ofall samples of any given coded picture. This is expressed asa floating point value, with an allowed range of 0.0001 to 48.0. ThesevaluesMUST NOT be encoded with more than four digits to the right of thedecimal point.¶
depend, to identify other streams that the stream depends on. The valueis a comma-separated list of rid-ids. These rid-ids identify RTP streamsthat this stream depends on in order to allow for proper interpretation.The mechanism defined in this document allows for such dependenciesto be expressed only when the streams are in the same media section.¶

All the restrictions are optional and subject to negotiation based on theSDP offer/answer rules described inSection 6.¶

This list is intended to be an initial set of restrictions. Future documentsmay define additional restrictions; seeSection 12.2. While this documentdoes not define restrictions for audio codecs or any media types other thanvideo, there is no reason suchrestrictions should be precluded from definition and registration by otherdocuments.¶

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] whenusing this framework.¶

Note that "rid-id" values are only required to be unique within amedia section ("m=" line); they do not necessarily need to be unique within anentire RTP session. In traditional usage, each media section is sent on itsown unique 5-tuple (that is: combination of sending address, sending port,receiving address, receiving port, and transport protocol), which provides anunambiguous scope. Similarly, when using BUNDLE[RFC8843],Media Identification (MID) values associate RTP streamsuniquely to a single media description. When restriction identifier (RID) is used with the BUNDLEmechanism, 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 offererMAY choose to include oneor more "a=rid" lines to specify a configuration profile for the given set ofRTP payload types.¶

In order to construct a given "a=rid" line, the offerer must follow thesesteps:¶

ItMUST generate a "rid-id" that is unique within a mediadescription.¶
ItMUST set the direction for the "rid-id" to one of"send" or "recv".¶
ItMAY include a listing of SDP media formats (usually corresponding to RTPpayload types) allowed to appear in the RTP stream. Any payload typechosenMUST be a valid payload type for the media section (that is, it mustbe listed on the "m=" line). The order of the listed formats issignificant; the alternatives are listed from (left) most preferred to(right) least preferred. When using RID, this preference overrides thenormal codec preference as expressed by format type ordering on the"m=" line, using regular SDP rules.¶
The offerer then chooses zero or more "a=rid" restrictions(Section 5) to be applied to the RTP stream andadds them to the "a=rid" line.¶
If the offerer wishes the answerer to have the ability to specify arestriction but does not wish to set a value itself, it includes thename of the restriction in the "a=rid" line, but without any indicatedvalue.¶

Note: If an "a=fmtp" attribute is also used to provide media-format-specificparameters, then the "a=rid" restrictions will further restrict theequivalent "a=fmtp" parameters for the given payload type for the specifiedRTP stream.¶

If a given codec would require an "a=fmtp" line when used without "a=rid", thenthe offerMUST 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 thisspecification, the entire "a=rid" line is ignored following the standardoffer/answer rules[RFC3264].¶

Section 6.1 requires the offer to include a valid "a=fmtp" linefor 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 validsession description.¶

6.2.2."a=rid"-Aware Answerer

If the answerer supports the "a=rid" attribute, the following verificationsteps are executed, in order, for each "a=rid" line in a received offer:¶

The answerer ensures that the "a=rid" line is syntactically wellformed. In the case of a syntax error, the "a=rid" line is discarded.¶
The answerer extracts the rid-id from the "a=rid" line and verifies itsuniqueness 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 andMUST NOT be included in the SDP answer.¶
If the "a=rid" line contains a "pt=", the list of payload typesis 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=" lineis discarded from the set of values in the "pt=". If no values are leftin the "pt=" parameter after this processing, then the "a=rid" line is discarded.¶
If the "direction" field is "recv", the answerer ensures that the specified"a=rid" restrictions are supported. In the case of an unsupportedrestriction, the "a=rid" line is discarded.¶
If the "depend" restriction is included, the answererMUST makesure that the listed rid-ids unambiguously match therid-ids in the media description. Any "depend" "a=rid" lines that do not arediscarded.¶
The answerer verifies that the restrictions are consistentwith 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 suchcodecs; otherwise, the list of such codecs is taken from the associated"m=" line. SeeSection 8 for more detail. If the"a=rid" restrictions are incompatible with the other codec propertiesfor all codecs, then the "a=rid" line is discarded.¶

Note that the answerer does not need to understand every restriction presentin a "send" line: if a stream sender restricts the stream in a way that thereceiver does not understand, this causes no issues with interoperability.¶

6.3.Generating the SDP Answer

Having performed verification of the SDP offer as described inSection 6.2.2, the answerer shall perform the following steps togenerate the SDP answer.¶

For each "a=rid" line that has not been discarded by previous processing:¶

The value of the "direction" field is reversed: "send" is changedto "recv", and "recv" is changed to "send".¶
The answererMAY choose to modify specific "a=rid" restriction values inthe answer SDP. In such a case, the modified valueMUST be more restrictivethan the ones specified in the offer. The answerMUST NOT include anyrestrictions that were not present in the offer.¶
The answererMUST NOT modify the "rid-id" present in the offer.¶
If the "a=rid" line contains a "pt=", the answerer is allowed todiscard one or more media formats from a given "a=rid" line. If the answererchooses to discard all the media formats from an "a=rid" line, theanswererMUST discard the entire "a=rid" line. If the offer did not containa "pt=" for a given "a=rid" line, then the answerMUST NOTcontain a "pt=" in the corresponding line.¶
In cases where the answerer is unable to support the payload configurationspecified in a given "a=rid" line with a direction of "recv" in the offer,the answererMUST discard the corresponding "a=rid" line. This includessituations in which the answerer does not understand one or more of therestrictions in an "a=rid" line with a direction of "recv".¶

Note: In the case that the answerer uses different PT values to represent acodec than the offerer did, the "a=rid" values in the answer use the PT valuesthat are present in its answer.¶

6.4.Offerer Processing of the SDP Answer

The offererSHALL follow these steps when processing the answer:¶

The offerer matches the "a=rid" line in the answer to the "a=rid" linein the offer using the "rid-id". If no matching line can be locatedin the offer, the "a=rid" line is ignored.¶
If the answer contains any restrictions that were not present in the offer,then the offererSHALL discard the "a=rid" line.¶
If the restrictions have been changed between the offer and theanswer, the offererMUST ensure that the modifications are more restrictivethan they were in the original offer and that they can be supported; ifnot, the offererSHALL discard the "a=rid" line.¶
If the "a=rid" line in the answer contains a "pt=" but theoffer did not, the offererSHALL discard the "a=rid" line.¶
If the "a=rid" line in the answer contains a "pt=" and theoffer did as well, the offerer verifies that the list of payload types is asubset of those sent in the corresponding "a=rid" line in the offer. Notethat this matching must be performed semantically rather than on literal PTvalues, as the remote end may not be using symmetric PTs. For the purposeof 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 theanswer. It then searches the list of "pt=" values indicated in the offerand 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, theoffererSHALL discard the "a=rid" line. Note that this semantic comparisonnecessarily requires an understanding of the meaning of codec parameters,rather than a rote byte-wise comparison of their values.¶
If the "a=rid" line contains a "pt=", the offerer verifies thatthe attribute values provided in the "a=rid" attributes are consistentwith the corresponding codecs and their other parameters. SeeSection 8 for more detail. If the "a=rid" restrictionsare incompatible with the other codec properties, then the offererSHALL discard the "a=rid" line.¶
The offerer verifies that the restrictions are consistentwith 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 suchcodecs; otherwise, the list of such codecs is taken from the associated"m=" line. SeeSection 8 for more detail. If the"a=rid" restrictions are incompatible with the other codec propertiesfor all codecs, then the offererSHALL discard the "a=rid" line.¶

Any "a=rid" line present in the offer that was not matched by step 1 abovehas been discarded by the answerer and does not form part of the negotiatedrestrictions on an RTP stream. The offererMAY still apply any restrictionsit indicated in an "a=rid" line with a direction field of "send", butit is not required to do so.¶

It is important to note that there are several ways in which an offer cancontain a media section with "a=rid" lines, although the corresponding mediasection in the response does not. This includes situations in which theanswerer does not support "a=rid" at all or does not support the indicatedrestrictions. Under such circumstances, the offererMUST be prepared toreceive 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 initialsession negotiation. Such an offerMAY propose a change in the number of RIDsin use. To avoid race conditions with media, any RIDs with proposed changesSHOULD use a new ID rather than reusing one from the previous offer/answerexchange. RIDs without proposed changesSHOULD reuse the ID from the previousexchange.¶

8.Interaction with Other Techniques

Historically, a number of other approaches have been defined that allowrestricting media streams via SDP. These include:¶

Codec-specific configuration set via format parameters ("a=fmtp") -- forexample, 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 withthese other restricting mechanisms, it is intended to impose additionalrestrictions beyond those communicated in other techniques.¶

In an offer, this means that "a=rid" lines, when combined with otherrestrictions 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 minimumwidth of 640, then specification of "max-width=320" in an "a=rid" line that isthen applied to that PT is nonsensical. According to the rules ofSection 6.2.2, this will result in the corresponding "a=rid" linebeing ignored by the recipient.¶

In an answer, the "a=rid" lines, when combined with the otherrestrictions on the media stream, are also expected to result in a non-emptyintersection. If the implementation generating an answer wishes to restrict aproperty 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 todiscard the "a=rid" line altogether, as described inSection 6.3.If it instead attempts to restrict the stream beyond what is allowed by othermechanisms, then the offerer will ignore the corresponding "a=rid" line, asdescribed inSection 6.4.¶

The following subsections demonstrate these interactions using commonly usedvideo codecs. These descriptions are illustrative of the interaction principlesoutlined 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 neverindicate sending restrictions.¶

8.1.1.max-fr - Maximum Frame Rate

The VP8 "max-fr" format parameter corresponds to the "max-fps" restrictiondefined in this specification. If an RTP sender is generating a stream usinga format defined with this format parameter, and the sending restrictionsdefined via "a=rid" include a "max-fps" parameter, then the sent streamwill 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 thenumber of pixels per macroblock (typically 256). If an RTP sender isgenerating a stream using a format defined with this format parameter, andthe 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 themax-height and max-width parameters.Section 6.1 of [RFC7741] requires that the width and height of the frame inmacroblocks 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 majorityof 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 torestrictions on the stream, but they are specific to the way the H.264 codecoperates, and do not have codec-independent equivalents.¶

The[RFC6184] codec format parameters covered in the following sectionscorrespond to restrictions on receiver capabilities and never indicatesending restrictions.¶

8.2.1.profile-level-id and max-recv-level - Negotiated Subprofile

These parameters include a "level" indicator, which acts as an indexinto Table A-1 of[H264]. This table contains a number of parameters,several of which correspond to the restrictions defined in thisdocument.[RFC6184] also defines format parameters for the H.264codec that may increase the maximum values indicated by the negotiatedlevel. The following sections describe the interaction between theseparameters and the restrictions defined by this document. In all cases,the H.264 parameters being discussed are the maximum of those indicatedby[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" formatparameter) corresponds to the "max-bps" restrictiondefined in this specification, by way of a conversion factor of 1000or 1200; see[RFC6184] for details regarding which factor getsused under differing circumstances.¶

If an RTP sender is generating a stream usinga format defined with this format parameter, and the sending restrictionsdefined via "a=rid" include a "max-fps" parameter, then the sent streamwill 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" restrictiondefined 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 usinga format defined with this format parameter, and the sending restrictionsdefined via "a=rid" include a "max-fs" parameter, then the sent streamwill 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" restrictiondefined 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 usinga format defined with this format parameter, and the sending restrictionsdefined via "a=rid" include a "max-pps" parameter, then the sent streamwill 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 allmacroblocks are static macroblocks. It is handled by applying theconversion factor described in Section 8.1 of[RFC6184], and theresult of this conversion is applied as described inSection 8.2.4.¶

8.3.Redundancy Formats and Payload Type Restrictions

Section 4 specifies that redundancy formats using redundancy RTP streams bindthe redundancy RTP stream to the source RTP stream with either theRepairedRtpStreamId SDES item or other mechanisms. However, there existredundancy RTP payload formats that result in the redundancy being included inthe source RTP stream. An example of this is "RTP Payload for Redundant AudioData"[RFC2198], which encapsulates one source stream with one or moreredundancy streams in the same RTP payload. Formats defining the source andredundancy encodings as regular RTP payload types require some considerationfor how the "a=rid" restrictions are defined. The "a=rid" line "pt=" parametercan be used to indicate whether the redundancy RTP payload type and/or theindividual 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.¶

11.SDP Examples

Note: See[RFC8853] for examples of RID usedin simulcast scenarios.¶

11.1.Many Bundled Streams Using Many Codecs

In this scenario, the offerer supports the Opus, G.722, G.711, and DTMF audiocodecs and VP8, VP9, H.264 (CBP/CHP, mode 0/1), H.264-SVC (SCBP/SCHP), andH.265 (MP/M10P) for video. An 8-way video call (to a mixer) is supported (send1 and receive 7 video streams) by offering 7 video media sections (1 sendrecvat max resolution and 6 recvonly at smaller resolutions), all bundled on thesame 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 activespeakers.¶
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 123a=rtpmap:96 OPUS/48000a=rtpmap:9 G722/8000a=rtpmap:8 PCMA/8000a=rtpmap:0 PCMU/8000a=rtpmap:123 telephone-event/8000a=mid:a1...m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-ida=rtpmap:98 VP8/90000a=fmtp:98 max-fs=3600; max-fr=30a=rtpmap:99 VP9/90000a=fmtp:99 max-fs=3600; max-fr=30a=rtpmap:100 H264/90000a=fmtp:100 profile-level-id=42401f; packetization-mode=0a=rtpmap:101 H264/90000a=fmtp:101 profile-level-id=42401f; packetization-mode=1a=rtpmap:102 H264/90000a=fmtp:102 profile-level-id=640c1f; packetization-mode=0a=rtpmap:103 H264/90000a=fmtp:103 profile-level-id=640c1f; packetization-mode=1a=rtpmap:104 H264-SVC/90000a=fmtp:104 profile-level-id=530c1fa=rtpmap:105 H264-SVC/90000a=fmtp:105 profile-level-id=560c1fa=rtpmap:106 H265/90000a=fmtp:106 profile-id=1; level-id=93a=rtpmap:107 H265/90000a=fmtp:107 profile-id=2; level-id=93a=sendrecva=mid:v1 (max resolution)a=rid:1 send max-width=1280;max-height=720;max-fps=30a=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 107a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id...same rtpmap/fmtp as above...a=recvonlya=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 107a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id...same rtpmap/fmtp as above...a=recvonlya=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 107a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id...same rtpmap/fmtp as above...a=recvonlya=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 107a=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 aselective forwarding unit (SFU) further flexibility to selectively forwardpackets from a source that best match the bandwidth and capabilities ofdiverse receivers. Scalable encodings have dependencies between layers, unlikeindependent simulcast streams. RIDs can be used to express these dependenciesusing the "depend" restriction. In the example below, the highest resolution isoffered 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=sendrecva=mid:v1 (max resolution)a=rid:0 send max-width=1280;max-height=720;max-fps=15a=rid:1 send max-width=1280;max-height=720;max-fps=30;depend=0a=rid:2 recv max-width=1280;max-height=720;max-fps=30a=rid:5 send max-width=640;max-height=360;max-fps=15a=rid:6 send max-width=320;max-height=180;max-fps=15a=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 inSection 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" restrictionsMUST beregistered with IANA and documented under the same rules as for SDPsession-level and media-level attributes as specified in[RFC4566].¶

Parameters for "a=rid" lines that modify the nature of encoded mediaMUST beof the form that the result of applying the modification to the stream resultsin a stream that still complies with the other parameters that affect themedia. In other words, restrictions always have to restrict the definition to bea subset of what is otherwise allowable, and never expand it.¶

New restriction registrations are accepted according to the "SpecificationRequired" policy of[RFC8126]. The registrationMUST contain the RIDparameter name and a reference to the corresponding specification. Thespecification itself must contain the following information (not all of whichappears 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 inSection 5 of this document, is given below:¶

Table 1:"a=rid" restriction names
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

It is conceivable that a future document will want to define RID-levelrestrictions that contain string values. These extensions need to take care toconform to the ABNF defined for rid-param-other. In particular, this meansthat such extensions will need to define escaping mechanisms if theywant to allow semicolons, unprintable characters, or byte valuesgreater than 127 in the string.¶

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>.

Movatterモバイル変換

RFC 8851

RTP Payload Format Restrictions