5.10. Applying a Remote Description (Applicazione di una descrizione remota)

5.10. Applying a Remote Description (Applicazione di una descrizione remota)

I seguenti passaggi sono eseguiti per applicare una descrizione remota (remote description). Se viene restituito un errore, la sessione DEVE essere ripristinata allo stato precedente l'esecuzione di questi passaggi.

Se la risposta contiene attributi "a=ice-options" in cui "trickle" è elencato come attributo, aggiornare la proprietà canTrickleIceCandidates di PeerConnection a "true". Altrimenti, impostare questa proprietà a "false".

I seguenti passaggi DEVONO essere eseguiti per gli attributi a livello di sessione; se un parametro è fuori intervallo o non può essere applicato, l'elaborazione DEVE arrestarsi e DEVE essere restituito un errore.

• Per qualsiasi valore di larghe di banda "CT" specificato, impostare questo valore come limite per il bitrate totale massimo di tutte le sezioni "m=", come specificato in [RFC4566], sezione 5.8. Entro questo limite complessivo, l'implementazione può decidere dinamicamente come allocare al meglio la larghezza di banda disponibile tra le sezioni "m=", rispettando eventuali limiti specifici indicati per singole sezioni "m=".

• Per qualsiasi valore di larghezza di banda "RR" o "RS" specificato, gestire come specificato in [RFC3556], sezione 2.

• Qualsiasi valore di larghezza di banda "AS" ([RFC4566], sezione 5.8) DEVE essere ignorato, poiché il significato di questo costrutto a livello di sessione non è ben definito.

Per ogni sezione "m=", i seguenti passaggi DEVONO essere eseguiti; se un parametro è fuori intervallo o non può essere applicato, l'elaborazione DEVE arrestarsi e DEVE essere restituito un errore.

• Se l'ICE ufrag o la password sono cambiati rispetto alla descrizione remota precedente:

  • Se la descrizione è di tipo "offer", l'implementazione DEVE annotare che è necessario un riavvio ICE, come descritto in [RFC8839], sezione 4.4.1.1.1.

  • Se la descrizione è di tipo "answer" o "pranswer", verificare se la descrizione locale corrente è un riavvio ICE e, in caso contrario, generare un errore. Se lo stato di PeerConnection è "have-remote-pranswer" e l'ICE ufrag o la password sono cambiati rispetto alla risposta provvisoria precedente, segnalare all'agente ICE di scartare qualsiasi stato precedente della checklist ICE per la sezione "m=". Infine, segnalare all'agente ICE di iniziare i controlli.

• Se la descrizione locale corrente indica un riavvio ICE ma né l'ICE ufrag né la password sono cambiati rispetto alla descrizione remota precedente (come prescritto da [RFC8445], sezione 9), generare un errore.

• Configurare i componenti ICE associati a questa sezione multimediale per usare l'ICE ufrag remoto e la password forniti per i loro controlli di connettività.

• Accoppiare eventuali candidati ICE forniti con i candidati locali raccolti, come descritto in [RFC8445], sezione 6.1.2, e avviare controlli di connettività con le credenziali appropriate.

