5.3.2. Subsequent Answers (Risposte successive)

5.3.2. Subsequent Answers (Risposte successive)

Quando createAnswer viene chiamato una seconda volta (o successivamente) oppure dopo che è già stata installata una descrizione locale, l'elaborazione differisce in parte da quella di una risposta iniziale.

Se la risposta precedente non è stata applicata tramite setLocalDescription, cioè il PeerConnection è ancora nello stato "have-remote-offer", DEVONO essere seguiti i passi per generare una risposta iniziale, soggetti alla seguente restrizione:

• I campi della riga "o=" DEVONO restare invariati tranne il campo <session-version>, che DEVE essere incrementato se la descrizione di sessione cambia in qualsiasi modo rispetto alla risposta generata in precedenza.

Se in precedenza è stata fornita una descrizione di sessione a setLocalDescription, una risposta si genera seguendo i passi nello stato "have-remote-offer" sopra, con queste eccezioni:

• Le righe "s=" e "t=" DEVONO restare invariate.

• Ogni riga "m=" e "c=" DEVE essere compilata con la porta e l'indirizzo del candidato predefinito per la sezione "m=", come descritto in [RFC8839], sezione 4.2.1.2. In alcuni casi il protocollo della riga "m=" può non coincidere con quello del candidato predefinito, perché il valore di protocollo della riga "m=" DEVE corrispondere a quanto fornito nell'offerta, come sopra.

• Ogni riga "a=ice-ufrag" e "a=ice-pwd" DEVE restare invariata, salvo che la sezione "m=" sia in riavvio, nel qual caso DEVONO essere create nuove credenziali ICE come specificato in [RFC8839], sezione 4.4.1.1.1. Se la sezione "m=" è aggregata in un'altra sezione "m=", NON DEVE comunque contenere credenziali ICE.

• Ogni riga "a=tls-id" DEVE restare invariata, salvo che la riga "a=tls-id" dell'offerente sia cambiata, nel qual caso DEVE essere creato un nuovo valore tls-id, come descritto in [RFC8842], sezione 5.2.

• Ogni riga "a=setup" DEVE usare un valore di ruolo "active" o "passive" coerente con l'associazione DTLS esistente, se l'offerente sta continuando l'associazione.

• DEVE essere usato il multiplexing RTCP, e una riga "a=rtcp-mux" inserita se e solo se la sezione "m=" usava in precedenza il multiplexing RTCP.

• Se la sezione "m=" non è aggregata in un'altra e il multiplexing RTCP non è attivo, una riga attributo "a=rtcp" DEVE essere compilata con porta e indirizzo del candidato RTCP predefinito. Se non sono ancora stati raccolti candidati RTCP, DEVONO essere usati valori predefiniti, come nella sezione 5.3.1 sopra.

• Se la sezione "m=" non è aggregata in un'altra, per ogni candidato raccolto nella fase di raccolta più recente (vedere sezione 3.5.1), DEVE essere aggiunta una riga "a=candidate", come definito in [RFC8839], sezione 5.1. Se la raccolta per la sezione è completata, DEVE essere aggiunto l'attributo "a=end-of-candidates", come descritto in [RFC8840], sezione 8.2. Se la sezione "m=" è aggregata in un'altra, sia "a=candidate" sia "a=end-of-candidates" DEVONO essere omessi.

• Per RtpTransceiver non arrestati, la o le righe "a=msid" DEVONO restare invariate, indipendentemente da cambiamenti di direzione o traccia del transceiver. Se non è presente alcuna riga "a=msid" nella descrizione corrente, la o le righe "a=msid" DEVONO essere generate secondo le stesse regole di una risposta iniziale.