Relationship of H.323 and H.245 versions

[Dave Walker]

in response to what I wrote, Pete wrote...
> >I understand what you're trying to do, but I'm a little concerned
> >about allowing a v2 entity to support any version of H.245,
> >including unspecified future versions which may or may not be
> >compatible with what we have now.
> As an ITU requirement any future H.245 version must be backward
> compatible with an earlier one so this shouldn't (in theory) be an
> issue.

Yes, but it's the "in theory" part that gives rise to the concern.
At some point, someone may come up with a very valid reason to break
compatiblity.

> >
> >So let me propose the following paragraph as replacement text for
> >the offending portion of the H.323 Version 2 Summary section (which
> >begins in the same way).
> One reason for suggesting new text is that I wanted a fairly definitive
> statement on this issue and the summary doesn't seem the right place for
> such normative text (i.e. it's a summary and everything it says should
> be in the main body of the document and so doesn't have any normative
> value by itself).  However, if the text you describe were copied to a
> normative part of the document, subject to changing 'other versions' to
> 'more recent versions' (as I have attempted to indicate below) I would
> be happy.  (Also I would like to add a note that the version of H.245
> that they end up connected to may change as a call evolves, as it seems
> churlish not to mention a particular gotcha if we know about it.  I've
> attempt to add text for this below.)

I thought it was normative - it should be, but if it's not and we have
to create a new section that's fine with me.

>
> >
> >"Products claiming compliance with Version 2 of H.323 shall comply
> >with all of the mandatory requirements of this document, H.323 (1998),
> >which references H.225.0 (1998) and H.245 (1998).  The protocol
> >identifiers used in messages defined in H.225.0 (1998) and H.245
> >(1998) are specified in those recommendations.  An H.323 Version 2
> >compliant product may also be compliant with (other)->(more recent) versions

I don't have a major problem with this, but I don't see it as an
improvement.  If my v2 product can't talk to a v1 product, I shouldn't
be prohibited from shifting into v1 mode.

> >of these
> >recommendations, but should not send messages or invoke procedures
> >defined in a newer version of a recommendation than a peer has
> identified itself as supporting.  () ->(Implementations must also be
> aware that, due to the procedures for 'Third party initiated pause and
> re-routing,' they may be connected to different versions of H.245 at
> >different times during the life of a call.)"

I'd like a "for example" in there.  Something like, "Implementations
must be aware that they may be connected to different version of H.245
at different times during the life of a call.  This may occur, for
example, as a result of the procedures for 'Third party initiated pause
and re-routing.'"

I'm also not sure about the "must", but if no-one else objects to it
then I'll not object either.

Regards,

Dave Walker
Mitel Corporation
Ontario, CANADA