15. Backward Compatibility to RFC 3984 (Abwärtskompatibilität zu RFC 3984)

15. Backward Compatibility to RFC 3984 (Abwärtskompatibilität zu RFC 3984)

Das vorliegende Dokument ist eine Überarbeitung von RFC 3984 und macht es obsolet. Die technischen Änderungen gegenüber RFC 3984 sind in Abschnitt 14 aufgeführt. Dieser Abschnitt behandelt Fragen der Abwärtskompatibilität.

Es ist zu beachten, dass es in der Mehrzahl der Fälle keine Kompatibilitätsprobleme bei der Interoperabilität zwischen älteren Implementierungen gemäß RFC 3984 und neuen Implementierungen gemäß diesem Dokument geben wird. Kompatibilitätsprobleme können nur auftreten, wenn beide der folgenden Bedingungen zutreffen: 1) ältere und neue Implementierungen arbeiten zusammen, und 2) Parametersätze werden out-of-band transportiert. Wenn solche Kompatibilitätsprobleme auftreten, lassen sich mit den folgenden Analysen die Ursache der Inkompatibilität leicht debuggen und finden.

Die Punkte 1, 2, 3, 7, 9, 10, 12 und 13 sind änderungsbedingte Fehlerbehebungen und verursachen keine Abwärtskompatibilitätsprobleme.

Punkt 4 (Hinzufügen von sechs neuen Medientyp-Parametern) verursacht keine Abwärtskompatibilitätsprobleme für SDP-Offer/Answer-basierte Anwendungen, da ältere RFC-3984-Empfänger diese Parameter ignorieren und es für ältere RFC-3984-Sender in Ordnung ist, diese optionalen Parameter nicht zu verwenden. Es gibt jedoch ein Abwärtskompatibilitätsproblem für deklarativ genutzte Anwendungen (nur für den Parameter sprop-level-parameter-sets, da die anderen fünf Parameter in deklarativer Nutzung nicht verwendbar sind). Beispielsweise haben deklarativ genutzte Anwendungen mit RTSP und SAP ein Abwärtskompatibilitätsproblem, weil der SDP-Empfänger gemäß RFC 3984 eine Sitzung nicht akzeptieren kann, deren SDP einen nicht erkannten Parameter enthält. Daher muss der RTSP- oder SAP-Server möglicherweise zwei Sätze von Streams bereitstellen, einen für ältere RFC-3984-Empfänger und einen für Empfänger gemäß diesem Memo.

Die Punkte 5, 6 und 11 betreffen den Out-of-Band-Transport von Parametersätzen. Es bestehen folgende Abwärtskompatibilitätsprobleme.

1. Wenn ein älterer Sender gemäß RFC 3984 in sprop-parameter-sets Parametersätze für eine andere Stufe als die durch profile-level-id angegebene Standardstufe aufnimmt, ist der Parameterwert von sprop-parameter-sets für den Empfänger gemäß diesem Memo ungültig; daher kann die Sitzung abgelehnt werden.

2. Bei SDP Offer/Answer zwischen einem älteren Anbieter gemäß RFC 3984 und einem Antwortenden gemäß diesem Memo: Wenn der Antwortende in der Antwort Parametersätze aufnimmt, die keine Obermenge der im Angebot enthaltenen Parametersätze sind, ist der Parameterwert von sprop-parameter-sets für den Anbieter ungültig, und die Sitzung kann nicht ordnungsgemäß initiiert werden (bezogen auf Änderungspunkt 11).

3. Wenn ein Endpunkt A gemäß diesem Memo in-band-parameter-sets gleich 1 setzt, versteht die andere Seite B gemäß RFC 3984 nicht, dass sie Parametersätze in-band übertragen muss, und B kann weiterhin Parametersätze aus dem von ihm gesendeten In-Band-Stream ausschließen. Folglich kann Endpunkt A den empfangenen Stream nicht decodieren.

Punkt 7 (Zulassung der Übermittlung von sprop-parameter-sets und sprop-level-parameter-sets mit dem in Abschnitt 6.3 von [9] spezifizierten fmtp-Quellattribut) ähnelt Punkt 4. Er verursacht keine Abwärtskompatibilitätsprobleme für SDP-Offer/Answer-basierte Anwendungen, da ältere RFC-3984-Empfänger das fmtp-Quellattribut ignorieren und es für ältere RFC-3984-Sender in Ordnung ist, das optionale fmtp-Quellattribut nicht zu verwenden. Es gibt jedoch ein Abwärtskompatibilitätsproblem für SDP-deklarativ genutzte Anwendungen, z. B. solche mit RTSP und SAP, weil der SDP-Empfänger gemäß RFC 3984 eine Sitzung nicht akzeptieren kann, deren SDP einen nicht erkannten Parameter enthält (d. h. das fmtp-Quellattribut). Daher muss der RTSP- oder SAP-Server möglicherweise zwei Sätze von Streams bereitstellen, einen für ältere RFC-3984-Empfänger und einen für Empfänger gemäß diesem Memo.

Punkt 14 verursacht keine Abwärtskompatibilitätsprobleme, da der Out-of-Band-Transport von Parametersätzen weiterhin erlaubt ist.

Punkt 15 verursacht keine Abwärtskompatibilitätsprobleme, da der hinzugefügte Abschnitt 8.5 informativ ist.

Punkt 16 erzeugt keine Abwärtskompatibilitätsprobleme, da die Handhabung der Standardstufe dieselbe ist, wenn mindestens ein Ende RFC-3984-konform ist, und darüber hinaus würden RFC-3984-konforme Enden die neuen Medientyp-Parameter, falls vorhanden, einfach ignorieren.