5.11. Applying an Answer (Applicazione di una risposta)

5.11. Applying an Answer (Applicazione di una risposta)

Oltre ai passaggi sopra menzionati per l'elaborazione di una descrizione locale o remota, i seguenti passaggi sono eseguiti quando si elabora una descrizione di tipo "pranswer" o "answer".

Per ogni sezione "m=", i seguenti passaggi DEVONO essere eseguiti:

• Se la sezione "m=" è stata rifiutata (cioè il valore del campo port è impostato a zero nella risposta), arrestare qualsiasi ricezione o trasmissione di media per questa sezione e, a meno che una sezione "m=" non rifiutata non sia in bundle con questa sezione, scartare eventuali componenti ICE associati, come descritto in [RFC8839], sezione 4.4.3.1.

• Se l'impronta DTLS remota è cambiata o il valore dell'attributo "a=tls-id" è cambiato, demolire la connessione DTLS. Ciò include il caso in cui lo stato di PeerConnection è "have-remote-pranswer". Se una connessione DTLS deve essere demolita ma la risposta non indica un riavvio ICE o, nel caso di "have-remote-pranswer", nuove credenziali ICE, DEVE essere generato un errore. Se viene eseguito un riavvio ICE senza cambiamento del valore tls-id o dell'impronta, la stessa connessione DTLS continua sul nuovo canale ICE. Si noti che sebbene JSEP richieda che i rispondenti modifichino il valore tls-id se e solo se lo fa l'offerente, i rispondenti non JSEP possono modificare il valore tls-id purché l'offerta contenesse un riavvio ICE. Pertanto, le implementazioni JSEP che elaborano dati DTLS prima di ricevere una risposta DEVONO essere preparate a ricevere un ClientHello o dati dalla connessione DTLS precedente.

• Se non esiste una connessione DTLS valida, preparare l'avvio di una connessione DTLS, usando i ruoli e le impronte specificati, su eventuali componenti ICE sottostanti, una volta che sono attivi.

