4.1.1. Constructor (Costruttore)
4.1.1. Constructor (Costruttore)
Il costruttore PeerConnection consente all'applicazione di specificare parametri globali per la sessione multimediale, come i server STUN/TURN e le credenziali da utilizzare durante la raccolta dei candidati, nonché la politica iniziale dei candidati ICE e la dimensione del pool, e anche la politica di bundle da utilizzare.
Se viene specificata una politica dei candidati ICE, funziona come descritto nella Sezione 3.5.3, facendo sì che l'implementazione JSEP presenti solo i candidati consentiti (incluso qualsiasi filtraggio interno all'implementazione) all'applicazione e utilizzi solo quei candidati per i controlli di connettività. L'insieme delle politiche disponibili è il seguente:
all: Tutti i candidati consentiti dalla politica di implementazione verranno raccolti e utilizzati.
relay: Tutti i candidati tranne i candidati relay verranno filtrati. Questo offusca le informazioni sulla posizione che potrebbero essere determinate dal peer remoto dai candidati ricevuti. A seconda di come l'applicazione distribuisce e sceglie i server relay, questo potrebbe offuscare la posizione a livello metropolitano o persino globale.
La politica predefinita dei candidati ICE DEVE essere impostata su "all", poiché questa è generalmente la politica desiderata e riduce anche tipicamente in modo significativo l'uso delle risorse del server TURN dell'applicazione.
Se viene specificata una dimensione per il pool di candidati ICE, questo indica il numero di componenti ICE per i quali pre-raccogliere i candidati. Poiché la pre-raccolta comporta l'utilizzo delle risorse del server STUN/TURN per periodi potenzialmente lunghi, questo DEVE verificarsi solo su richiesta dell'applicazione, e pertanto la dimensione predefinita del pool di candidati DEVE essere zero.
L'applicazione può specificare la sua politica preferita riguardo all'uso del bundle, il meccanismo di multiplexing definito in [RFC8843]. Indipendentemente dalla politica, l'applicazione cercherà sempre di negoziare il bundle su un singolo trasporto e offrirà un singolo gruppo bundle su tutte le sezioni "m="; l'uso di questo singolo trasporto dipende dall'accettazione del bundle da parte del risponditore. Tuttavia, specificando una politica dall'elenco sottostante, l'applicazione può controllare esattamente quanto aggressivamente cercherà di raggruppare i flussi multimediali insieme, il che influisce su come interagirà con un endpoint non consapevole del bundle. Quando si negozia con un endpoint non consapevole del bundle, verranno stabiliti solo i flussi non contrassegnati come flussi solo-bundle.
L'insieme delle politiche disponibili è il seguente:
balanced: La prima sezione "m=" di ogni tipo (audio, video o applicazione) conterrà parametri di trasporto, che consentiranno a un risponditore di sbundlare quella sezione. La seconda e tutte le successive sezioni "m=" di ogni tipo verranno contrassegnate come solo-bundle. Il risultato è che se ci sono N tipi di media distinti, verranno raccolti candidati per N flussi multimediali. Questa politica bilancia il desiderio di multiplexing con la necessità di garantire che audio e video di base possano ancora essere negoziati nei casi legacy. Quando agisce come risponditore, se non c'è un gruppo bundle nell'offerta, l'implementazione rifiuterà tutte le sezioni "m=" tranne la prima di ogni tipo.
max-compat: Tutte le sezioni "m=" conterranno parametri di trasporto; nessuna verrà contrassegnata come solo-bundle. Questa politica consentirà a tutti i flussi di essere ricevuti da endpoint non consapevoli del bundle, ma richiederà la raccolta di candidati separati per ogni flusso multimediale.
max-bundle: Solo la prima sezione "m=" conterrà parametri di trasporto; tutti i flussi diversi dal primo verranno contrassegnati come solo-bundle. Questa politica mira a minimizzare la raccolta dei candidati e massimizzare il multiplexing, al costo di una minore compatibilità con gli endpoint legacy. Quando agisce come risponditore, l'implementazione rifiuterà qualsiasi sezione "m=" diversa dalla prima sezione "m=", a meno che non siano nello stesso gruppo bundle di quella sezione "m=".
Poiché fornisce il miglior compromesso tra prestazioni e compatibilità con gli endpoint legacy, la politica di bundle predefinita DEVE essere impostata su "balanced".
L'applicazione può specificare la sua politica preferita riguardo all'uso del multiplexing RTP/RTCP [RFC5761] utilizzando una delle seguenti politiche:
negotiate: L'implementazione JSEP raccoglierà candidati sia RTP che RTCP ma offrirà anche "a=rtcp-mux", consentendo così la compatibilità con endpoint multiplexing o non-multiplexing.
require: L'implementazione JSEP raccoglierà solo candidati RTP e inserirà un'indicazione "a=rtcp-mux-only" in tutte le nuove sezioni "m=" nelle offerte che genera. Questo dimezza il numero di candidati che l'offerente deve raccogliere. L'applicazione di una descrizione con una sezione "m=" che non contiene un attributo "a=rtcp-mux" causerà la restituzione di un errore.
La politica di multiplexing predefinita DEVE essere impostata su "require". Le implementazioni POSSONO scegliere di rifiutare i tentativi dell'applicazione di impostare la politica di multiplexing su "negotiate".