5.2.2. Subsequent Offers (Offerte successive)

5.2.2. Subsequent Offers (Offerte successive)

Quando createOffer viene chiamato una seconda volta (o successiva) o viene chiamato dopo che una descrizione locale è già stata installata, l'elaborazione è in qualche modo diversa rispetto a un'offerta iniziale.

Se l'offerta precedente non è stata applicata utilizzando setLocalDescription, il che significa che il PeerConnection è ancora nello stato "stable", i passaggi per generare un'offerta iniziale DEVONO essere seguiti, con la seguente restrizione:

• I campi della riga "o=" DEVONO rimanere gli stessi tranne per il campo <session-version>, che DEVE incrementare di uno ad ogni chiamata a createOffer se l'offerta potrebbe differire dall'output della chiamata precedente a createOffer; le implementazioni POSSONO scegliere di incrementare <session-version> ad ogni chiamata.

Se l'offerta precedente è stata applicata utilizzando setLocalDescription, ma una risposta corrispondente dal lato remoto non è ancora stata applicata, il che significa che il PeerConnection è ancora nello stato "have-local-offer", viene generata un'offerta seguendo i passaggi nello stato "stable" sopra, con queste eccezioni:

• Le righe "s=" e "t=" DEVONO rimanere le stesse.
• Ogni riga "a=mid" DEVE rimanere la stessa.
• Ogni riga "a=ice-ufrag" e "a=ice-pwd" DEVE rimanere la stessa, a meno che la configurazione ICE non sia cambiata o l'opzione IceRestart non sia stata specificata.
• Per i RtpTransceiver che sono ancora presenti, le righe "a=rid" DEVONO rimanere le stesse.
• Per i RtpTransceiver che sono ancora presenti, qualsiasi riga "a=simulcast" DEVE rimanere la stessa.