5.2.2. Subsequent Offers

5.2.2. Subsequent Offers

When createOffer 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 offer.

If the previous offer was not applied using setLocalDescription, meaning the PeerConnection is still in the "stable" state, the steps for generating an initial offer 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 by one on each call to createOffer if the offer might differ from the output of the previous call to createOffer; implementations MAY opt to increment <session-version> on every call.

If the previous offer was applied using setLocalDescription, but a corresponding answer from the remote side has not yet been applied, meaning the PeerConnection is still in the "have-local-offer" state, an offer is generated by following the steps in the "stable" state above, along with these exceptions:

• The "s=" and "t=" lines MUST stay the same.
• Each "a=mid" line MUST stay the same.
• Each "a=ice-ufrag" and "a=ice-pwd" line MUST stay the same, unless the ICE configuration has changed or the IceRestart option was specified.
• For RtpTransceivers that are still present, the "a=rid" lines MUST stay the same.
• For RtpTransceivers that are still present, any "a=simulcast" line MUST stay the same.