TCS is always first message, not TCSAck

[Douglas Clowes]

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 at mailbag.intel.com