11. Media Handling (Gestione dei media)

11.1. Sending Media (Invio dei media)

Le procedure per l'invio dei media differiscono per le implementazioni complete e lite.

11.1.1. Procedures for Full Implementations (Procedure per implementazioni complete)

Gli agenti inviano sempre i media utilizzando una coppia di candidati, chiamata coppia di candidati selezionata. Un agente invierà i media al candidato remoto nella coppia selezionata (impostando l'indirizzo e la porta di destinazione del pacchetto uguali a quel candidato remoto) e li invierà dal candidato locale della coppia selezionata. Quando il candidato locale è server o peer reflexive, i media provengono dalla base. I media inviati da un candidato inoltrato vengono inviati dalla base attraverso quel server TURN, utilizzando le procedure definite in [RFC5766].

Se il candidato locale è un candidato inoltrato, è RECOMMENDED che un agente crei un canale sul server TURN verso il candidato remoto. Questo viene fatto utilizzando le procedure per la creazione del canale come definito nella Sezione 11 di [RFC5766].

La coppia selezionata per un componente di un flusso multimediale è:

• vuota se lo stato dell'elenco di controllo per quel flusso multimediale è Running e non esiste una coppia selezionata precedente per quel componente a causa di un riavvio ICE

• uguale alla coppia selezionata precedente per un componente di un flusso multimediale se lo stato dell'elenco di controllo per quel flusso multimediale è Running e c'era una coppia selezionata precedente per quel componente a causa di un riavvio ICE

• uguale alla coppia nominata con la priorità più alta per quel componente nell'elenco valido se lo stato dell'elenco di controllo è Completed

Se la coppia selezionata per almeno un componente di un flusso multimediale è vuota, un agente MUST NOT inviare media per alcun componente di quel flusso multimediale. Se la coppia selezionata per ciascun componente di un flusso multimediale ha un valore, un agente MAY inviare media per tutti i componenti di quel flusso multimediale.

Si noti che la coppia selezionata per un componente di un flusso multimediale potrebbe non essere uguale alla coppia predefinita per quello stesso componente dallo scambio di offerta/risposta più recente. Quando ciò accade, viene utilizzata la coppia selezionata per i media, non la coppia predefinita. Quando ICE viene completato per la prima volta, se le coppie selezionate non corrispondono alle coppie predefinite, l'agente di controllo invia uno scambio di offerta/risposta aggiornato per rimediare a questa disparità. Tuttavia, fino a quando quell'offerta aggiornata non arriva, non ci sarà una corrispondenza. Inoltre, in casi molto insoliti, i candidati predefiniti nell'offerta/risposta aggiornata non corrisponderanno.

11.1.2. Procedures for Lite Implementations (Procedure per implementazioni Lite)

Un'implementazione lite MUST NOT inviare media fino a quando non ha un elenco Valid che contiene una coppia di candidati per ciascun componente di quel flusso multimediale. Una volta che ciò accade, l'agente MAY iniziare a inviare pacchetti multimediali. Per fare ciò, invia i media al candidato remoto nella coppia (impostando l'indirizzo e la porta di destinazione del pacchetto uguali a quel candidato remoto) e li invierà dal candidato locale.

11.1.3. Procedures for All Implementations (Procedure per tutte le implementazioni)

ICE ha interazioni con i meccanismi di adattamento del buffer di jitter. Un flusso RTP può iniziare a utilizzare un candidato e passare a un altro, sebbene ciò accada raramente con ICE. Il candidato più recente può far sì che i pacchetti RTP prendano un percorso diverso attraverso la rete -- uno con caratteristiche di ritardo diverse. Come discusso di seguito, gli agenti sono incoraggiati a riaggiustare i buffer di jitter quando ci sono cambiamenti nell'indirizzo di origine o di destinazione dei pacchetti multimediali. Inoltre, molti codec audio utilizzano il bit marker per segnalare l'inizio di un talkspurt, ai fini dell'adattamento del buffer di jitter. Per tali codec, è RECOMMENDED che il mittente imposti il bit marker [RFC3550] quando un agente cambia la trasmissione dei media da una coppia di candidati a un'altra.

11.2. Receiving Media (Ricezione dei media)

Le implementazioni ICE MUST essere preparate a ricevere media su ciascun componente su qualsiasi candidato fornito per quel componente nello scambio di offerta/risposta più recente (nel caso di RTP, ciò includerebbe sia RTP che RTCP se i candidati fossero forniti per entrambi).

È RECOMMENDED che, quando un agente riceve un pacchetto RTP con un nuovo indirizzo IP di origine o di destinazione per un particolare flusso multimediale, l'agente riaggiusti i suoi buffer di jitter.

RFC 3550 [RFC3550] descrive un algoritmo nella Sezione 8.2 per rilevare collisioni e loop della sorgente di sincronizzazione (SSRC). Questi algoritmi si basano, in parte, sulla visualizzazione di diversi indirizzi di trasporto di origine con lo stesso SSRC. Tuttavia, quando viene utilizzato ICE, tali cambiamenti a volte si verificheranno man mano che i flussi multimediali passano da un candidato all'altro. Un agente sarà in grado di determinare che un flusso multimediale proviene dallo stesso peer come conseguenza dello scambio STUN che precede la trasmissione dei media. Pertanto, se c'è un cambiamento nell'indirizzo di trasporto di origine, ma i pacchetti multimediali provengono dallo stesso agente peer, questo SHOULD NOT essere trattato come una collisione SSRC.