• Se è presente un attributo "a=end-of-candidates", elaborare l'indicazione di fine candidati come descritto in [RFC8838], sezione 14.

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

  • Se la sezione "m=" viene riciclata (vedere sezione 5.2.2), dissociare il RtpTransceiver attualmente associato impostando la sua proprietà mid a null, e scartare la mappatura tra il transceiver e il suo indice di sezione "m=".

  • Se la sezione "m=" non è associata ad alcun RtpTransceiver (eventualmente perché è stata dissociata nel passaggio precedente), trovare un RtpTransceiver o crearne uno secondo i passaggi seguenti:

    • Se la sezione "m=" è sendrecv o recvonly, e vi sono RtpTransceiver dello stesso tipo aggiunti a PeerConnection tramite addTrack che non sono associati ad alcuna sezione "m=" e non sono fermati, trovare il primo (secondo l'ordine canonico descritto nella sezione 5.2.1) di tali RtpTransceiver.

    • Se nessun RtpTransceiver è stato trovato nel passaggio precedente, crearne uno con direzione recvonly.

    • Associare il RtpTransceiver trovato o creato alla sezione "m=" impostando il valore della proprietà mid del RtpTransceiver sul MID della sezione "m=", e stabilire una mappatura tra il transceiver e l'indice della sezione "m=". Se la sezione "m=" non include un MID (cioè l'endpoint remoto non supporta l'estensione MID), generare un valore per la proprietà mid del RtpTransceiver, seguendo le indicazioni per "a=mid" menzionate nella sezione 5.2.1.

  • Per ogni formato multimediale specificato che è anche supportato dall'implementazione locale, stabilire una mappatura tra il tipo di payload specificato e il formato multimediale, come descritto in [RFC3264], sezione 6.1. In particolare, l'implementazione registra il tipo di payload da usare nei pacchetti RTP in uscita quando si invia ciascun formato multimediale specificato, nonché la preferenza relativa per ciascun formato indicata dal loro ordinamento. Se un formato multimediale indicato non è supportato dall'implementazione locale, DEVE essere ignorato.

  • Per ogni formato multimediale "rtx" specificato, stabilire una mappatura tra il tipo di payload RTX e il tipo di payload primario associato, come descritto in [RFC4588], sezione 4. Se tipi di payload primari referenziati non sono presenti, ciò DEVE comportare un errore. I tipi di payload RTX possono riferirsi a tipi di payload primari non supportati dall'implementazione multimediale locale, nel qual caso il tipo di payload RTX DEVE essere ignorato.

  • Per ogni parametro fmtp specificato supportato dall'implementazione locale, abilitarli sui formati multimediali associati.

  • Per ogni Synchronization Source (SSRC) segnalata nella sezione "m=", preparare la demultiplazione dei flussi RTP destinati a questa sezione "m=" usando quella SSRC, come descritto in [RFC8843], sezione 9.2.

  • Per ogni estensione di intestazione RTP specificata supportata anche dall'implementazione locale, stabilire una mappatura tra ID estensione e URI, come descritto in [RFC5285], sezione 5. In particolare, l'implementazione registra l'ID estensione da usare nei pacchetti RTP in uscita quando si invia ciascuna estensione di intestazione specificata. Se un'estensione di intestazione RTP indicata non è supportata dall'implementazione locale, DEVE essere ignorata.

  • Per ogni meccanismo di feedback RTCP specificato supportato dall'implementazione locale, abilitarli sui formati multimediali associati.

  • Per qualsiasi valore di larghezza di banda "TIAS" ("Transport Independent Application Specific Maximum") specificato, impostare questo valore come vincolo sul bitrate RTP massimo da usare quando si inviano media, come specificato in [RFC3890]. Se non è presente un valore "TIAS" ma è specificato un valore "AS", generare un valore "TIAS" usando questa formula:

    TIAS = AS * 1000 * 0.95 - (50 * 40 * 8)

    Il 1000 converte l'unità da kbps a bps (come richiesto da TIAS), e lo 0,95 alloca il 5% all'RTCP. Si sottrae poi una stima dell'overhead di intestazione, in cui 50 si basa su 50 pacchetti al secondo, 40 sulla dimensione tipica dell'intestazione (in byte), e 8 converte byte in bit. "TIAS" è preferibile ad "AS" perché consente un controllo più accurato della larghezza di banda.

  • Per qualsiasi valore di larghezza di banda "RR" o "RS", gestire come specificato in [RFC3556], sezione 2.

  • Qualsiasi valore di larghezza di banda "CT" specificato DEVE essere ignorato, poiché il significato di questo costrutto a livello multimediale non è ben definito.

  • Se la sezione "m=" è di tipo "audio":

    • Per ogni formato multimediale "CN" specificato, configurare la soppressione del silenzio per tutti i formati multimediali supportati con la stessa frequenza di clock, come descritto in [RFC3389], sezione 5, tranne i formati che hanno propri meccanismi interni di soppressione del silenzio. La soppressione del silenzio per tali formati (ad es. Opus) è controllata tramite parametri fmtp, come discusso nella sezione 5.2.3.2.

    • Per ogni formato multimediale "telephone-event" specificato, abilitare la trasmissione DTMF (dual-tone multifrequency) per tutti i formati multimediali supportati con la stessa frequenza di clock, come descritto in [RFC4733], sezione 2.5.1.2. Se vi sono formati multimediali supportati senza un formato telephone-event corrispondente, disabilitare la trasmissione DTMF per tali formati.

    • Per qualsiasi valore "ptime" specificato, configurare i formati multimediali disponibili per usare la dimensione del pacchetto specificata durante l'invio. Se la dimensione specificata non è supportata per un formato multimediale, usare invece il valore più vicino.

Infine, se questa descrizione è di tipo "pranswer" o "answer", seguire l'elaborazione definita nella sezione 5.11.