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@PBC.BE.PHILIPS.COM] Sent: Wednesday, October 06, 1999 12:19 PM To: ITU-SG16@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@pbc.be.philips.com | WWW: http://www.business-comms.be.philips.com | -----------------------------------------------------