Paul and Douglas,
I want to make sure there are no problems with the text defined in 8.2.4/H.323v4 ("Early H.245").
The Early H.245 field is in a special field inside the Setup message typically used only with Fast Connect. If the called endpoint understands this, it shall reply with a TCSAck as the first H.245 message: that is a requirement in that section of text. If it does not understand that field, it may reply with something else.
If we were using one of the pre-existing fields in v3/2/1, I'd agree that the order of messages would be problematic, but this field can only be interpreted by a V4 device and the order of messages is explicit (I hope). Do you believe that there are problem? It seems solid to me.
Paul
----- Original Message ----- From: "Paul Long" plong@PACKETIZER.COM To: ITU-SG16@mailbag.cps.intel.com Sent: Saturday, November 04, 2000 12:21 PM Subject: Re: TCS is always first message, not TCSAck
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@DINGOBLUE.NET.AU] Sent: Friday, November 03, 2000 6:05 PM To: ITU-SG16@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@mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com