Re: H.323 Fast Connect and Versioning
Tamura-san,
The problem is not related to D.8-D.11. The problem is only with Fast Connect. The scenario is this: Calling Device Called Device (Version 3) (Version 0) Setup(fastStart(T38Version=3))--------------> <------------------------------------Connect(fastStart(T38Version=3) ^^^ | Responds with incorrect Version----------------------------
Once the Calling Device receives the fastStart message with version 3 advertised, it will transmit UDPTL data with the wrong ASN.1 encoding for 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.
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----------------------------
However, I do not know which devices might break as a result of this. It would only be devices that propose T.38 channels in the Setup message.
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.
Paul
----- Original Message ----- From: "Hiroshi Tamura" tamura@toda.ricoh.co.jp To: paulej@packetizer.com Cc: PeterP@vegastream.com; itu-sg16@external.cisco.com; tsg16q14@itu.int Sent: Tuesday, October 14, 2003 4:41 AM Subject: Re: H.323 Fast Connect and Versioning
Paul,
Anyway, to answer your question... I don't think the procedures
documented
in D.8 - D.11 are a problem. In theory, the endpoint that transmits an
OLC
would not propose an OLC with a version number included that is not supported by the other side. However, the text does not say that. As
such,
I think I will bring a contribution as Rapporteur to have some text
added
that makes it very explicit that an endpoint SHALL NOT propose in an OLC version of T.38 not supported by the other endpoint. Does that sound reasonable?
Yes, Reasonable.
But, before that, I'm very sorry for my poor understanding. Why does the problem happen in D.8 - D.11? "version" in T38FaxProfile in DataApplicationCapability in OLC is the same in all cases. Even in voice to fax case, for example, between the caller
with
the version 3 and the called with the version 1, does the called possibly accept (CONNECT) in reponse to SETUP because it does not know our syntax
issue?
Could you please explain to me?
Thanks in advance.
I have also had some discussion with people about the various solutions
to
Fast Connect. I think one person or another thinks the various ideas
(and I
have about 5 now) are insufficient. What has most recently been
proposed is
to simply add text that says a called endpoint shall not accept a Fast Connect proposal that includes a T.38 version it does not support. That kind of text should have been in there, as well, but it is not. I
wonder if
anybody's equipment would break with such text?
I hope it does not exist. If any, the version 2 implementation before the last meeting may do harm. Also, the above sentence that you suggests is ok for me.
Regards,
Hiroshi Tamura
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
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
Paul,
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?
Now, I cannot say yes or no. But, it is good to finish it at Janauary meeting.
Also, now, Chimura-san and I are examining T.38 implementers guide, which is near term work issues in Q.14. If we can make something before the meeting and my boss allows me to go there, I positively think of it.
Best regards, -- Hiroshi Tamura
participants (2)
-
Hiroshi Tamura -
Paul E. Jones