15. Backward Compatibility to RFC 3984

15. Backward Compatibility to RFC 3984

The current document is a revision of RFC 3984 and obsoletes it. The technical changes relative to RFC 3984 are listed in Section 14. This section addresses the backward compatibility issues.

It should be noted that for the majority of cases, there will be no compatibility issues for legacy implementations per RFC 3984 and new implementations per this document to interwork. Compatibility issues may only occur when both of the following conditions are true: 1) legacy implementations and new implementations are interworking, and 2) parameter sets are transported out-of-band. When such compatibility issues occur, it is easy to debug and find the reason for the incompatibility using the following analyses.

Items 1, 2, 3, 7, 9, 10, 12, and 13 are bug-fix types of changes and do not incur any backward compatibility issues.

Item 4 (addition of six new media type parameters) does not incur any backward compatibility issues for SDP Offer/Answer-based applications, as legacy RFC 3984 receivers ignore these parameters, and it is fine for legacy RFC 3984 senders not to use these parameters as they are optional. However, there is a backward compatibility issue for declarative-usage-based applications (only for the parameter sprop-level-parameter-sets as the other five parameters are not usable in declarative usage). For example, declarative-usage-based applications using RTSP and SAP have a backward compatibility issue because the SDP receiver per RFC 3984 cannot accept a session for which the SDP includes an unrecognized parameter. Therefore, the RTSP or SAP server may have to prepare two sets of streams, one for legacy RFC 3984 receivers and one for receivers according to this memo.

Items 5, 6, and 11 are related to out-of-band transport of parameter sets. There are following backward compatibility issues.

1. When a legacy sender per RFC 3984 includes parameter sets for a level different than the default level indicated by profile-level-id to sprop-parameter-sets, the parameter value of sprop-parameter-sets is invalid to the receiver per this memo; therefore, the session may be rejected.

2. In SDP Offer/Answer between a legacy offerer per RFC 3984 and an answerer per this memo, when the answerer includes in the answer parameter sets that are not a superset of the parameter sets included in the offer, the parameter value of sprop-parameter-sets is invalid to the offerer, and the session may not be initiated properly (related to change item 11).

3. When one endpoint A per this memo includes in-band-parameter-sets equal to 1, the other side B per RFC 3984 does not understand that it must transmit parameter sets in-band, and B may still exclude parameter sets in the in-band stream it is sending. Consequently, endpoint A cannot decode the stream it receives.

Item 7 (allowance of conveying sprop-parameter-sets and sprop-level-parameter-sets using the fmtp source attribute as specified in Section 6.3 of [9]) is similar to item 4. It does not incur any backward compatibility issues for SDP Offer/Answer-based applications, as legacy RFC 3984 receivers ignore the fmtp source attribute, and it is fine for legacy RFC 3984 senders not to use the fmtp source attribute as it is optional. However, there is a backward compatibility issue for SDP declarative-usage-based applications, e.g., those using RTSP and SAP, because the SDP receiver per RFC 3984 cannot accept a session for which the SDP includes an unrecognized parameter (i.e., the fmtp source attribute). Therefore, the RTSP or SAP server may have to prepare two sets of streams, one for legacy RFC 3984 receivers and one for receivers according to this memo.

Item 14 does not incur any backward compatibility issues, as out-of-band transport of parameter sets is still allowed.

Item 15 does not incur any backward compatibility issues, as the added Section 8.5 is informative.

Item 16 does not create any backward compatibility issues as the handling of the default level is the same if either end is RFC 3984 compliant, and, furthermore, RFC-3984-compliant ends would simply ignore the new media type parameters, if present.