Re: Relationship of H.323 and H.245 versions
Dave,
Comments interleaved...
Pete,
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.
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.)
"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 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.)"
Regards,
Dave Walker Mitel Corporation Ontario, CANADA
Regards,
Pete
================================= Pete Cordell BT Labs E-Mail: pete.cordell@bt-sys.bt.co.uk Tel: +44 1473 646436 Fax: +44 1473 645499 =================================
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
participants (2)
-
Dave Walker -
Pete Cordell