TCS is always first message, not TCSAck

[Paul Long]

Douglas,

TCS-first has always been required, and I don't think it can be stated any
clearer than it already is ("...the H.245 terminalCapabilitySet message ...
shall be the first H.245 message sent.") That said, however, it is, IMO, an
artificial requirement as evidence by the fact that many implementations
ignore it and do indeed ack the remote's TCS before sending their TCS
without causing any apparent interoperability problems. That doesn't mean it
is okay to do this, just that I do not know of a problem this has caused,
which is not to say that it hasn't caused problems or will not in the
future.

Speaking of the future, I'd be willing to bet that this _will_ cause
problems for Early H.245 because a v4+ EP might misinterpret the
TCSAck-first from a non-compliant pre-v4 EP--and there are lots of them out
there--as accepting Early H.245. It was probably not a good idea to use
something so subtle as whether TCS or TCSAck is the first message to
indicate acceptance of Early H.245.

Paul Long
ipDialog

-----Original Message-----
From: Douglas Clowes [mailto:dclowes at DINGOBLUE.NET.AU]
Sent: Friday, November 03, 2000 6:05 PM
To: ITU-SG16 at MAILBAG.INTEL.COM
Subject: Re: TCS is always first message, not TCSAck


Paul(s),

I think that the requirement to send TCS as a first message may be
ambiguous, or lead to interworking problems.

An H.323 EP may not be in a position to send TCS at all times, particularly
if it is an Interworking Facility (IWF) such as a Signalling Gateway which
does not participate in RTP. The same may also be true of a Media Gateway
Controller, which must await advice from the MG as to current capabilities
before sending TCS.

H.245 operations, such as CESE and MSDE, have timeouts. If an EP can't
acknowledge a procedure initiated by the other end, until it has sent TCS,
then timeouts are a possibility. I would expect that responses before TCS
would be required, and that TCS should be the first _request_, although I
don't see a good reason why an EP can't do MSDE before it has TCS to send.

Similarly, if each end sends TCS simultaneously, then each end will receive
TCS before TCSAck. But if one EP is not ready to send TCS, it has the
problem that if it does not ack the TCS received, it may timeout and the
call fail. So an EP should be able to ack a received message, even before
sending TCS.

Thoughts?

Douglas

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at mailbag.intel.com