Skip to main content

5.3.2. Subsequent Answers

5.3.2. Subsequent Answers​

When createAnswer is called a second (or later) time or is called after a local description has already been installed, the processing is somewhat different than for an initial answer.

If the previous answer was not applied using setLocalDescription, meaning the PeerConnection is still in the "have-remote-offer" state, the steps for generating an initial answer MUST be followed, subject to the following restriction:

  • The fields of the "o=" line MUST stay the same except for the <session-version> field, which MUST increment if the session description changes in any way from the previously generated answer.

If any session description was previously supplied to setLocalDescription, an answer is generated by following the steps in the "have-remote-offer" state above, along with these exceptions:

  • The "s=" and "t=" lines MUST stay the same.

  • Each "m=" and "c=" line MUST be filled in with the port and address of the default candidate for the "m=" section, as described in [RFC8839], Section 4.2.1.2. Note that in certain cases, the "m=" line protocol may not match that of the default candidate, because the "m=" line protocol value MUST match what was supplied in the offer, as described above.

  • Each "a=ice-ufrag" and "a=ice-pwd" line MUST stay the same, unless the "m=" section is restarting, in which case new ICE credentials MUST be created as specified in [RFC8839], Section 4.4.1.1.1. If the "m=" section is bundled into another "m=" section, it still MUST NOT contain any ICE credentials.

  • Each "a=tls-id" line MUST stay the same, unless the offerer's "a=tls-id" line changed, in which case a new tls-id value MUST be created, as described in [RFC8842], Section 5.2.

  • Each "a=setup" line MUST use an "active" or "passive" role value consistent with the existing DTLS association, if the association is being continued by the offerer.

  • RTCP multiplexing MUST be used, and an "a=rtcp-mux" line inserted if and only if the "m=" section previously used RTCP multiplexing.

  • If the "m=" section is not bundled into another "m=" section and RTCP multiplexing is not active, an "a=rtcp" attribute line MUST be filled in with the port and address of the default RTCP candidate. If no RTCP candidates have yet been gathered, default values MUST be used, as described in Section 5.3.1 above.

  • If the "m=" section is not bundled into another "m=" section, for each candidate that has been gathered during the most recent gathering phase (see Section 3.5.1), an "a=candidate" line MUST be added, as defined in [RFC8839], Section 5.1. If candidate gathering for the section has completed, an "a=end-of-candidates" attribute MUST be added, as described in [RFC8840], Section 8.2. If the "m=" section is bundled into another "m=" section, both "a=candidate" and "a=end-of-candidates" MUST be omitted.

  • For RtpTransceivers that are not stopped, the "a=msid" line(s) MUST stay the same, regardless of changes to the transceiver's direction or track. If no "a=msid" line is present in the current description, "a=msid" line(s) MUST be generated according to the same rules as for an initial answer.

Last updated on