Re: H.323 Fast Connect and Versioning
Paul et al, Pardon my $AU 0.02 ... I thought that it was a fundamental principle that protocols were backward compatible, despite the fact that this is not always so. Making such a change breaks backward compatibility. An existing version 0 called device will respond with the mandatorily unchanged version 3. It is unsafe for the calling device to assume that the called device can handle version 3 if version 3 is not compatible with version 0. The proposed solution does not discriminate between a device that replies with offered version because it can handle it, or because it doesn't know they are incompatible. A existing version 3 calling device (if there is one) may break if it receives a modified faststart response from the called device, being unable to match the accepted faststart against the offered ones. Since this is only an issue for faststart (contained in H.225.0) it seems reasonable to base the solution on H.225.0. Option 1. ========= If you want the behaviour of changing the faststart, as indicated in the email to which this replies, then look at the protocolIdentifier, and introduce the behaviour at a particular value. There would be a magic value of protocolIdentifier which triggers the new behaviour. A called endpoint must follow earlier behaviour for values of protocolIdentifier (in Setup) less than the magic value where changed behaviour is allowed (i.e. must not change the faststart) and must follow later behaviour (set the verion) if protocolIdentifier is equal or greater. This avoids confusing an older calling endpoint. For the calling endpoint, if the protocolIdentifier (in the response e.g. Connect) is less than the magic value, it must limit the version selected to that which was available when that version of H.225.0 was decided, and if equal or greater must use the possibly modified version in the response. This requires that the value of the protocolIdentifier be modified (incremented) to achieve discrimination. Not something which should be done in a change to the IG (IMHO). Option 2. ========= Add an optional element to H.225.0 to carry the possibly modified fastStart (e.g. "modifiedFastStart SEQUENCE OF OCTET STRING OPTIONAL" wherever fastStart appears in a response) to contain the fastStart with the actual version accepted. If a called endpoint adds this to its response and the calling endpoint doesn't understand it, no harm is done because the called EP is a later vintage than the calling EP and presumably understands everything the calling EP could send. A calling EP that doesn't find this element must limit the version used as in option 1, and if it does find this element, must limit the version to that contained therein. (end of options) I feel that Option 1 is cleaner, but Option 2 is more IG-friendly. I also note that option 2 could be retrofitted to earlier versions of H.323 if the option 2 modifiedFastStart element were embedded in a NonStandardParameter of a ClearToken with a "magic" tokenOID, carried in the "tokens" element of the H.225.0 response. In this case, no change to the ASN.1 would be required, and an H.323 v2 EP (say) could indicate that it really does understand some later version of a codec that it normally wouldn't be expected to understand. However, this has a strong kludgy feel to it :). Anyway, since I'm not currently being paid for this, I guess that I should limit my time. Cheers, Douglas Clowes Consultant, Savant Solutions P/L. At 03:27 17/10/2003 -0400, Paul E. Jones wrote:
participants (1)
-
Douglas Clowes