8.3.2 Changing the Set of Media Formats (Modifica dell'insieme dei formati media)
8.3.2 Changing the Set of Media Formats (Modifica dell'insieme dei formati media)
L'elenco dei formati media usati nella sessione PUÒ essere cambiato. Per farlo, l'offerer crea una nuova descrizione media, con l'elenco dei formati media nella riga m= diverso dal flusso media corrispondente nel SDP precedente. Questo elenco PUÒ includere nuovi formati, e PUÒ rimuovere formati presenti nel SDP precedente. Tuttavia, nel caso di RTP, la mappatura da un particolare numero di tipo di payload dinamico (dynamic payload type) a un particolare codec all'interno di quel flusso media NON DEVE cambiare per la durata di una sessione. Ad esempio, se A genera un'offerta con G.711 assegnato al tipo di payload dinamico 46, il numero di tipo di payload 46 DEVE riferirsi a G.711 da quel punto in poi in qualsiasi offerta o risposta per quel flusso media nella sessione. Tuttavia, è accettabile che più numeri di tipo di payload siano mappati allo stesso codec, così che un'offerta aggiornata potrebbe anche usare il numero 72 per G.711.
Le mappature devono restare fisse per la durata della sessione a causa della sincronizzazione lasca tra gli scambi di segnalazione SDP e il flusso media.
Il flusso media corrispondente nella risposta è formulato come descritto nella sezione 6, e può comportare anche un cambio di formati media. Analogamente, come descritto nella sezione 6, non appena invia la sua risposta, l'answerer DEVE iniziare a inviare media usando qualsiasi formato nell'offerta che era anche presente nella risposta, e DOVREBBE usare il formato più preferito nell'offerta che era anche elencato nella risposta (supponendo che il flusso consenta l'invio), e NON DEVE inviare usando formati che non sono nell'offerta, anche se erano presenti in un SDP precedente del peer. Analogamente, quando l'offerer riceve la risposta, DEVE iniziare a inviare media usando qualsiasi formato nella risposta, e DOVREBBE usare il più preferito (supponendo che il flusso consenta l'invio), e NON DEVE inviare usando formati che non sono nella risposta, anche se erano presenti in un SDP precedente del peer.
Quando un agent cessa di usare un formato media (non elencando quel formato in un'offerta o risposta, benché fosse in un SDP precedente) dovrà comunque essere preparato a ricevere media con quel formato per un breve periodo. Come sa quando può smettere di essere preparato a ricevere con quel formato? Se deve saperlo, si possono applicare tre tecniche. Prima, l'agent può cambiare le porte oltre a cambiare i formati. Quando i media arrivano sulla nuova porta, sa che il peer ha cessato di inviare con il vecchio formato, e può cessare di essere preparato a riceverlo. Questo approccio ha il vantaggio di essere indipendente dal formato media. Tuttavia, i cambi di porta possono richiedere cambi nella prenotazione delle risorse o nuove chiavi per i protocolli di sicurezza. Il secondo approccio è usare un insieme totalmente nuovo di tipi di payload dinamici per tutti i codec quando uno viene scartato. Quando si ricevono media con uno dei nuovi tipi di payload, l'agent sa che il peer ha cessato di inviare con il vecchio formato. Questo approccio non influisce su prenotazioni o contesti di sicurezza, ma è specifico per RTP e spreca uno spazio di tipi di payload molto piccolo. Un terzo approccio è usare un timer. Quando si riceve l'SDP dal peer, si imposta il timer. Quando scatta, l'agent può cessare di essere preparato a ricevere con il vecchio formato. Un valore di un minuto sarebbe tipicamente più che sufficiente. In alcuni casi, un agent potrebbe non importarsene, e quindi restare continuamente preparato a ricevere con i vecchi formati. In questo caso non serve fare nulla.
Naturalmente, se il flusso offerto è rifiutato, l'offerta può cessare di essere preparata a ricevere usando qualsiasi nuovo formato non appena riceve il rifiuto.