Skip to main content

5.9. Applying a Local Description

5.9. Applying a Local Description​

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

First, "m=" sections are processed. 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 this "m=" section is new, begin gathering candidates for it, as defined in [RFC8445], Section 5.1.1, unless it is definitively being bundled (either (1) this is an offer and the "m=" section is marked bundle-only or (2) it is an answer and the "m=" section is bundled into another "m=" section).

  • Or, if the ICE ufrag and password values have changed, trigger the ICE agent to start an ICE restart as described in [RFC8445], Section 9, and begin gathering new candidates for the "m=" section. If this description is an answer, also start checks on that media section.

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

    • If there is no RtpTransceiver associated with this "m=" section, find one and associate it with this "m=" section according to the following steps. Note that this situation will only occur when applying an offer.

      • Find the RtpTransceiver that corresponds to this "m=" section, using the mapping between transceivers and "m=" section indices established when creating the offer.

      • Set the value of this RtpTransceiver's mid property to the MID of the "m=" section.

    • If RTCP mux is indicated, prepare to demux RTP and RTCP from the RTP ICE component, as specified in [RFC5761], Section 5.1.3.

    • For each specified RTP header extension, establish a mapping between the extension ID and URI, as described in [RFC5285], Section 6.

    • If the MID header extension is supported, prepare to demux RTP streams intended for this "m=" section based on the MID header extension, as described in [RFC8843], Section 15.

    • For each specified media format, establish a mapping between the payload type and the actual media format, as described in [RFC3264], Section 6.1. In addition, prepare to demux RTP streams intended for this "m=" section based on the media formats supported by this "m=" section, as described in [RFC8843], Section 9.2.

    • For each specified "rtx" media format, establish a mapping between the RTX payload type and its associated primary payload type, as described in Sections 8.6 and 8.7 of [RFC4588].

    • If the direction attribute is of type "sendrecv" or "recvonly", enable receipt and decoding of media.

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

Last updated on