Tamura-san,

I thought it would happen from the conversion among us. I do not understand well. One of my understanding is that the version 1

machine

is not aware of our syntax issue and it could accept any Setup and return Connect irrespective of the version. Am I right?

That is correct. That's the problem we are looking at.

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.

We potentially have this same problem with SIP and other SDP-based systems. They must change the version number in the "answer" to an "offer".

The 2002 ASN.1 syntax is for t30-data. Before V.21 signal starts, i.e. during CNG and CED exchange, I do not believe there are issues. If we use Fast Connect and V.21 signals are exchanged during Fast Connect, it would be a problem. Is this one of the problems?

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.

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

Paul