Tamura-san,

Sorry for the long delay. I was out of the office last week and spending time trying to catch up this week... and fighting a horrible cold. The doctor told me I was a baby for going to see him with a fever of 100.6F, but I don't feel good :-(

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?

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?

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: Wednesday, October 01, 2003 10:01 PM Subject: Re: H.323 Fast Connect and Versioning

Paul,

Thanks for your comment.

One confirmation.

...

...

Why are there issues in Fast Connect only?

With regular H.245 capability exchange and the use of OLCs, both sides

will

...

know the actual capabilities. Version 2 devices should then only send

an

...

OLC with a version that it knows the remote side can accept.

...

The problem has to do with sending a Fast Connect proposal (channel proposal) for T.38v2 (2002 syntax) to a version 0 device (1998) syntax

and

...

that device accepting the proposal and, subsequently, sending

2002-encoded

...

IFP packets. The version 0 device cannot decode the IFP packets.

I understand it.

My question is, In Figure D.8 - D.11 in H.323 Annex D, does the same issue happen?

I think so.

...

In short, there is a potential for sending the wrong ASN.1 PER encoded messages.

Yes.

Regards,

Hiroshi Tamura