Paul,
Thanks for your explanation.
It seems that I did not notice the important points. I quote them for other members.
---------------------------------------------------------
8.1.7.1 in H.323 (regarding fast connect procedure)
...
A called endpoint may choose to repeat the fastStart element in all subsequent messages up to and including Connect: the contents of the fastStart element shall be the same.
...
NOTE - The called endpoint is only allowed to alter fields in a proposed OpenLogicalChannel structure as specified in this clause. An endpoint is not allowed, for example, to alter the number of frames per packet or other characteristics of the proposed channel not specifically stated in this clause.
---------------------------------------------------------
the Called Device. The problem is really the fault of the Called Device, because it accepted a version it did not support. However, the reason that a called device would do this is because there is nothing in Annex D/H.323 or Annex B/T.38 that tells the called endpoint not to accept the fastStart proposal or to modify the version to match the actual supported version of the endpoint.
OK. I understand.
Probably the best solution would be to modify the T.38 and Annex D/H.323 text to allow the following:
Calling Device Called Device (Version 3) (Version 0) Setup(fastStart(T38Version=3))--------------> <------------------------------------Connect(fastStart(T38Version=0) ^^^ | Responds with actual supported Version----------------------------
Yes.
Also, note that we have precisely the same problem with SIP, too. The INVITE message and the 200 message looks almost exactly the same. Nowhere, as far as I know, does it say how a SIP device should handle the T.38 version field when replying to an INVITE.
As there are no SIP devices for T.38 fortunately, we should handle soon.
Anyway, we should discuss and decide at the next SG16 meeting. Do you plan to propose something at TIA TR30.5 meeting in December?
Best regards, -- Hiroshi Tamura