Tamura-san,
Time permitting, I will probably try to take something to the TIA TR30.5 meeting. I may not write a concrete proposal, but just present the problem formally and propose a few alternatives. Perhaps through the discussion, we may end up with something we can take to the ITU. Will you be present at that meeting?
Paul
----- Original Message ----- From: "Hiroshi Tamura" tamura@toda.ricoh.co.jp To: paulej@packetizer.com Cc: tamura@toda.ricoh.co.jp; PeterP@vegastream.com; itu-sg16@external.cisco.com; tsg16q14@itu.int Sent: Monday, October 20, 2003 10:13 PM Subject: Re: H.323 Fast Connect and Versioning
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