A scenario that cannot be solved without APC-1280 or deferred "Connect"

[Gur Kimchi]

Joerg Ott wrote:
> I am wondering whether you are missing the point here.

Hey, it could happen. :-)

> - H.225.0 signaling carries a protocol identifier in the mandatory part
>   of all relevant PDUs (RAS as well as call signaling channel)

You're right. However, this is a tenuous relationship that should
perhaps be documented. Even though H.225.0 is integral to H.323, we need
to be extra careful with future versions of these Recommendations to
assure that the numbers of associated versions are always the same. The
only mention I could find in either H.323 or H.225.0 is editorial, not
normative.  6.1/H.225.0: "...both the discovery and registration
sequences contain an H.245 style OBJECT IDENTIFIER that allows the
vintage to be determined in terms of the version of H.323 implemented."
I don't know, maybe such a thing cannot be normative.

> - H.323/H.225.0 describe in each revesion explicitly which version of
>   H.245 to use

When I first started on H.323 last year, I asked Jim Toga which version
of H.245 to use. He said to use version 2 but that this wasn't
documented anywhere. I see now that it is.

> and which features of this to implement.

As I said in my previous email, H.323 does not specify which ASN.1
extension fields are required. It states which messages and procedures
are required but not which extensions are required. This is still a big
problem and the principal one that I was addressing in this thread. An
endpoint has no way of knowing whether the remote endpoint will
recognize a particular extension. This _will_ cause problems like the
one I described concerning opening a logical channel.

>   (And, for clarity, this is *NOT* done in the ASN.1, but in the
>   references section of the document!)

I justed looked, and versions 1 and 2 of both Recommendations cite H.245
version 1--not version 2--in terms of the year of decision (1995 vs
1997). I assume this should be fixed.

> Hence you can deduce the H.245 version from the H.225.0 version number
> which is determined IN-BAND in the first PDU exchange between any two
> H.323 systems.

I see this now. Thanks.

> And, of course, you cannot add anything to H.245 without
> this being appropriate reflected in the H.323/H.225.0 specification.

Maybe I misunderstood him, but it sounded like Jim was saying just the
opposite, that an H.323 endpoint could use H.245 constructs in a version
of H.245 after the version identified in the H.323 Recommendation. See
for yourself. What do you think? "If vendors want to utilize some of the
constructs from v2 in their v1 implementations (and other entities
recognize and respond to them) there is no 'rule' against this."

> Also: you are talking about no H.323 version signaling?  H.225.0 and H.323
> go together at all times!  H.225.0 defines the protocol syntax and H.323
> the procedures; so there is no difference between an H.225.0 and an H.323
> version number!

Well, there is a difference, because they are separate Recommendations.
However, as long as we have people like you around that know that they
must have the same version number, we'll be okay, but there is
technically nothing preventing them from having different version
numbers.

--
Paul Long___________________________http://www.cmpu.net/public/plong
Smith Micro Software, Inc.__________http://www.smithmicro.com/