Capability Exchange procedures

Paul Long plong at SMITHMICRO.COM
Wed Oct 6 18:14:45 EDT 1999


Frank,

No, from my experience, TCSReject is really only used to indicate a
non-sensical or otherwise unusable TCS, such as a descriptor that references
a non-existent table entry. There is no other reason for an EP to "not
like," or reject, a TCS. If a TCS indicates receive capability for something
you can't transmit, ignore it; if it indicates transmit capability for
something you can't receive, no problem--the remote EP will look at _your_
receive caps to determine what to transmit, not its own transmit caps.

BTW, I have always thought that that passage was kinda screwy. An EP would
first have to send an OLC request and receive an OLCAck before transmitting
a signal (Fast Connect aside). If the remote doesn't have receive capability
for a signal, it would presumable respond with OLCReject, so does this
passage mean that an EP shall not _request_ to open a logical channel for
something for which the remote EP does not have the receive caps? (Stupid,
but what's the harm?) Or does it mean that even if the remote EP acks the
open request for a signal for which it did not previously indicate receive
caps, the requesting EP cannot then transmit it? Seems to me that this is at
best a redundant requirement. The intent was probably that an EP should only
transmit a signal for which it has somehow received acknowledgement, i.e.,
through the CESE or Fast Connect procedures.

Regarding the last sentence of the first paragraph of 5.2, this means that
the presence of unrecognized extensions do not effect the root or recognized
extensions of a capability (or any other ASN.1 component, for that matter).
The receiver should simply ignore them. This brings up a VERY important
point, however! The sender of a message must know what version of H.245 the
receiver is using. (All of this goes for RAS and call-signaling, too.) If it
encodes extensions that were defined after the receiver's version, it must
know that the receiver is behaving based only on the components it
recognizes. For example, if an H.323v3 EP sends an h263VideoCap containing
the h263options extension addition to an H.323v1 EP, and the v1 EP
acknowledges the cap set, the v3 EP shall not encode any H.263 features
identified in the h263Options extension addition. The v1 EP is only
acknowledging what it recognizes, which in this case does not include
h263Options, not necessarily what the v3 EP sent. As we build more and more
products based on more and more different versions of H.323, this must
always be kept in mind! As long as we were all v1, one never needed to check
the version of the remote. Things are different now.

I think that the second paragraph of 5.2 is clear. It does not say that the
total capability of a terminal is its receive caps, excluding its transmit
caps. It just says that a terminal indicates its total receive caps via its
cap set.

Strictly speaking, you are correct about paragraph three (not four).
However, I think that most people read it as if it were written this way:
"The absence of a receive capability indicates that the terminal cannot
receive [the particular signal described by that capability] (is a
transmitter only)." Perhaps this should be clarified in H.245v6 (v7?).

I see your point about 7.2.3, but I think that the mere presence of Table 6
indicates when a TCSReject should be sent.

Paul Long
Smith Micro Software, Inc.

-----Original Message-----
From: Derks, Frank [mailto:F.Derks at PBC.BE.PHILIPS.COM]
Sent: Wednesday, October 06, 1999 12:19 PM
To: ITU-SG16 at MAILBAG.INTEL.COM
Subject: Capability Exchange procedures


Dear All,

I just went through the descriptions of the Capability Exchange in both
the
H.323 and the H.245 documents and it would seem that they are not quite
clear.

The first two sentences in the first paragraph in H.245, "5.2 Capability
Exchange", seem to mean that a terminal should not send any media that
"can
not be received" by the receive terminal. The only way to achieve this
is
that the receive terminal send a TCS Reject for all those media types
that
it can not receive. However, the third sentence contradicts this by
stating
that those capabilities that are not understood (or can be used) should
be
ignored. Furthermore, the fourth sentence states that not understood
extensions to a capability that is understood (and can be used) should
be
ignored, which could result in unsuccessful communication. So how should
this paragraph be read.

The second paragraph in H.245, "5.2 Capability Exchange", states: "The
total
capability of a terminal to receive and decode various signals is made
known
to the other terminal by transmission of its capability set."

I would say that the "total capability" includes both the receive and
the
transmit capabilities and not just its "receive (and decode)"
capabilities.

Furthermore, most of section 5.2 talks about capabilities and not about
their exchange.

The fourth paragraph in H.245, "5.2 Capability Exchange", states: "The
absence of _a_ transmit capability indicates that ....". This phrasing
(the
"a") suggests that the absence of just one of the capabilities indicates
that no choices are offered.

Section 7.2.3 "Terminal Capability Set Acknowledge", states: "This is
used
to confirm receipt of a TerminalCapabilitySet from the peer CESE". In
other
words upon reception of a TCS, the Acknowledge should always be sent. So
when should a Reject be sent? The logical succession of TCS messages
between
two CESEs is not well documented and clarifying text is required to make
this clear.

Frank

-----------------------------------------------------
Frank Derks                    |Tel  +31 35 6893238 |
Advanced Development           |Fax  +31 35 6891030 |
Philip Business Communications |P.O. Box 32         |
                               |1200 JD  Hilversum  |
                               |The Netherlands     |
----------------------------------------------------|
E-mail: mailto:f.derks at pbc.be.philips.com           |
WWW: http://www.business-comms.be.philips.com       |
-----------------------------------------------------



More information about the sg16-avd mailing list