• Se il valore del campo proto della sezione "m=" indica l'uso di RTP:

  • Se la sezione "m=" fa riferimento a meccanismi di feedback RTCP che non erano presenti nella sezione "m=" corrispondente nell'offerta, ciò indica un problema di negoziazione e DEVE comportare un errore. Tuttavia, nuovi formati multimediali e nuovi valori di estensione di intestazione RTP sono consentiti nella risposta, come descritto in [RFC3264], sezione 7 e [RFC5285], sezione 6.

  • Se la sezione "m=" ha il mux RTCP abilitato, scartare il componente ICE RTCP, se esiste, e iniziare o continuare a multiplexare RTCP sul componente ICE RTP, come specificato in [RFC5761], sezione 5.1.3. Altrimenti, preparare la trasmissione di RTCP sul componente ICE RTCP; se non esiste un componente ICE RTCP perché il mux RTCP era stato precedentemente abilitato, ciò DEVE comportare un errore.

  • Se la sezione "m=" ha Reduced-Size RTCP abilitato, configurare la trasmissione RTCP per questa sezione "m=" per usare Reduced-Size RTCP, come specificato in [RFC5506].

  • Se l'attributo di direzione nella risposta indica che l'implementazione JSEP dovrebbe inviare media ("sendonly" per risposte locali, "recvonly" per risposte remote, o "sendrecv" per entrambi i tipi di risposta), scegliere il formato multimediale da inviare come il formato multimediale più preferito dalla descrizione remota che è anche supportato localmente, come discusso nelle sezioni 6.1 e 7 di [RFC3264], e iniziare a trasmettere media RTP usando quel formato una volta stabiliti i livelli di trasporto sottostanti. Se non è già stato scelto un SSRC per questo flusso RTP in uscita, sceglierne uno casuale unico. Se i media sono già trasmessi, lo stesso SSRC DOVREBBE essere usato a meno che la frequenza di clock del nuovo codec non sia diversa, nel qual caso DEVE essere scelto un nuovo SSRC, come specificato in [RFC7160], sezione 4.1.

  • La mappatura dei tipi di payload dalla descrizione remota è usata per determinare i tipi di payload per i flussi RTP in uscita, incluso il tipo di payload per il formato multimediale di invio scelto sopra. Eventuali estensioni di intestazione RTP negoziate dovrebbero essere incluse nei flussi RTP in uscita, usando la mappatura delle estensioni dalla descrizione remota. Se l'estensione di intestazione MID è stata negoziata, includerla nei flussi RTP in uscita, come indicato in [RFC8843], sezione 15. Se le estensioni di intestazione RtpStreamId o RepairedRtpStreamId sono state negoziate e sono stati stabiliti rid-id, includere queste estensioni di intestazione nei flussi RTP in uscita, come indicato in [RFC8851], sezione 4.

  • Se la sezione "m=" è di tipo "audio", e la soppressione del silenzio è stata (1) configurata per il formato multimediale di invio come risultato dell'elaborazione della descrizione remota e (2) anche abilitata per quel formato nella descrizione locale, usare la soppressione del silenzio per i media in uscita, in conformità alle indicazioni nella sezione 5.2.3.2. Se queste condizioni non sono soddisfatte, la soppressione del silenzio NON DEVE essere usata per i media in uscita.

  • Se il simulcast è stato negoziato, inviare il numero appropriato di Source RTP Streams come specificato in [RFC8853], sezione 5.3.3.

  • Se il formato multimediale di invio scelto sopra ha un formato multimediale "rtx" corrispondente o è stato negoziato un meccanismo FEC, stabilire un flusso RTP ridondante con SSRC casuale unico per ogni Source RTP Stream, e iniziare o continuare a trasmettere pacchetti RTX/FEC secondo necessità.

  • Se il formato multimediale di invio scelto sopra ha un formato multimediale "red" corrispondente della stessa frequenza di clock, consentire la codifica ridondante usando il formato specificato a fini di resilienza, come discusso in [RFC8854], sezione 3.2. Si noti che a differenza dei formati multimediali RTX o FEC, il formato "red" è trasmesso sul Source RTP Stream, non sul flusso RTP ridondante.

  • Abilitare i meccanismi di feedback RTCP referenziati nella sezione multimediale per tutti i Source RTP Streams usando i formati multimediali specificati. In particolare, iniziare o continuare a inviare i tipi di feedback richiesti e reagire al feedback ricevuto, come specificato in [RFC4585], sezione 4.2. Quando si invia feedback RTCP, seguire le regole e le raccomandazioni da [RFC8108], sezione 5.4.1 per selezionare quale SSRC usare.

  • Se l'attributo di direzione nella risposta indica che l'implementazione JSEP non dovrebbe inviare media ("recvonly" per risposte locali, "sendonly" per risposte remote, o "inactive" per entrambi i tipi di risposta), arrestare la trasmissione di tutti i media RTP, ma continuare a inviare RTCP, come descritto in [RFC3264], sezione 5.1.

• Se il valore del campo proto della sezione "m=" indica l'uso di SCTP:

  • Se esiste un'associazione SCTP e la porta SCTP remota è cambiata, scartare l'associazione SCTP esistente. Ciò include il caso in cui lo stato di PeerConnection è "have-remote-pranswer".

  • Se non esiste un'associazione SCTP valida, preparare l'avvio di un'associazione SCTP sul componente ICE e sulla connessione DTLS associati, usando il valore della porta SCTP locale dalla descrizione locale e il valore della porta SCTP remota dalla descrizione remota, come descritto in [RFC8841], sezione 10.2.

Se la risposta contiene gruppi di bundle validi, scartare eventuali componenti ICE per le sezioni "m=" che saranno aggregate sui componenti ICE primari in ciascun bundle, e iniziare a multiplexare queste sezioni "m=" di conseguenza, come descritto in [RFC8843], sezione 7.4.

Se la descrizione è di tipo "answer" e vi sono ancora candidati rimanenti nel pool di candidati ICE, scartarli.