5.10. Applying a Remote Description

5.10. Applying a Remote Description

The following steps are performed to apply a remote description. If an error is returned, the session MUST be restored to the state it was in before performing these steps.

If the answer contains any "a=ice-options" attributes where "trickle" is listed as an attribute, update the PeerConnection canTrickleIceCandidates property to be "true". Otherwise, set this property to "false".

The following steps MUST be performed for attributes at the session level; if any parameters are out of bounds or cannot be applied, processing MUST stop and an error MUST be returned.

• For any specified "CT" bandwidth value, set this value as the limit for the maximum total bitrate for all "m=" sections, as specified in [RFC4566], Section 5.8. Within this overall limit, the implementation can dynamically decide how to best allocate the available bandwidth between "m=" sections, respecting any specific limits that have been specified for individual "m=" sections.

• For any specified "RR" or "RS" bandwidth values, handle as specified in [RFC3556], Section 2.

• Any "AS" bandwidth value ([RFC4566], Section 5.8) MUST be ignored, as the meaning of this construct at the session level is not well defined.

For each "m=" section, the following steps MUST be performed; if any parameters are out of bounds or cannot be applied, processing MUST stop and an error MUST be returned.

• If the ICE ufrag or password changed from the previous remote description:

  • If the description is of type "offer", the implementation MUST note that an ICE restart is needed, as described in [RFC8839], Section 4.4.1.1.1.

  • If the description is of type "answer" or "pranswer", then check to see if the current local description is an ICE restart, and if not, generate an error. If the PeerConnection state is "have-remote-pranswer" and the ICE ufrag or password changed from the previous provisional answer, then signal the ICE agent to discard any previous ICE checklist state for the "m=" section. Finally, signal the ICE agent to begin checks.

• If the current local description indicates an ICE restart but neither the ICE ufrag nor the password has changed from the previous remote description (as prescribed by [RFC8445], Section 9), generate an error.

• Configure the ICE components associated with this media section to use the supplied ICE remote ufrag and password for their connectivity checks.

• Pair any supplied ICE candidates with any gathered local candidates, as described in [RFC8445], Section 6.1.2, and start connectivity checks with the appropriate credentials.

• If an "a=end-of-candidates" attribute is present, process the end-of-candidates indication as described in [RFC8838], Section 14.

• If the proto field value of the "m=" section indicates use of RTP:

  • If the "m=" section is being recycled (see Section 5.2.2), disassociate the currently associated RtpTransceiver by setting its mid property to null, and discard the mapping between the transceiver and its "m=" section index.

  • If the "m=" section is not associated with any RtpTransceiver (possibly because it was disassociated in the previous step), either find an RtpTransceiver or create one according to the following steps:

    • If the "m=" section is sendrecv or recvonly, and there are RtpTransceivers of the same type that were added to the PeerConnection by addTrack and are not associated with any "m=" section and are not stopped, find the first (according to the canonical order described in Section 5.2.1) such RtpTransceiver.

    • If no RtpTransceiver was found in the previous step, create one with a recvonly direction.

    • Associate the found or created RtpTransceiver with the "m=" section by setting the value of the RtpTransceiver's mid property to the MID of the "m=" section, and establish a mapping between the transceiver and the index of the "m=" section. If the "m=" section does not include a MID (i.e., the remote endpoint does not support the MID extension), generate a value for the RtpTransceiver mid property, following the guidance for "a=mid" mentioned in Section 5.2.1.

  • For each specified media format that is also supported by the local implementation, establish a mapping between the specified payload type and the media format, as described in [RFC3264], Section 6.1. Specifically, this means that the implementation records the payload type to be used in outgoing RTP packets when sending each specified media format, as well as the relative preference for each format that is indicated in their ordering. If any indicated media format is not supported by the local implementation, it MUST be ignored.

  • For each specified "rtx" media format, establish a mapping between the RTX payload type and its associated primary payload type, as described in [RFC4588], Section 4. If any referenced primary payload types are not present, this MUST result in an error. Note that RTX payload types may refer to primary payload types that are not supported by the local media implementation, in which case the RTX payload type MUST also be ignored.

  • For each specified fmtp parameter that is supported by the local implementation, enable them on the associated media formats.

  • For each specified Synchronization Source (SSRC) that is signaled in the "m=" section, prepare to demux RTP streams intended for this "m=" section using that SSRC, as described in [RFC8843], Section 9.2.

  • For each specified RTP header extension that is also supported by the local implementation, establish a mapping between the extension ID and URI, as described in [RFC5285], Section 5. Specifically, this means that the implementation records the extension ID to be used in outgoing RTP packets when sending each specified header extension. If any indicated RTP header extension is not supported by the local implementation, it MUST be ignored.

  • For each specified RTCP feedback mechanism that is supported by the local implementation, enable them on the associated media formats.

  • For any specified "TIAS" ("Transport Independent Application Specific Maximum") bandwidth value, set this value as a constraint on the maximum RTP bitrate to be used when sending media, as specified in [RFC3890]. If a "TIAS" value is not present but an "AS" value is specified, generate a "TIAS" value using this formula:

    TIAS = AS * 1000 * 0.95 - (50 * 40 * 8)

    The 1000 changes the unit from kbps to bps (as required by TIAS), and the 0.95 is to allocate 5% to RTCP. An estimate of header overhead is then subtracted out, in which the 50 is based on 50 packets per second, the 40 is based on typical header size (in bytes), and the 8 converts bytes to bits. Note that "TIAS" is preferred over "AS" because it provides more accurate control of bandwidth.

  • For any "RR" or "RS" bandwidth values, handle as specified in [RFC3556], Section 2.

  • Any specified "CT" bandwidth value MUST be ignored, as the meaning of this construct at the media level is not well defined.

  • If the "m=" section is of type "audio":

    • For each specified "CN" media format, configure silence suppression for all supported media formats with the same clock rate, as described in [RFC3389], Section 5, except for formats that have their own internal silence suppression mechanisms. Silence suppression for such formats (e.g., Opus) is controlled via fmtp parameters, as discussed in Section 5.2.3.2.

    • For each specified "telephone-event" media format, enable dual-tone multifrequency (DTMF) transmission for all supported media formats with the same clock rate, as described in [RFC4733], Section 2.5.1.2. If there are any supported media formats that do not have a corresponding telephone-event format, disable DTMF transmission for those formats.

    • For any specified "ptime" value, configure the available media formats to use the specified packet size when sending. If the specified size is not supported for a media format, use the next closest value instead.

Finally, if this description is of type "pranswer" or "answer", follow the processing defined in Section 5.11.