15. Backward Compatibility to RFC 3984 (Compatibilità all'indietro con RFC 3984)

15. Backward Compatibility to RFC 3984 (Compatibilità all'indietro con RFC 3984)

Il presente documento è una revisione dell'RFC 3984 e la rende obsoleta. Le modifiche tecniche rispetto all'RFC 3984 sono elencate nella sezione 14. Questa sezione affronta le questioni di compatibilità all'indietro.

Va osservato che nella maggior parte dei casi non vi saranno problemi di compatibilità per l'interoperabilità tra implementazioni legacy conformi all'RFC 3984 e nuove implementazioni conformi al presente documento. I problemi di compatibilità possono verificarsi solo quando sono vere entrambe le seguenti condizioni: 1) implementazioni legacy e nuove implementazioni interoperano, e 2) gli insiemi di parametri sono trasportati fuori banda. Quando si verificano tali problemi di compatibilità, è facile eseguire il debug e individuare la causa dell'incompatibilità mediante le analisi seguenti.

Gli elementi 1, 2, 3, 7, 9, 10, 12 e 13 sono modifiche di tipo correzione di bug e non comportano problemi di compatibilità all'indietro.

L'elemento 4 (aggiunta di sei nuovi parametri di tipo di media) non comporta problemi di compatibilità all'indietro per le applicazioni basate su SDP Offer/Answer, poiché i ricevitori legacy conformi all'RFC 3984 ignorano questi parametri, ed è accettabile che i mittenti legacy conformi all'RFC 3984 non usino tali parametri in quanto opzionali. Tuttavia vi è un problema di compatibilità all'indietro per le applicazioni basate su uso dichiarativo (solo per il parametro sprop-level-parameter-sets, poiché gli altri cinque parametri non sono utilizzabili in uso dichiarativo). Ad esempio, le applicazioni a uso dichiarativo che usano RTSP e SAP hanno un problema di compatibilità all'indietro perché il ricevitore SDP conforme all'RFC 3984 non può accettare una sessione il cui SDP include un parametro non riconosciuto. Pertanto il server RTSP o SAP potrebbe dover preparare due insiemi di flussi, uno per i ricevitori legacy conformi all'RFC 3984 e uno per i ricevitori conformi al presente memo.

Gli elementi 5, 6 e 11 riguardano il trasporto fuori banda degli insiemi di parametri. Sussistono i seguenti problemi di compatibilità all'indietro.

1. Quando un mittente legacy conforme all'RFC 3984 include in sprop-parameter-sets insiemi di parametri per un livello diverso dal livello predefinito indicato da profile-level-id, il valore del parametro sprop-parameter-sets non è valido per il ricevitore conforme al presente memo; pertanto la sessione può essere rifiutata.

2. In SDP Offer/Answer tra un offerente legacy conforme all'RFC 3984 e un rispondente conforme al presente memo, quando il rispondente include nella risposta insiemi di parametri che non sono un sovrainsieme degli insiemi di parametri inclusi nell'offerta, il valore del parametro sprop-parameter-sets non è valido per l'offerente e la sessione potrebbe non essere avviata correttamente (correlato all'elemento di modifica 11).

3. Quando un endpoint A conforme al presente memo imposta in-band-parameter-sets uguale a 1, l'altro lato B conforme all'RFC 3984 non comprende che deve trasmettere gli insiemi di parametri in banda, e B può ancora escludere gli insiemi di parametri dal flusso in banda che sta inviando. Di conseguenza l'endpoint A non può decodificare il flusso ricevuto.

L'elemento 7 (consentire di veicolare sprop-parameter-sets e sprop-level-parameter-sets tramite l'attributo sorgente fmtp come specificato nella sezione 6.3 di [9]) è simile all'elemento 4. Non comporta problemi di compatibilità all'indietro per le applicazioni basate su SDP Offer/Answer, poiché i ricevitori legacy conformi all'RFC 3984 ignorano l'attributo sorgente fmtp, ed è accettabile che i mittenti legacy conformi all'RFC 3984 non usino l'attributo sorgente fmtp in quanto opzionale. Tuttavia vi è un problema di compatibilità all'indietro per le applicazioni basate su uso dichiarativo SDP, ad esempio quelle che usano RTSP e SAP, perché il ricevitore SDP conforme all'RFC 3984 non può accettare una sessione il cui SDP include un parametro non riconosciuto (cioè l'attributo sorgente fmtp). Pertanto il server RTSP o SAP potrebbe dover preparare due insiemi di flussi, uno per i ricevitori legacy conformi all'RFC 3984 e uno per i ricevitori conformi al presente memo.

L'elemento 14 non comporta problemi di compatibilità all'indietro, poiché il trasporto fuori banda degli insiemi di parametri è ancora consentito.

L'elemento 15 non comporta problemi di compatibilità all'indietro, poiché la sezione 8.5 aggiunta è informativa.

L'elemento 16 non crea problemi di compatibilità all'indietro poiché la gestione del livello predefinito è la stessa se almeno un'estremità è conforme all'RFC 3984 e, inoltre, le estremità conformi all'RFC 3984 ignorerebbero semplicemente i nuovi parametri di tipo di media, se presenti.