Relationship of H.323 and H.245 versions
dave_walker at Mitel.COM
Wed Jan 20 15:31:53 EST 1999
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
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
> >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
I'm also not sure about the "must", but if no-one else objects to it
then I'll not object either.
More information about the sg16-avd