Paul,
Ugly! That leaves open the decision, for the receiver of the TCS, of when you give up on a call because you do not have compatible capabilities.
I can see that an empty-ish TCS could be distinguished from a TCS that isn't empty, but contains codecs I can't match. But how many EPs out there would already appreciate the distinction? If I send TCS 0.5, will my peer drop the call?
Ugly!
Douglas
At 21:13 04/11/2000 -0600, Paul Long wrote:
Regarding Douglas' concern, regardless of whether "an EP _should_ be able to ack a received message, even before sending TCS" (emphasis mine), the fact remains that it _shall not_ do this, except when indicating that it understands earlyH245Control. The solution to the particular problem he mentions is for the endpoint to send an "almost empty" TCS, or "TCS=0.5" :-). All it contains is sequenceNumber, protocolIdentifier, and--here's the important part--multiplexCapability. In particular, it doesn't need to contain capabilityTable or capabilityDescriptors, and the multiplexCapability can provide only minimal information. Including multiplexCapability means that it is not an empty TCS and therefore cannot be mistaken for one, but the endpoint also does not need to know its eventual capabilities at call-startup time.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com