15. Backward Compatibility to RFC 3984 (Rétrocompatibilité avec la RFC 3984)

15. Backward Compatibility to RFC 3984 (Rétrocompatibilité avec la RFC 3984)

Le présent document est une révision de la RFC 3984 et la rend obsolète. Les modifications techniques par rapport à la RFC 3984 sont énumérées à la section 14. La présente section traite des questions de rétrocompatibilité.

Il convient de noter que, dans la majorité des cas, il n'y aura pas de problèmes de compatibilité pour l'interopérabilité entre les implémentations héritées conformes à la RFC 3984 et les nouvelles implémentations conformes au présent document. Les problèmes de compatibilité ne peuvent survenir que lorsque les deux conditions suivantes sont vraies : 1) les implémentations héritées et les nouvelles implémentations interopèrent, et 2) les ensembles de paramètres sont transportés hors bande. Lorsque de tels problèmes de compatibilité surviennent, il est facile de déboguer et de trouver la raison de l'incompatibilité à l'aide des analyses suivantes.

Les éléments 1, 2, 3, 7, 9, 10, 12 et 13 sont des modifications de type correction de bogues et n'entraînent aucun problème de rétrocompatibilité.

L'élément 4 (ajout de six nouveaux paramètres de type de média) n'entraîne aucun problème de rétrocompatibilité pour les applications basées sur SDP Offer/Answer, car les récepteurs hérités conformes à la RFC 3984 ignorent ces paramètres, et il est acceptable que les émetteurs hérités conformes à la RFC 3984 n'utilisent pas ces paramètres car ils sont optionnels. Cependant, il existe un problème de rétrocompatibilité pour les applications basées sur un usage déclaratif (uniquement pour le paramètre sprop-level-parameter-sets, car les cinq autres paramètres ne sont pas utilisables en usage déclaratif). Par exemple, les applications à usage déclaratif utilisant RTSP et SAP ont un problème de rétrocompatibilité parce que le récepteur SDP conforme à la RFC 3984 ne peut pas accepter une session pour laquelle le SDP inclut un paramètre non reconnu. Par conséquent, le serveur RTSP ou SAP peut devoir préparer deux jeux de flux, l'un pour les récepteurs hérités conformes à la RFC 3984 et l'autre pour les récepteurs conformes au présent mémo.

Les éléments 5, 6 et 11 concernent le transport hors bande des ensembles de paramètres. Les problèmes de rétrocompatibilité suivants existent.

1. Lorsqu'un émetteur hérité conforme à la RFC 3984 inclut dans sprop-parameter-sets des ensembles de paramètres pour un niveau différent du niveau par défaut indiqué par profile-level-id, la valeur du paramètre sprop-parameter-sets est invalide pour le récepteur conforme au présent mémo ; par conséquent, la session peut être rejetée.

2. Dans SDP Offer/Answer entre un offreur hérité conforme à la RFC 3984 et un répondant conforme au présent mémo, lorsque le répondant inclut dans la réponse des ensembles de paramètres qui ne sont pas un sur-ensemble des ensembles de paramètres inclus dans l'offre, la valeur du paramètre sprop-parameter-sets est invalide pour l'offreur, et la session peut ne pas être initiée correctement (lié à l'élément de modification 11).

3. Lorsqu'un point d'extrémité A conforme au présent mémo inclut in-band-parameter-sets égal à 1, l'autre côté B conforme à la RFC 3984 ne comprend pas qu'il doit transmettre les ensembles de paramètres en bande, et B peut toujours exclure les ensembles de paramètres du flux en bande qu'il envoie. Par conséquent, le point d'extrémité A ne peut pas décoder le flux qu'il reçoit.

L'élément 7 (autorisation de transmettre sprop-parameter-sets et sprop-level-parameter-sets au moyen de l'attribut source fmtp tel que spécifié à la section 6.3 de [9]) est similaire à l'élément 4. Il n'entraîne aucun problème de rétrocompatibilité pour les applications basées sur SDP Offer/Answer, car les récepteurs hérités conformes à la RFC 3984 ignorent l'attribut source fmtp, et il est acceptable que les émetteurs hérités conformes à la RFC 3984 n'utilisent pas l'attribut source fmtp car il est optionnel. Cependant, il existe un problème de rétrocompatibilité pour les applications basées sur un usage déclaratif SDP, par exemple celles utilisant RTSP et SAP, parce que le récepteur SDP conforme à la RFC 3984 ne peut pas accepter une session pour laquelle le SDP inclut un paramètre non reconnu (c'est-à-dire l'attribut source fmtp). Par conséquent, le serveur RTSP ou SAP peut devoir préparer deux jeux de flux, l'un pour les récepteurs hérités conformes à la RFC 3984 et l'autre pour les récepteurs conformes au présent mémo.

L'élément 14 n'entraîne aucun problème de rétrocompatibilité, car le transport hors bande des ensembles de paramètres reste autorisé.

L'élément 15 n'entraîne aucun problème de rétrocompatibilité, car la section 8.5 ajoutée est informative.

L'élément 16 ne crée aucun problème de rétrocompatibilité car la gestion du niveau par défaut est la même si l'une des extrémités est conforme à la RFC 3984, et en outre, les extrémités conformes à la RFC 3984 ignoreraient simplement les nouveaux paramètres de type de média, s'ils sont présents.